FBSD 5.5 and software timers

[Michael Scheidell]

> -----Original Message-----
> From: Steve Watt [mailto:steve at Watt.COM] 
> Sent: Monday, July 24, 2006 6:28 PM
> To: Michael Scheidell
> Cc: hackers at freebsd.com
> Subject: Re: FBSD 5.5 and software timers

> It sounds like ntpd isn't really synchronizing.  If you keep 
> an eye on associations (my finger-memory command is 'ntpq -c 
> peer -c assoc -c rv') over time, you may notice that your 
> machine never decides to synchronize.  Especially interesting 
> is the 'condition' column in the 'assoc' output.

Ntp hasn't changed from 5.4 to 5.4, still acts the same.
Ntp versions look like they are the same, only thing changed is kernel.

ntpdc -c peers (same command) does show the * on one of them, so I
assume 

Also note, this happens across 20 different computers (ntp) but only the
5.5 built systems have a problem with nanosleep().

I guess it depends on the design reason:
Did freebsd decide to change how nanosleep() worked on 5.5? Or is this a
bug?

On 5.4, if you set a 200ms sleep: nanosleep(200*1000) it triggered
reasonably close to 200ms, no matter if the wallclock went forward or
back.

On 5.5, if at 12:32.20000000 you set a 200ms sleep and changed the
wallclock with ntpd back 9 seconds , nanosleep expires in 9 seconds plus
200ms.

Here is a 5.5 system:  20ghz, no HTT, ntpd started with -x:
If I started it without the -x offsets would be in the -2 or +1 area.

ntpq -c  peer -c assoc -c rv
     remote           refid      st t when poll reach   delay   offset
jitter
========================================================================
======
 LOCAL(0)        LOCAL(0)        10 l    6   64  377    0.000    0.000
0.004
+a77.coleman.edu 204.152.184.72   2 u  668 1024  377  119.466  -35277.
422.506
*meow.febo.com   192.168.1.230    2 u  319 1024  377   87.445  -35443.
436.095
+216-228-12-34.d 216.218.192.202  2 u  649 1024  377  143.816  -35295.
441.571
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 14084  9014   yes   yes  none    reject   reachable  1
  2 14085  b414   yes   yes  none  candidat   reachable  1
  3 14086  b614   yes   yes  none  sys.peer   reachable  1
  4 14087  b414   yes   yes  none  candidat   reachable  1
status=0684 leap_none, sync_ntp, 8 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Wed Jul  5 17:49:24 EDT 2006 (1)",
processor="i386", system="FreeBSD/5.5-RELEASE-p2", leap=00, stratum=3,
precision=-18, rootdelay=88.208, rootdispersion=35861.579, peer=14086,
refid=24.123.66.139,
reftime=c87086c3.b381f74c  Tue, Jul 25 2006  8:02:11.701, poll=10,
clock=c8708802.e65819f6  Tue, Jul 25 2006  8:07:30.899, state=4,
offset=-35343.172, frequency=422.004, jitter=462.419, stability=0.119

Does anyone know if this is a design change? The handling of nanosleep()
and the wallclock?

Does 6.1 do this? If if 6.1 works, does this mean that 6.2 will break it
also?
What about posix 'real time' timers? Would I have better luck with them
across os versions?

> 
> As for whys, it rather depends on what you see from the ntpq commands.
> 

Could still be, but there seems to be no way to fix it.
This isnt a hardware problem, its 20 different computers, ibm 300,
305,306's, p4 2.8, and 2.0's,
Dell 750's and 850's with p4 2.8's with HTT.