[ntp:questions] high precision tracking: trying to understand sudden jumps

[Unruh]

"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>starlight at binnacle.cx wrote:
>> Hello,
>> 
>> I'm trying to configure a small network for high precision time. 
>> Recently acquired an Endrun CDMA time server that runs like 
>> a dream, tracking CDMA time to about +/- 5 microseconds.
>> 
>> The clients are a rag-tag assembly of diverse systems including 
>> a Centos 4.5 Linux i686, Linux x86_64, Sun Ultra 10, Sun Ultra 80, 
>> IBM RS/6000 44p, Windows 2003 X64, and a Windows XP laptop.
>> 
>> All are configured to prefer the Endrun clock and poll it on a 
>> 16 second interval.  All are attached to a single SMC gigabit 
>> Ethernet switch with only the Endrun and two Sun systems running 
>> at a lower speed of 100 MBPS.  Close to zero network traffic
>> and system loads.
>> 
>> All systems are running 'ntpd' 4.2.4p4.  Compiled NTP native 
>> 64-bit for the Windows X64 system.  [A #ifdef tweak to 
>> 'intptr_t' and 'uintptr_t' is required, will provide patch if 
>> desired].
>> 
>> It generally is working well, with the systems tracking anywhere 
>> from +/- 100 microseconds to +/- 500 microseconds most of the 
>> time.
>> 
>> However once or twice a day, all the systems experience a 
>> random, uncorrelated time shift of from one to several 
>> milliseconds.  
><snip>

>Forcing the poll interval to 16 seconds is not always a good idea!
>Ntpd will select a poll interval, generally starting at 64 seconds, and 
>ramping up to as long as 1024 seconds as the clock is beaten into 
>submission!

It is his network, he is not going to overload it. So, if he wants a 16 sec
poll interval that is up to him. 
I agree it is not a good idea for remote servers, but on his own system it
is fine. 


>Directly connected refclocks are frequently polled at shorter intervals
>but I don't think your refclock is "directly connected" in the same 
>sense that a clock working through a serial or parallel port is directly
>connected!

>A clock connected via ethernet with all the latencies and jitter 
>thereunto appertaining is no different than any other network server and 
>should be polled in the same manner!

??? The longer polls are in order not to swamp the remote server whith
10000 people all polling every 16 sec ( or 1 sec) There is nothing in ntp
itself that mandates a longer poll interval. In fact a shorter poll
interval makes ntp much more responsive to changes ( clock drifts, etc)



>The very short poll intervals correct large errors quickly and the very 
>long intervals correct small errors very accurately!

No for a properly designed system both should be corrected.