In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
