[ntp:questions] Re: simple time server

Bryan Henderson bryanh at giraffe-data.com
Fri Aug 4 17:42:42 UTC 2006


>>> I don't mean "local time" as in 12:00 means solar noon.  I mean the time
>
>Most people, asking here, who use the term, mean wall clock time, 

I hate to descend further into this terminology abyss, but I've never
seen "wall clock time" used that way.  I've seen it used plenty to
refer to passage of time such as a wall clock would measure, in
contrast to subset time scales such as CPU time.  E.g. "This program
takes 5 seconds of CPU time but 1 minute of wall clock time to run" or
"the lawyer will take 15 minutes of billable time but four hours of
wall clock time to get us the answer."

Incidentally, I use the same definition of "local time" as others; what
I really said in my original post was "local system time," which I hoped
would prevent confusion with local time.  Didn't work.

>>>   1) Philosophically, the Linux kernel has no business messing with the
>>>      hardware clock.  That's something that makes more sense done by a
>
>In engineering terms, it is the most sensible place to do it, because
>the kernel is in the position to do this at the most accurate time
>without excessive overheads. 

That argues for a system call that says "set the hardware clock to the
system time," not an 11 minute clock maintenance policy inside the
kernel.  The automatic update is so imprecise anyway that a few
microseconds of instruction execution is not noticeable.  The hardware
clock can be set only to a full second.  The kernel rounds the system
time to the nearest full second to do it.

There are (Ntpd-less) people who want a very accurate hardware clock,
who use 'hwclock --systohc' to do much better than this (Hwclock waits
for the system time to reach the top of a second, sometimes holding up
the whole system while it waits, and sets the hardware clock at that
moment -- using estimations of the time it takes for the kernel part
of the processing.  Hwclock could do even better with a system call
designed for that purpose.

>>> The system clock on a Unix system doesn't operate in a time zone at
>>> all.  It keeps absolute time.  The OS doesn't convert to local time;
>
>I don't know what you mean by absolute time, but I think it would have
>to be TAI, not UTC.

There's probaby a better word could have used, but I just meant
timezoneless time -- time by itself without any concept of where the
sun is or what people in some place customarily call a certain moment.

UTC and TAI are both standards for specifying that.  In fact so are
EDT, PST, etc. taken individually.  That's the kind of time that a
Unix system clock measures.  By constrast, a Windows clock keeps local
time.  If you transport a Windows computer from Los Angeles to New
York, you normally tell the kernel to change its clock by 3 hours.  If
you transport a Unix system, you don't.  You just tell the various
programs that report the kernel's time that you'd like to see it in
EST now.

>>> it generates it -- from two pieces of information: 1) absolute time;
>>> 2) time zone.
>
>That's what you were being told.

No, I don't think it is.  Many people think the Unix kernel keeps time
in the Greenwhich time zone as opposed to the New York time zone.
Maybe because the number it uses to represent the time is based on a
moment that is nicely at the beginning of a year in that time zone
(1970).  Whereas on the contrary, the kernel knows nothing of time
zones.  The wording of that posting sounded a lot like that
misconception.

But then, in retrospect, if one thought I meant local time when I said
"local system time," one would have thought I was pretty much an idiot
(to want to an alternative to Ntpd in order to have local time), so maybe
he was trying to come down to my level!

>One other point, anything that uses the NTP wire formats, but doesn't
>use the NTP algorithms from the reference implementation, isn't NTP,
>it is only SNTP.

Thanks for that.  I had started to get that impression by reading the
introduction to the SNTP spec, but I haven't actually read either yet.
I will -- to make sure I don't create more confusion in terms here.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California



More information about the questions mailing list