Re: simple time server - NTP

This is a discussion on Re: simple time server - NTP ; >>>using the local system time. > >That presupposes that both your clients and servers are located in the >same time-zone. I don't mean "local time" as in 12:00 means solar noon. I mean the time maintained locally on the system, ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: simple time server

  1. Re: simple time server

    >>>using the local system time.
    >
    >That presupposes that both your clients and servers are located in the
    >same time-zone.


    I don't mean "local time" as in 12:00 means solar noon. I mean the time
    maintained locally on the system, as opposed to something that's supposed
    to match a higher stratum NTP server.

    >ntpd needs to be able to adjust the clock. This usually can only be done
    >by the root user.


    Exactly. The simple service I'm trying to provide, for which I
    hypothesized Nptd might be adequate in some mode, has no need to
    adjust the clock. So the fact that Ntpd insists on superuser
    privilege is evidence that my hypothesis was wrong.

    >>> and the fact that it put my kernel in the hardware clock updating
    >>> mode).

    >
    >That's usually considered to be a good thing. Why don't you want it to
    >happen?


    Well, I never said I didn't want it to happen. I said it was evidence
    that Ntpd in the mode I ran it in is not the simple time service I
    described.

    But I also don't want it to happen. For two reasons:

    1) Philosophically, the Linux kernel has no business messing with the
    hardware clock. That's something that makes more sense done by a
    user space process dedicated to that task. (Ntpd might be a good
    choice for that process, but might not).

    2) With somebody constantly correcting the hardware clock, it's impossible
    to tell what the systematic drift rate of it is, so it's impossible
    to keep accurate time while the kernel is not running.

    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.

    >The system clock on most Unix systems operates in UTC. Conversion to the
    >desired time zone is performed by the OS.


    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;
    it generates it -- from two pieces of information: 1) absolute time;
    2) time zone.

    --
    Bryan Henderson Phone 408-621-2000
    San Jose, California
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: simple time server

    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.

  3. Re: simple time server

    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

  4. Re: simple time server

    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

+ Reply to Thread