Date: Tue, 25 Jul 2006 09:34:29 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: scheidell@secnap.net Cc: freebsd-hackers@freebsd.org Subject: Re: FBSD 5.5 and software timers Message-ID: <20060725.093429.-1648696470.imp@bsdimp.com> In-Reply-To: <B3BCAF4246A8A84983A80DAB50FE72424C6970@secnap2.secnap.com> References: <B3BCAF4246A8A84983A80DAB50FE72424C6970@secnap2.secnap.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <B3BCAF4246A8A84983A80DAB50FE72424C6970@secnap2.secnap.com>
"Michael Scheidell" <scheidell@secnap.net> writes:
: > -----Original Message-----
: > From: Peter Jeremy [mailto:peterjeremy@optushome.com.au]
: > Sent: Tuesday, July 25, 2006 4:00 AM
: > To: Michael Scheidell
: > Cc: freebsd-hackers@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[473]: time reset -2.497234 s Jul 23 16:03:56
: > >audit18 ntpd[473]: 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.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060725.093429.-1648696470.imp>