Re: ntp rant

[timeOday]
I hate NTP.

And I love it ;-)

It does a simple job in such a ridiculously arcane way.

It's overly complex, and difficult to set up ... I absolutely agree on
that. ntp by multicast or broadcast sounds like cool features, but I
never got them to work. It's overkill for adjusting a simple desktop
clock, but nowadays the resource usage is insignificant compared to
the average b/w, cpu, mem etc a normal desktop computer is equipped
with.

Setting it up with plenty of redundant time servers, one can just let
it run and forget about it. (At our servers, I have scripts graphing
the time differences and sending alarms, though). If the clock gets
seriously out of sync, one needs to restart it. One would also need
to configure the computer to adjust the hw clock after the system
clock, particularly on a laptop that is frequently shut down. I think
the system clock should be in UTC, particularly in countries having
daylight saving time, or at laptops that are frequently passing
timezones.

I've been using it for years and still don't even know how to determine
whether it's doing anything at all. Just because nptq -p spouts its
usual gibberish (not documented in the manpage of course), don't assume
your clock is sync'd.

The gibberish is well documented, and the number one most important
column is "offset", which is the difference between your clock and the
other servers, in milliseconds.

I don't remember where it is documented, probably in the html
documentation shipped with ntp, though nowadays google is often easier
than searching for documentation on the harddisk ...

Informative error messages? Forget it! "no
server suitable for synchronization found." Wow, a single unvarying
sentence that describes every possible issue! Check the syslog for more
and you'll probably find "ntpd exiting." Oh, now I understand!

I agree that this is a problem, I've also experienced problems like
this. There is a debug mode, but not much helpful.

Also, I always wonder for how long I have to wait from the ntp deamon
is started and until the clock actually gets synced.

Isn't there something better? I'm perfectly willing to sacrifice a
few milliseconds of accuracy here or there if that's what it takes.

There is always openntp - my colleague installed it at our servers,
but we had to throw it out of production. Maybe it was just
misconfigured, but our server clocks was really fluctuating. While we
don't need millisecond precision, I found that 250 ms difference
actually can be too much in some circumstances. One usually wouldn't
bother on a laptop, though.

Moreover, it was stopping up very frequently, and (before we got the
alarm scripts installed) the servers could really drift unacceptably much
before we discovered it. I think that while ntpd accepts a slack of
several minutes (half an hour?) openntpd only accepts some seconds,
and sometimes it was not capable of keeping the clocks well enough in
sync. Well, may have been a configuration issue, but I concluded ntpd is
much better than openntpd - which is kind of sad, since I generally
like things to be "open".

For a desktop computer, a cronscript syncing the clock with ntpdate
could be considered - anyway, since memory and cpu is cheap nowadays,
I prefer to have a fire-and-forget daemon there watching the clock.

--
Tobias Brox, 69°42'N, 18°57'E
.

Relevant Pages

  • Re: NTP for dummies
    ... I didn't write the documentation or rfc1305 or NTP project page or the book for dummies and dummies shouldn't read them. ... I believe this can be done because the NTP pages make reference to an "Undisciplined Local Clock" but as with all the documentation it assumes you are already an expert so no simple example is given. ...
    (comp.protocols.time.ntp)
  • Re: Hardware SNTP server
    ... But I certainly see what appears to be a pretty big drawback in the implementation, in that you're throwing away most of what I consider to be the best parts of NTP, just so that you can burn these things into FPGAs. ... Because these servers would not be the same and would not have precisely the same concept of time, to do this would be to completely destroy the NTP protocol itself. ... Even if they're all served by the same atomic clock reference, using serial cable splitters or whatever, those differences in cable lengths would be significant. ... What you want is broadcast, multicast, and manycast servers and clients, so that the load is automatically distributed across the set of servers, and the clients are automatically served by those machines which are close by. ...
    (comp.protocols.time.ntp)
  • Re: ntpq -p show refid as .INIT. even my NTP Servers are synchronized properly.
    ... We are configured NTP in Multiple servers and all the servers are ... getting snchronized properly.We are having primary and Secondary NTP ... reference clock. ... Local BIOS is nothing but the Hardware clock, yes it is the Real time ...
    (comp.protocols.time.ntp)
  • Re: tinker step 0 (always slew) and kernel time discipline
    ... operator intervention is required and the clock will be stepped manually as part of a much larger procedure. ... How about designing your NTP subnet in such a way as to prevent these failures in the first place? ... Your original problem, IIRC, resulted from an extremely poor design of your NTP subnet; two servers each serving its unsynchronized local clock and drifting apart. ... If you really do need NTP the easiest configuration is for your client to use from four to seven servers. ...
    (comp.protocols.time.ntp)
  • Re: tinker step 0 (always slew) and kernel time discipline
    ... Considering the rather large number of servers around here and the national labs, if a step ever occurs, the hardware is to blame. ... This is not a step problem, it is a fatal condition for the applications. ... If the divergence is due to configuring both servers with the local clock driver, this violates the principle that all servers cling to the same timescale, UTC or synthetic. ... Above all, if you are serious about the integrity of the time function and believe in Lamport's happens-before relation, as interpreted by NTP, take very seriously the topics discussed in the white papers linked from the NTP project page. ...
    (comp.protocols.time.ntp)