FBSD 5.5 and software timers
scheidell at secnap.net
Tue Jul 25 12:31:48 UTC 2006
> -----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
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
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
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
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
LOCAL(0) LOCAL(0) 10 l 6 64 377 0.000 0.000
+a77.coleman.edu 184.108.40.206 2 u 668 1024 377 119.466 -35277.
*meow.febo.com 192.168.1.230 2 u 319 1024 377 87.445 -35443.
+216-228-12-34.d 220.127.116.11 2 u 649 1024 377 143.816 -35295.
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,
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
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.
More information about the freebsd-hackers