i386/115054: NTP errors out on startup but restart of NTP fixes problem

[Bruce Evans]

The following reply was made to PR i386/115054; it has been noted by GNATS.

From: Bruce Evans <brde at optusnet.com.au>
To: Bruce Evans <brde at optusnet.com.au>
Cc: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des at des.no>,
        "Chauncey N. Menefee" <cmenefee at prism-grp.com>,
        freebsd-gnats-submit at freebsd.org, freebsd-i386 at freebsd.org
Subject: Re: i386/115054: NTP errors out on startup but restart of NTP fixes
 problem
Date: Thu, 2 Aug 2007 07:03:55 +1000 (EST)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
 
 --0-1632471214-1186002235=:76975
 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
 Content-Transfer-Encoding: QUOTED-PRINTABLE
 
 On Thu, 2 Aug 2007, Bruce Evans wrote:
 
 > On Wed, 1 Aug 2007, [utf-8] Dag-Erling Sm=C3=B8rgrav wrote:
 >
 >> Bruce Evans <brde at optusnet.com.au> writes:
 >>> Several versions of FreeBSD have annoying behaviouor for network
 >>> startup, involving the network not actually being up when ifconfig
 >>> returns and subsequent different mishandling of this by various
 >>> utilities.  [...]
 >>> This problem seems to get worse with each release of FreeBSD and/or
 >>> with newer NICs.  I never noticed fxp or even ed or rl NICs.  Now it
 >>> is barely noticeable with fxp and very noticeable with sk, bge and em
 >>> NICs.
 >>=20
 >> I have never seen this with any of the cards I've used (xl, fxp, rl, re,
 >> sis, bge, sk, msk and probably others, in no particular order).
 >>=20
 >> Perhaps there is a hardware issue involved?  Does the problem occur if
 >> you hardcode the link speed instead of relying on autonegotiation?
 >
 > No difference.  I thought it might be the cheap switch, but going
 > direct makes no difference except to break hard-coding the link speed
 > for bge.  Thie followings is with bge (1Gbps capable but reduced to
 > 100baseTX full-duplex by autonegotiation) under -current, connected
 > to fxp (100baseTX full-duplex by autonegotiation or hard-coded) under
 > FreeBSD-~5.2:
 >
 > [... ping hangs for 11+ seconds; "route get" hangs for 5 seconds]
 
 The fastest way to get a working ping is to insert a delay of >=3D 2.9
 seconds after "ifconfig up" (2.8 doesn't work -- it doesn't even reduce
 the duration of the hangs by 2.8 seconds).  Then "route get" (ping next
 still takes 11+ seconds.  Then ping works instantly:
 
 %%%
 ttyv1:root at besplex:/tmp> ifconfig bge0 down; time ifconfig bge0 up; sleep 2=
 =2E9; t
 ime route get delplex; time route get delplex; time ping -c1 delplex
          0.48 real         0.00 user         0.47 sys
     route to: delplex
 destination: 192.168.2.0
         mask: 255.255.255.0
    interface: bge0
        flags: <UP,DONE,CLONING>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     e=
 xpire
         0         0         0         0         0         0      1500      =
   -3
          0.22 real         0.00 user         0.00 sys
     route to: delplex
 destination: delplex
    interface: bge0
        flags: <UP,HOST,DONE,LLINFO,WASCLONED>
   recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     e=
 xpire
         0         0         0         0         0         0      1500      =
 1200
          0.00 real         0.00 user         0.00 sys
 PING delplex.bde.org (192.168.2.4): 56 data bytes
 64 bytes from 192.168.2.4: icmp_seq=3D0 ttl=3D64 time=3D0.163 ms
 
 --- delplex.bde.org ping statistics ---
 1 packets transmitted, 1 packets received, 0% packet loss
 round-trip min/avg/max/stddev =3D 0.163/0.163/0.163/0.000 ms
          0.00 real         0.00 user         0.00 sys
 %%%
 
 The first "route get" still takes 0.22 seconds, and increasing the sleep ti=
 me
 doesn't reduce that, but it does reduce the expire time -- "sleep N" gives
 an expire time of about -N seconds.
 
 Bruce
 --0-1632471214-1186002235=:76975--