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.

Regards,
-- 
-Chuck

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to