Dear Aaron, dear Jeff,
Am Dienstag, den 24.03.2015, 19:43 +0000 schrieb Brown, Aaron F:
> > Am Sonntag, den 22.03.2015, 00:57 -0700 schrieb Jeff Kirsher:
> > > On Sun, 2015-03-22 at 08:42 +0100, Paul Menzel wrote:
> > > > please CC me on replies as I am not subscribed.
> > > >
> > > > On an Intel S1200RP server board with firmware version
> > > > S1200RP.86B.01.03.0004.082120131450 and an Intel I210 ethernet
> > > > controller,
> > > >
> > > > $ lspci -s 2:00 -nn
> > > > 02:00.0 Ethernet controller [0200]: Intel Corporation I210
> > > > Gigabit Network Connection [8086:1533] (rev 03)
> > > >
> > > > using Linux 3.16.7-ck7-1 with igb 5.0.5-k, the driver takes
> > > > four seconds until the link is up.
> > > >
> > > > $ dmesg | grep -i igb
> > > > [ 1.590061] igb: Intel(R) Gigabit Ethernet Network Driver -
> > > > version 5.0.5-k
> > > > [ 1.590063] igb: Copyright (c) 2007-2014 Intel Corporation.
> > > > [ 1.695658] igb 0000:02:00.0: irq 43 for MSI/MSI-X
> > > > [ 1.695662] igb 0000:02:00.0: irq 44 for MSI/MSI-X
> > > > [ 1.695665] igb 0000:02:00.0: irq 45 for MSI/MSI-X
> > > > [ 1.695667] igb 0000:02:00.0: irq 46 for MSI/MSI-X
> > > > [ 1.695670] igb 0000:02:00.0: irq 47 for MSI/MSI-X
> > > > [ 1.723244] igb 0000:02:00.0: added PHC on eth0
> > > > [ 1.723246] igb 0000:02:00.0: Intel(R) Gigabit Ethernet
> > > > Network Connection
> > > > [ 1.723247] igb 0000:02:00.0: eth0: (PCIe:2.5Gb/s:Width x1)
> > > > 00:1e:67:99:86:33
> > > > [ 1.723293] igb 0000:02:00.0: eth0: PBA No: 102100-000
> > > > [ 1.723294] igb 0000:02:00.0: Using MSI-X interrupts. 4 rx
> > > > queue(s), 4 tx queue(s)
> > > > [ 5.763310] igb 0000:02:00.0 eth0: igb: eth0 NIC Link is Up
> > > > 1000 Mbps Full Duplex, Flow Control: RX
> > > > $ sudo journalctl -u systemd-networkd
> > > > -- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So
> > > > 2015-03-22 08:39:39 CET. --
> > > > Mär 20 17:39:31 myhostname systemd-networkd[245]: lo: gained
> > > > carrier
> > > > Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0: link
> > > > configured
> > > > Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0: gained
> > > > carrier
> > > >
> > > > That’s at least three seconds too long. ;-) Is there a way to
> > > > speed that up. At least the operating system should only take
> > > > two or less seconds until I am able to log back in over a
> > > > network connection. It’s bad enough the firmware takes 50
> > > > seconds.
> > >
> > > Are you using auto-negotiation? I assume so, since auto
> > > -negotiation can take that long or longer to link.
> >
> > I am using the default settings. I guess that uses auto-negotiation.
> >
> > > Depending on what you are linking to can also make a difference.
> > > If you want to speed up the link time, you can hard set the speed
> > > and duplex on both the NIC and the device it connects to. That
> > > will speed up the "link up".
> >
> > I have no control over the device the NIC connects to as this is a
> > rented server in a data center.
> >
> > How can I hard set the parameters? No parameter is advertised for
> > that.
>
> # ethtool -s ethX [speed N] [duplex half|full] ... [advertise N] ...
>
> > $ /sbin/modinfo igb | grep parm
> > parm: max_vfs:Maximum number of virtual functions to allocate per
> > physical function (uint)
> > parm: debug:Debug level (0=none,...,16=all) (int)
> >
> > Additionally, is there a fall back if hard setting it does not
> > work. The NIC is the only way to connect to the server so hard
> > setting something incorrectly could result in a big problem.
> >
> > Though the auto-negotiated settings should be safe, I assume.
> >
> > eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
>
> Both sides either need to be forced or both sides need to be auto
> -neg. Otherwise the auto-negotiation process will usually detect
> link (the physical signal) but fail to find duplex (since one side is
> not talking) and default to the lowest common denominator, e.g. half
> duplex. So, you could try forcing speed, it may look right on your
> end but if you have no visibility to the other end it could be
> running at half duplex.
>
> You may be able to speed up the auto negotiation process by
> exclusively advertising 1000 Mbps Full Duplex.
>
> # ethtool -s ethX advertise 0x20
Discussing this on the systemd-devel mailing list in the thread
*networkd: Is auto-negotiation turned off when specifying parameters in
a link file?* [1], I finally got a chance test this.
$ more /etc/udev/rules.d/20-eth0-ethtool.rules
ACTION=="add", SUBSYSTEM=="net", RUN+="/usr/sbin/ethtool -s eth0 advertise
0x20"
$ sudo journalctl -u systemd-networkd
-- Logs begin at Di 2015-06-30 12:11:30 CEST, end at Di 2015-06-30 20:36:58
CEST. --
Jun 30 12:11:30 kpb01 systemd-networkd[395]: lo : gained
carrier
Jun 30 12:11:30 kpb01 systemd-networkd[395]: eth0 : link
configured
Jun 30 12:11:34 kpb01 systemd-networkd[395]: eth0 : gained
carrier
$ s$ sudo journalctl -k | grep igb
Jun 30 12:11:30 kpb01 kernel: igb: Intel(R) Gigabit Ethernet Network Driver
- version 5.0.5-k
Jun 30 12:11:30 kpb01 kernel: igb: Copyright (c) 2007-2014 Intel
Corporation.
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: irq 44 for MSI/MSI-X
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: irq 45 for MSI/MSI-X
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: irq 46 for MSI/MSI-X
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: irq 47 for MSI/MSI-X
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: irq 48 for MSI/MSI-X
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: added PHC on eth0
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: Intel(R) Gigabit Ethernet
Network Connection
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: eth0: (PCIe:2.5Gb/s:Width
x1) 00:1e:67:d7:f6:de
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: eth0: PBA No: 102100-000
Jun 30 12:11:30 kpb01 kernel: igb 0000:03:00.0: Using MSI-X interrupts. 4
rx queue(s), 4 tx queue(s)
Jun 30 12:11:34 kpb01 kernel: igb 0000:03:00.0 eth0: igb: eth0 NIC Link is
Up 1000 Mbps Full Duplex, Flow Control: RX
So, assuming the setting was picked up, there is no improvement.
Currently, the system is faster up than the network device tries to
configure the link. Do you have any other suggestions?
Aren’t there really any other options to easily debug/instrument the
Linux kernel module to be sure where the time is spent and to optimize
it?
Having systems reboot very quickly is important to have short down
times.
Thanks,
Paul
[1] http://lists.freedesktop.org/archives/systemd-devel/2015-April/030408.html
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/
_______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
