[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Link up wait timeout [was: Bug#537271: netcfg: new version of gateway reachability patch]



Matthew Palmer wrote:
> On Wed, Feb 09, 2011 at 02:52:53AM -0500, Robert Edmonds wrote:
> > btw, (unrelated to #537271), it seems to me that 3 seconds is a fairly
> > short value for NETCFG_LINK_WAIT_TIME.  i'm pretty sure i've seen
> > link-up take longer than that on occasion before, depending on NIC
> > chipset, switch, autonegotiation latency, etc.
> 
> I've been led to believe by people who should know (a Linux netdev
> maintainer) that autonegotiation *should* take on the order of 500ms.

perhaps.  and if autonegotiation fails?

as an unscientific experiment i plugged a 3com 10bT hub (pre-802.3u, no
autonegotiation) into a an intel 82574L gigabit NIC on my desktop.  i
tried bringing up the interface first (ip link set up) and then plugging
the connection, as well as plugging the connection followed by bringing
up the interface, and then reading the timestamps in /var/log/kern.log.
after repeating the experiment several times in both configurations it
always took about 2.2 seconds to report link-up:

Feb  9 15:57:19 chase kernel: [673424.095647] ADDRCONF(NETDEV_UP): eth1: link is not ready
Feb  9 15:57:21 chase kernel: [673426.309855] e1000e: eth1 NIC Link is Up 10 Mbps Half Duplex, Flow Control: None
Feb  9 15:57:21 chase kernel: [673426.309919] 0000:08:00.0: eth1: Autonegotiated half duplex but link partner cannot autoneg.  Try forcing full duplex if link gets many collisions.
Feb  9 15:57:21 chase kernel: [673426.309920] 0000:08:00.0: eth1: 10/100 speed: disabling TSO
Feb  9 15:57:21 chase kernel: [673426.311109] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

> > 5 - 10 seconds would be a more conservative default, given that
> > there's no penalty if link-up occurs before the timeout.
> 
> Sure, there's no penalty is link-up occurs, but what about all the people
> for whom link-up doesn't occur -- say, because they're on a wireless link,
> or their chipset doesn't work right, or it's trying on a link that isn't
> actually up?  Every delay screws them over more and more.

not really.  false negatives are more harmful here.  if it takes 7
seconds instead of 3 for netcfg to report link-up failure, the user will
still be disappointed -- because they have no link, not because it took
a few extra seconds for the error to be reported.

-- 
Robert Edmonds
edmonds@debian.org


Reply to: