FBSD 5.5 and software timers

[M. Warner Losh]

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[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