I have been working on a refclock driver for my ntp installation and I’m not
sure what sort of performance to expect. I’m using the refclock_shm driver
that comes with ntp 4.2.0 with a daemon that takes time from an IRIG time
card and writes it to shared memory. This works okay, but I’d still like to
see better.
When I start the daemon, and before I start NTP, I sync the RTC to the time
card. The two clocks aren’t more than a couple hundred usec off at this
point. When I start NTP, the initial offset is pretty good, but NTP lets the
system clock drift quite a bit before it starts to converge. By quite a bit,
I mean anywhere from 20 to 70 msec offset. After NTP has run for a few
hours, the drift value is good enough to restart NTP and have the total
drift held down below 10 msec before the filter converges. One of the things
that is particularly puzzling is how long it takes NTP to recognize the
hardware clock as a sys.peer. Sometimes as much as five minutes.
Is this the best I can expect? I don’t have any experience with hardware
clocks driving NTP, but I would expect a hardware clock to be treated a
little better by the NTP filters. I’ve only used the standard network
servers up to the present. With some luck, a good drift file, and the iburst
keyword, I can get good synchronization to a network server in about ten
seconds. Shouldn’t I be able to do that with a hardware clock?
I’ve tried posting similar questions on the comp…ntp newsgroup, but I
haven’t been favored with any replies. I’d appreciate any suggestions or
comments besides the obvious “Why are you using NTP?”.
Thanks,
David Kuechenmeister