> From: Paul Menzel [mailto:paulepan...@users.sourceforge.net]
> Sent: Tuesday, March 24, 2015 12:53 AM
> To: Kirsher, Jeffrey T
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] igb: Decrease time until link is up
> 
> Dear Jeff,
> 
> 
> thank you for the reply!
> 
> 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


> 
> 
> Thanks,
> 
> Paul
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
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

Reply via email to