[ntp:questions] Re: ntp client over satellite and no CMOS battery

David Woolley david at djwhome.demon.co.uk
Sat Sep 10 10:18:29 UTC 2005


In article <1126302219.672905.37320 at o13g2000cwo.googlegroups.com>,
GNWIII at gmail.com wrote:
> Brad Knowles wrote:

> What is the cheapest way to keep ntpd sync'd to 10 s, 1 s, or 0.1 s
> without network?

10s is definitely not possible.  I am pretty sure that 1s is also not
possible.  100ms is, but unless the error is systematic and always in
the same direction, you will get a lot of clock steps.  ntpd is 
designed for keeping time within about 50ms, and preferably within
about 10ms.  It will ignore time sources with uncertainties of 
around 1 second or more.

The cheapest way of maintaining time to about 10s is to use a kernel
PLL loop implementation, without ntpd, calibrate the static drift and
reset from wrist watch about every other or whenever booted.  Most
PCs have a random component to their clock drift of around 30 seconds
a year, unless restarted or suffering from lost interrupts.

> > a sync and then keep you in sync, until you reboot the machine.

> Or the network goes down!

ntpd will continue to try to sync and to maintain the last known 
frequency error (including that from ntp.drift) even when the network
is down.  (If you lose an interface, it may have problems see in 
the network in the future, especially if the IP address is dyamic.)

> time that the network comes up when ntp is sync'd.  In my if-up.local I
> have a "service ntpd restart", which (on fedora core 4) does ntpdate to

Restarting ntpd, rather than re-adding a server, is something that you 
should try not to do.

> get the initial setting, then starts ntpd.  This way, the network
> doesn't "come up" until ntpd has a good chance to sync.  I just leave
> ntpd running after the network goes down.

The network must already be up before ntpdate can work!

If you are using a system with a kernel PLL loop you should poll the
state of that loop, e.g. ntptime, until it is showing synchronised and
with an acceptable maximum error (note that if you are prepared to tolerate
10s errors, the maximum error is clamped to about 16s).

> More work needs to be done for sites with intermittent network access.

But that's not necessarily within the scope of NTP, as NTP is predicated
on maintaining a continual stream of updates and optimising the update
interval automatically.  Something that doesn't do this but uses the 
NTP wire formats is an SNTP implementation, not an NTP one.

What I do for occassional access to to measure the static frequency error,
correct that with ntptime and then, every week or so, run ntpdate -b.
(I haven't tried ntpd -q - the only worry I'd have about that is whether
it would invalidate the kernel PLL setting either whilst trying to
sync or on a failed attempt.

Noting the subject line, I would suggest that anyone who is in a position
to use satellite connections can afford to use GPS reference clocks.




More information about the questions mailing list