Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!udel.edu!Mills
From: Mills@udel.edu
Newsgroups: comp.protocols.time.ntp
Subject: Re:  NTP and the infamous SPARC clock problem (again)
Message-ID: <9012031311.aa05921@huey.udel.edu>
Date: 3 Dec 90 18:11:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 22

Rich,

The problem has been reported to be lost clock ticks due the practice
of disabling interrupts while dirty pages are swapped to backing store,
which occurs about once every 30 seconds. Apparently, this can result
in periods up to several hundred milliseconds during which clock
interrupts are stuck. It has also been reported that the fix of choice
is to dump the System-V clock code in favor of the old 4.3bsd clock code.
This has not been verified here. Diskless clients should have no trouble,
as should not workstations that don't dirty too many pages/second. I
do not know what if anything Sun is doing about this. Our gaggle of
SPARCs keep pretty good time, but they are hardly stressed and usually
dirty only the fileserver's pages.

It is possible to widen the aperture NTP uses to distinguish clock
jitter from broken clocks. Ex box this aperture is +-128 ms, but could
easily be made much larger. However, if a few hundred milliseconds is
being yanked from under it every 30 seconds or so, NTP is not the protocol
of choice. Run NTP on a stable platform somewhere and a bugged timed to
keep the rascals in line.

Dave