[ale] UTC time vs GPS time, not the same???

[mike at trausch.us]

On 01/19/2012 11:52 PM, Ron Frazier wrote:
> I've been doing some additional research on computer time keeping and 
> such.  I just read that GPS time does not account for leap seconds (the 
> seconds periodically added to match UTC time with astronomical time).  
> The statement also said that because of this, there is about a 15 second 
> difference between GPS time and UTC time, even though the clocks are 
> highly accurate.  Does anyone know if this is true?  If so, a GPS clock 
> might not be the best source for time on a computer network, especially 
> if computers being communicated to are being synced to UTC.

The thing is that the difference between GPS time and UTC is well-known,
and the GPS network is about the most accurate time source we can get
our hands on next to getting that signal from WWVB.  Since the delta
between GPS and UTC (and, for that matter, the delta between UTC and
GMT) is well-known and understood, it can easily be compensated for.

I would consider a system that obtains time from either source (GPS or
WWVB) to be a stratum 1 server.  However, I wouldn't advertise it on the
'net as such, because you'd get a lot of traffic.

> I'd also REALLY like to know why the clocks in computers are so widely 
> variable.

The RTC present in most computers is simply cheap, that's all.  If you
need to have a reliable clock attached to the computer, do so.  For 99%+
of all needs, simply staying in sync with systems on the Internet is
good enough.

> I know the software clock in the OS is synced to the hardware 
> clock at boot.  But, after that, it apparently varies widely in 
> performance, even though it's receiving periodic interrupts from the 
> hardware clock.

Load can be a factor there.  Timer interrupts are not always reliably
serviced, and they're not always reliably triggered.  They're good
enough to go on for most work loads, but if you need to have accurate
time kept over the long haul, you use NTP.  That's just the way that it is.

Sure, the operating system could probably steal a single core from the
available set of cores, and it could then perhaps run some tests to
perform better calibration and then use some form of busy-loop to work
from.  However, while such a thing could perhaps increase the ability of
the system to track time reliably, it would be wasteful in both terms of
power spent and the lack of availability of a processor to work with.
Even on a 6, 8, 12 or 16 core computer, dedicating a single core to the
purpose of time-keeping is silly when you can just install an NTP client.

> Is it really the case that some routines switch off the 
> hardware interrupts, causing the software clock to miss cycles?  If 
> that's true, why are user level programs allowed to do that.  You'd 
> think processing the hardware interrupt from the hardware clock would be 
> a pretty important thing.

It is "pretty important" and it is handled as such.  That doesn't mean
that it's "stop-the-world important", though.

For systems where there is a need for truly accurate timing, more
expensive and tightly spec'd components are used (and in the cases where
a system keeps more accurate time than the kernel can with ticks), the
kernel can (since source is available!) be trained to use that more
accurate time source, or even to simply copy its time periodically.

However, it's simply better to use what's already here for that purpose;
NTP is the way to keep your systems in sync with each other, and that's
just the way it is.  :-)

	--- Mike

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                   --- Carveth Read, “Logic”

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 729 bytes
Desc: OpenPGP digital signature
Url : http://mail.ale.org/pipermail/ale/attachments/20120120/001a2003/attachment-0001.bin