Date: Tue, 25 Jul 2006 17:59:46 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Michael Scheidell <scheidell@secnap.net> Cc: freebsd-hackers@freebsd.org Subject: Re: FBSD 5.5 and software timers Message-ID: <20060725075946.GA728@turion.vk2pj.dyndns.org> In-Reply-To: <44C4EB9D.1060106@secnap.net> References: <44C4EB9D.1060106@secnap.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 2006-Jul-24 11:47:41 -0400, Michael Scheidell wrote: >This software timer was resetting a 1 second hardware watchdog timer. >Every 200ms, I sent a reset to the hardware WDT. >Everything worked on 5.4, but I am getting failures on 5.5 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. >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. >if -2.49, and we were inside of the nanosleep() and I was expecting a=20 >200ms sleep, I get 2600ms. >(yes, I think I do. the 1 second hardware timer on the WDT triggers if=20 >not reset every 1000ms (1 second)) Say the time is 12:34:56.789 and you do nanosleep(200msec). This is implemented as "sleep until 12:34:56.989". When you set the clock back by 2.49 seconds, it then takes an additional 2.49 seconds (a total of 2.69 seconds) until the timer expires. >ntpd using strata 2 ntp server, with 2 other backups. 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 that they can lock at +/-300ppm and just step regularly. I'm not exactly sure what triggers it but it seems to be exacerbated by noisy time servers (eg via a heavily loaded network link). A work-around is to delete ntp.drift and restart ntpd. You might like to enable some of the ntpd statistics gathering and see if anything anomolous is occurring. --=20 Peter Jeremy --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFExc9y/opHv/APuIcRAnJTAKCQeKWYEE/3MScGtt6zTrn0b2Y9/wCgrJEk 8AqMXSEBQpJpYCpSlBSFNrc= =lP4P -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060725075946.GA728>