[ntp:questions] Stick to PPS, even if the prefer server fails
unruh-spam at physics.ubc.ca
Wed Mar 25 23:48:49 UTC 2009
Dave Hart <davehart at gmail.com> writes:
>On Mar 25, 9:19=A0pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
>> I have no idea why and whether kernel PPS code is any better ( or worse)
>> than say PPS discipline using the shm PPS refclock using parallel port
>> interrupt. Ie, both can discipline
>> to about 1-2usec level.
>Re-read the thread, then. A kernel clock disciplined by PPS allows
>PPS to continue to discipline the clock when ntpd's PPS implementation
>stops doing so because of a prefer peer problem.
I must admit that I am completely confused by this prefer peer problem. I
would think that ntp would use the PPS/refclock preferentially no matter
what external servers are doing. But clearly I am not understanding
something. If it does not that would seem to me to be a bug in ntp, not
something one should be rewriting kernel code to overcome.
>> The main problem is that the ntp model is too slow
>> reacting to temperature induced drifts.
>I'm sure that's your main problem re ntpd, but it's completely
>tangential to the thread.
I was not clear-- the main problem with ntp's ability to discipline the
system clock to better than a few microseconds is that ntp reacts too
slowly to temperature induced drifts. Ie, while ntp might be able to
discipline a clock with a constant rate to sub microsecond precision, ntp
in a running, temperature varying system cannot, in part because of ntp's
reaction to drift rate changes. I think that is germaine to the thread, but
opinions may vary.
Ie, if you use ntp with the addition of temperature measurements to
estimate the temp induced drift rate, you can discipline the clock much
better than with ntp on its own.
However if the only concern was losing PPS discipline due to prefer peer
problems, then I agree this is tangential.
>> >The complete system doesn't serve time to others. It's intention is
>> >monitoring. I'm building this as a diploma thesis for a
>> >telecommunication company. They have a large number of ntp servers
>> >with GPS receivers (called SSU) across the country. So my system only
>> >watches the offsets, that these SSUs have to assure that they are OK.
>> They can monitor only to the msec (or 1/10 msec) =A0level unless the othe=
>r systems are at the same place.
>I think he's monitoring the self-reported offsets between the NTP
>disciplined clock and the local GPS receiver. Network delay would not
>be a factor if so.
I got the impression that he was using this machine to monitor a whole
bunch of other machine distributed over the USA to make sure that their
clocks were well disciplined by their own on board GPS receivers.
More information about the questions