>
> From: Richard B. Johnson <root@chaos.analogic.com>
> >The whole yy:mm:dd:hh:mm:ss ball of wax must be synchronous. At
> >last reading, this was done by "Convention", i.e., international
> >agreement. The drift of Earth time from Celestial time is periodically
> >taken out by leap-seconds.
>
> I'm curious: How does the Kernel handle the leap-second? Does it
> record a minute with 61 seconds somewhere? If so, doesn't it
> break programs which count on (SECONDS_PER_MINUTE == 60)?
>
> Or does something like ntpd spread that leap second out over
> some period of time? Is there some "Convention" of the rate
> to re-adjust?
You know there was an early Unix that allowed a 61 second minute.
But this was because, early on, there was little understanding
about the nature of time as used by Computers. If you use the
'C' runtime library, leap-seconds mean nothing. They are never
presented to application code. If you were to break down the
time_t variable into its components, you never see a leap-second.
The kernel uses a software PLL to slowly adjust the machine's
idea of time. However, if you set the time, the new time take
effect immediately.
How the leap second is supposed to work is similar to what we do
here. Every night around midnight (actual time is not important), crond
executes a task that does:
rdate time-A.timefreq.bldrdoc.gov
clock -w
This sets our idea of time to that of NIST, then sets the CMOS clock.
This happends every night on our machine that is used for a local
name-server and time-server. I actually use a program that is a bit
better than `rdate` because it takes into account the reply time from
NIST. It's called nettime.
Since NIST handles leap-seconds itself, the time will always be near
what NIST says it should be. The time could be off, on the average, as
much as a 1/2 second, but it cannot drift.
If somebody was writing a file at the time, the update time (UTIME) of the
file could actually be earlier than its creation time, but only for that
instant. If this was a problem, and I have only heard theoretical
balderdash about it being a problem, no actual evidence of anything
such as this even occurring; one could run `rdate` as such a high
priority that it completes before anything else is allowed to run.
No software that uses time should ever be written like this:
(void)time(&stop);
stop += WAIT_SECONDS;
(void)time(&now);
while(now != stop)
{
DO_SOMETHING;
(void)time(&now);
}
The condition where "now" equals "stop" may never occur because the
CPU could be taken away for several seconds, especially when the OS
has to handle an exception. Or, somebody could reset the time.
You always test for something that must eventually happen like greater
or less.
Note that NIST has some good information and free software source code
available on their site, time.nist.gov.
Cheers,
Dick Johnson
***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.105 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu