FBSD 5.5 and software timers
M. Warner Losh
imp at bsdimp.com
Tue Jul 25 15:35:55 UTC 2006
In message: <B3BCAF4246A8A84983A80DAB50FE72424C6970 at secnap2.secnap.com>
"Michael Scheidell" <scheidell at secnap.net> writes:
: > -----Original Message-----
: > From: Peter Jeremy [mailto:peterjeremy at optushome.com.au]
: > Sent: Tuesday, July 25, 2006 4:00 AM
: > To: Michael Scheidell
: > Cc: freebsd-hackers at freebsd.org
: > Subject: Re: FBSD 5.5 and software timers
: > Basically, when you ask for a 200msec delay, the kernel
: > sleeps until an absolute time. It looks like the handling of
: > absolute time sleeps across time steps was changed.
: > Unfortunately, both approaches are equally valid in different
: > circumstances.
: I agree
: > >It fails within 1 second of getting these types of log
: > entries: Jul 23
: > >15:03:42 audit18 ntpd: time reset -2.497234 s Jul 23 16:03:56
: > >audit18 ntpd: time reset +1.532401 s
: > Rather than focussing on the changed sleep handling, I
: > suggest you concentrate on fixing your clock: Your system
: > clock should not be stepping.
: Except: 20 different machines. Some IBM 300's with 2.0Ghz P4,s, 305 and
: 306's with 2.8P4, some DELL 750's and 850's with 2.8p4 with HTT enabled.
: Even the 5.4 machines shows the bifurcating -1, +2, -2, +1 time resets,
: but timers work more like I want them to.
: > I presume the servers are all stable (ie not stepping) and
: > have a reasonably low delay. If so, I suspect your ntpd PLL
: > has locked up. I've seen problems with some versions of ntpd
: 20 different machines?
That would strongly imply a poor choice of upstream server. Followed
closely by all the machines have the same timekeeping hardware that's
misbehaving. Try different kern.timecounter.hardware settings to see
if the problem goes away.
More information about the freebsd-hackers