latency spikes, was Re: [LinuxPPS] slightly offtopic

Udo van den Heuvel udovdh at xs4all.nl
Sun Oct 1 19:45:32 CEST 2006


gnu not unix wrote:
> (waves) 'Morning from California *sips coffee*

:-)

> In message <451FCA61.8090305 at xs4all.nl> you write:
> 
>> Hello,
> 
>> Not really pps related, but how would you fix the situation where you
>> gps works OK but is not chosen as the time source?
> 
> (...)
> 
>> So how come?
> 
>> # ntpq -pn
>>     remote           refid      st t when poll reach   delay   offset jitter
>> ==============================================================================
>> 127.127.1.0     .LOCL.          10 l    9   64  377    0.000    0.000 0.002
>> x127.127.20.0    .GPS.            0 l    -   16  377    0.000  -165.88 3.688
> (...)
> (big list of remote peers deleted)
> 
> Your offset is Rather High. And the jitter is large also. 
> 
> So, the normal ntp mitigation has decided that the remote host
> has the One True Tick and thus, has been chosen as peer.
> 
> Were you running a disk io test or doing a lot of console (not X-windows)
> scrolling? Heavy disk io will tend to clobber your offset/jitter.

Some largish (for this box) downloads.
I then expect the box to keep pps as the main time source since the rest
is 'far' away over the net.
So how can it be that although there is NMEA stuff can still drift to
another host as primary time source?




More information about the LinuxPPS mailing list