[ntp:questions] ntpd wedged again

Chuck Swiger cswiger at mac.com
Mon Feb 13 21:00:06 UTC 2012

On Feb 13, 2012, at 4:06 AM, Dave Hart wrote:
>> A clock is an oscillator and a counter.  (Go read VMWare's
>> "Timekeeping-In-VirtualMachines.pdf" or PHK's
>> "timecounter.pdf" for considerably more detailed description
>> and examples if this is unclear.)
> By your definition, NTP was developed and used for quite a few years
> on operating systems which lacked a clock.  I have to say, as
> impressed as I have always been with NTP and Dr. Mills, I'm even more
> impressed to know he spent a decade doing the impossible.

Um, they connected to reference sources like the NIST WWV / WWVB radio time broadcasts:

"The first use of radios as a primary reference source was in 1981 when a Spectracom WWVB receiver was connected to a Fuzzball at COMSAT Laboratories in Clarksburg, MD [34]. This machine provided time synchronization for Fuzzball LANs in Washington, London, Oslo and later Munich. These LANs were used in the DARPA Atlantic Satellite program for satellite measurements and protocol development. Later, the LANs were used to watch the national power grids of the US, UK and Norway swish and sway over the heating and cooling seasons [30].
DARPA purchased four of the Spectracom WWVB receivers, which were hooked up to Fuzzballs at MIT Lincoln Laboratories, COMSAT Laboratories, USC Information Sciences Institute, and SRI International. The radios were redeployed in 1986 in the NSF Phase I backbone network, which used Fuzzball routers [26]. It is a tribute to the manufacturer that all four radios are serviceable today; two are in regular operation at U Delaware, a third serves as backup spare and the fourth is in the Boston Computer Museum.

These four radios, together with a Heath WWV receiver at COMSAT Laboratories and a pair of TrueTime GOES satellite receivers at Ford Motor Headquarters and later at Digital Western Research Laboratories, provided primary time synchronization services throughout the ARPANET, MILNET and dozens of college campuses, research institutions and military installations. By 1988 two Precision Standard Time WWV receivers joined the flock, but these along with the Heath WWV receiver are no longer available. From the early 1990s these nine pioneer radio-equipped Internet time servers were joined by an increasing number of volunteer radio-equipped servers now numbered over 100 in the public Internet."

[ From www.eecis.udel.edu/~mills/database/papers/history.pdf ]

If you can find a sufficiently old IBM PC lacking the BIOS CMOS RTC/TOD clock and an ISA NIC (or newer hardware where the battery on the motherboard has failed), you might still be able to run a nanoBSD kernel and ntpd, and use a WWVB radio receiver or GPS receiver via the parallel port to provide accurate time reference, and then provide stratum-1 timeservice to the network, even though the local machine itself cannot keep track of time at all when powered off.

> PHK's timecounter.pdf [1] (circa 2002-2004 [1][2]) says "We can
> therefore with good fidelity define 'a clock' to be the combination of
> an oscillator and a counting mechanism."
> Nearly every computer system which provided time-of-day to
> applications _ever_ meets that definition.  The classic tick-based
> software clock I described meets the definition.  The oscillator was
> in some cases simply AC 50/60 Hz supply, much more commonly in the
> home/personal computer era a quartz crystal paired with a hardware
> counter circuit configured as a divider feeding an interrupt line
> triggered 10 to 100 times per second.  The counting mechanism was the
> tick interrupt handler, which incremented the software clock by the
> appropriate amount, 1/10th to 1/100th of a second (plus or minus a
> smidge from adjtime use, where present).

The quartz crystal and counter in an IBM PC BIOS RTC/TOD is a real clock.  It continues to run and count the crystal's oscillations to track time, even if the CPU and operating system is asleep or off.

The time value stored on a commpage is only updated when the OS is running, and becomes stale if the OS is not running.  If you were to do debugging via kdb and Firewire (which lets you do DMA directly to memory) against a halted or panic'ed system, you would discover that the BIOS CMOS RTC/TOD clock continues to run, but the stored time is not updated.

For that matter, the stored value is *always* stale, although it might still be accurate with reduced precision, within a limited period such as one scheduler tick.  However, if the system runs into interrupt processing issues, such as getting stuck in a long-running interrupt handler and dropping some timer interrupts, the value on the page might be further off than you expect, until the next time the system actually reads a "real" clock and corrects the discrepancy, or a timekeeping mechanism like ntpd compensates via external time references.

> As for the VMware paper, it looks quite informative and detailed, but
> I seriously doubt there is anything in there that says anything
> remotely like "a clock is never implemented in software, and is always
> a (possibly virtualized) hardware counter interrogated at the time of
> reading."  Perhaps there's something particular you'd like to draw
> attention to in that voluminous paper to bolster such a claim?

See figure 1 on page 5.  You see an oscillator, a counter, and an interrupt.

"All PC timer devices can be described using roughly the same block diagram, as shown in Figure 1. Not all the devices have all the features shown, and some have additional features, but the diagram is a useful abstraction."

"The oscillator provides a fixed input frequency to the timer device. The frequency might be specified, or the operating system might have to measure it at startup time. The counter might be readable or writable by software. It counts down one unit for each cycle of the oscillator. When it reaches zero, it generates an output signal that might interrupt the processor. At this point, if the timer is set to one-shot mode, it stops; if set to periodic mode, it continues counting. There might also be a counter input register whose value is loaded into the counter when it reaches zero; this register allows software to control the timer period. Some real timer devices count up instead of down and have a register whose value is compared with the counter to determine when to interrupt and restart the count at zero, but count-up and count-down timer designs provide equivalent functionality."

"Common PC timer devices include the programmable interval timer (PIT), the CMOS real time clock (RTC), the local advanced programmable interrupt controller (APIC) timers, the advanced configuration and power interface (ACPI) timer, the time stamp counter (TSC), and the high precision event timer (HPET)."

You might even be able to infer something from the TSC being described as a "time stamp counter" and not a "time stamp clock".

>> to store a low-resolution approximation to "now" was used in pre-OSX
>> MacOS and in Linux, but it isn't being used under FreeBSD.
>> And "Windows Services for Unix" claims to be POSIX-compliant or at
>> least "POSIXy" for NT/Win2k/XP/etc, so the distinction you're drawing
>> just doesn't appear to make sense.
> Windows SFU (ahem) is not Windows.  NT is a microkernel design (in the
> Mach sense, not the NTP sense) with multiple OS personalities built on
> top of it.  My discussion relates only to the Windows subsystem of NT,
> which sometimes has sported OS/2 1.x as well as POSIX/SFU subsystems
> which operate side-by-side with the Windows subsystem, not on top of
> it.  The only thing special about the Windows subsystem compared to
> others is it owns the console/GUI and other subsystem I/O is funneled
> through it.
> The only distinction I'm trying to draw is simply that you are wrong
> to claim a software clock that does not involve interrogating hardware
> is not a clock.

And your references for such a claim are?

Look, even the most basic, primitive timesources like a sundial are measuring an oscillator-- in that case, the revolution of the Earth itself around its axis.  It's only comparatively recently that we've discovered Rubidium and Cesium atomic time standards which are more reliable than solar time (or "International Celestial Reference Frame").

[ ... ]
>> See http://en.wikipedia.org/wiki/Time_Stamp_Counter and references.
> Thanks for the pointer.  I learned some Intel processors I didn't have
> experience with also suffer power-state-related TSC issues.  I also
> note it's a Wikipedia article, which means the reliability as an
> authority is questionable at best.

That's why I suggested following the references, rather than just using wikipedia by itself.


More information about the questions mailing list