Thomas Brathans wrote:
clvrmnky wrote:
[...]
It should be mentioned that using ntpdate in this manner is an egregious
hack. If you run xntp as a daemon, and have a few stratum 2 servers to
key off of, after the daemon settles down, the current time should be
close enough for anything you need to do. This is certainly good enough
to coordinate things like radio-astronomy devices.
The idea is to have a local box act as a local timeserver, so your
webserver, DB server &etc all run xntp using that local timeserver as a
master.
Read the docs for ntpdate (which is soon to be retired). There are a
number of caveats if you need to use it. It is really intended to slew
the local clock into some kind of decent shape prior to starting the ntp
daemon. It's use to arbitrarily and asynchronously set the clock in
this manner is definitely not recommended, and may result in your clocks
*not* being in correct sync.
I was wrong - it actually was a matter of rigths, but I didn't notice it
cause some other stuff went wrong...
But I still think that my solution is a good one, cause right after
synchronising the time with ntpdate a file is timestamped... I see no other
way keeping the time between synchronisation and timestamping that short.
So nobody has the opportunity to manipulate the time before timestamping.
It's your design, of course, but you are not guaranteeing any further
precision on that timestamp by using ntpdate asynchronously. In fact,
you may be guaranteeing the exact opposite!
Depending on your server OS, it may be easy for non-privileged users to
change the system clock (if this is a concern, you have bigger
problems), but generally xntp run as a daemon works closely with your
hardware clock to keep it in tight precision with the stratum 2 (and
eventually, stratum 1) servers it talks to. This precision is much
tighter than a simple call to ntpdate.
AFAIK, ntpdate does not use the hardware clock drift to recalculate the
time, nor is it guaranteed to actually return the "correct" time (within
the advertised specs of ntp). It is a tool intended to slew the clock
into reasonable shape prior to running ntp. For non-critical
applications, it's probably fine. If you require a higher level of
precision or accuracy, then it is certainly not the way to go.
I'm assuming you are running a local timeserver, and your script calls
ntpdate on that server. Hitting random stratum 1 and 2 servers with
ntpdate whenever you want is a bit rude compared with running a proper
ntp server that uses a pool of stratum 2 servers to coordinate when it
synchronizes. i.e., ntp, once setup, is nice and easy on upstream servers.
