In article <3458.bryanh@giraffe-data.com>,
bryanh@giraffe-data.com (Bryan Henderson) wrote:

> 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, although
I did find your wording ambiguous when I first read it.

> 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. Note that, on Linux systems, the kernel
can also be made to do the final filtering of NTP updates, so its
time is more accurate than that seen by the NTP user space code.

> 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;

Laying aside that relativity implies that there is no such thing as
absolute time, all Posix systems, like Linux and typical Unix systems,
keep UTC time, and not for example, TAI, in terms of how it is interpreted
by their time conversion libraries. In particular, Posix time cannot
represent negative leap seconds (23:59:60 UTC) and differences in Posix
time give the wrong duration, in seconds, across leap seconds (there is
a small lobby to change it to do so, but I would argue that this would
confuse most business users, especially when dealing with future times).
As such it actually further from any concept of "absolute" time than
is UTC.

There is a somewhat arbitrary epoch, but that is defined in UTC, and is
a quite round time in UTC.

I don't know what you mean by absolute time, but I think it would have
to be TAI, not UTC.

Note that UTC stands for Universal Coordinated Time and it is not the
name of any country's timezone. (TAI is International Atomic Time.)

What NTP tries to do is to communicate UTC, not the time of a higher
order NTP node, where UTC is ultimately derived from a national
standards atomic clock, which in turn are mutually synchronised
with other such clocks.

> it generates it -- from two pieces of information: 1) absolute time;
> 2) time zone.

That's what you were being told. Again a reasonable thing to tell
someone who is talking about "local time" given the number of people
who expect NTP to communicate wall clock time directly.

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.

Hi Bryan,

On Thursday, August 3, 2006 at 18:10:38 +0000, Bryan Henderson wrote:

> I use Hwclock and its adjtime file to take care of hardware clock
> drift while the kernel is not running, but that works only if Hwclock
> is the only thing that ever sets the hardware clock.

That's a good reason to want to disable the RTC update every 11 minutes.
I heard that some kernels have a setting to disable it. Most don't, but
can be trivially patched. Removing any code setting the RTC, you can
safely have STA_UNSYNC cleared by ntpd, without eleven minutes mode. It
works very well: I also prefer to rely exclusively on hwclock drift
correction, and do so.

Note that the temperature of the RTC chip, and thus its drift rate, may
not be exactly the same when the kernel runs, and during some forms of
"doesn't run". The difference can be huge, around 1s/day.

Thank you for hwclock, Bryan. :-)


Serge.
--
Serge point Bets arobase laposte point net

Hello David,

On Friday, August 4, 2006 at 7:50:55 +0100, David Woolley wrote:

> bryanh@giraffe-data.com (Bryan Henderson) wrote:
>> Philosophically, the Linux kernel has no business messing with the
>> hardware clock.
> 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.

The method used by Linux kernels to set the RTC, last time I checked,
was indeed cheap in terms of processor cycles. But in terms of accuracy,
it's also cheap, dead cheap. The kernel sets the RTC in a frame of
plus/minus 5 milliseconds (with HZ=100) around the intended time, and
without compensation for the exact restart delay of the RTC chip (can
add up to 3 ms of error).

A roughly calibrated hwclock sets the RTC with a 10 or 20 times better
accuracy _at least_. A hundred of microseconds is repeatably achievable.
With such figures, my choice is all done. Even if I must admit that the
processing overhead is *huge* (but I don't care much).


Serge.
--
Serge point Bets arobase laposte point net