[ntp:questions] Very large offset and jitter values after reboot

Nicola Berndt nb at komeda-berlin.de
Mon Aug 25 08:57:42 UTC 2008

Richard B. Gilbert schrieb:
> Nicola Berndt wrote:
>> Richard B. Gilbert schrieb:
>>> Nicola Berndt wrote:
>>>> Hello,
>>>> I have now successfully set up my machine to use a usb-gpd-mouse to set 
>>>> the time. Strangely every time I reboot I get results like this, wich 
>>>> settle down after a (not so short) while:
>>>>     remote           refid      st t when poll reach   delay   offset  
>>>> jitter
>>>> ==============================================================================
>>>> GPS_NMEA(0)     .GPS.            0 l    9   64   37    0.000  -580.75 
>>>> 3965.19
>>>> The problem is, that this takes rather long and the computer's job 
>>>> actually is, to provide exact time outdoors right after booting..
>>>> I already tried what would happen if I did a 'hwclock --systohc' once 
>>>> things are settled, but with no luck. My driftfile btw. says -35.666 - 
>>>> looks good to me - and I am very worried about the huge jitter...
>>>> Any ideas for me, anyone?
>>>> Thx and regards,
>>>> ../nico berndt
>>> 1.  Don't reboot!  My Windows, Linux, Solaris, and OpenVMS systems will 
>>> all run until the power goes off for longer than the run time of my UPS.
>>> 2.  Start ntpd with the "-g" switch.  The -g switch tells it to get and 
>>> set the correct time.  Following startup, ntpd will discipline the clock 
>>> in the usual way.  It may take a relatively long time, around thirty 
>>> minutes, to settle into really tight synchronization.
>>> _______________________________________________
>> 1, As I wrote already, the device has to work outdoors, where there is 
>> no unlimited power-source, so I have to reboot. Also I think, a computer 
>> that cannorttake a reboot has a problem wich needs to be adressed. Just 
>> my opinion, though..
> I'd say that a computer that needs to be rebooted other than following a 
>   power failure or a hardware failure, has something wrong with its 
> hardware or operating system.  Once upon a time, Windows needed regular 
> reboots but this was largely cured by Windows 2000.  Windows XP can run 
> for months between reboots.

I actually said "a computer that /cannot take a reboot/". You are 
talking a computer that needs rebooting ... Think of a laptop for 
instance, that runs on batteries. It simply cannot run forever.

>> 2, I forgot to mention that I already do so, still takes too long to 
>> settle. I also don't understand what is taking so long, since - jitter 
>> or not - the nmea time is precise enough to just quickly set the time at 
>> startup and then let things go their way. Can someone explain that to me?
> I don't believe you said what kind of GPS receiver you were using.  It 
> sounds as if your are using a receiver designed for navigation rather 
> than timing.  Timing receivers usually use a binary protocol rather than 
> NMEA.  Timing recievers also typically have a Pulse Per Second (PPS) 
> output which provides a very precise indication of the "top of the second".

I am using a u-blox LEA-4H module, wich can do binary and text modes and 
provides a pps signal on a separate line. The pps part gives me trouble 
at the moment though (noise) and I will either change the module or fix 
the problems soon. Not an option for right now, though.

> Even on a warm start with a good value in the drift file, ntpd can take 
> up to thirty minutes to pull in to tight synchronization.  If you are 
> only looking for the seconds you may never notice the time required to 
> synchronize within, say, 100 microseconds.
> If you are cold starting ntpd, delete the drift file before starting! 
> No drift file is better than one with an incorrect value for drift.

Why would I have an incorrect value in the drift file? Might that cause 
my offset? As I understood it, the driftfile is being written to over a 
longer period of time and is used to correct a general drift of the 
clock. This might vary under different temperatures maybe, but should be 
rather stable besides, no?

> Last but not least, ntpd uses some complex algorithms to discipline the 
> clock.
> It's NOT just a set the time and forget it.  The typical computer clock 
> is NOT designed for high accuracy; left to itself it might be off by as 
> much as 500 PPM or 43 seconds per day.  Ntpd makes the clock tick at 
> intervals as close as possible to one tick per second.

Sure, but /initially/ set the clock quickly and then go on with all the 
ntp-goodies for timekeeping should be in it. That is what I am looking 
for. Being as fast as possible as precise as possible and getting better 
from there on.

> If you understand such things as phase locked loops (I don't) you'll 
> find the math in RFC-1305.

../nico berndt

More information about the questions mailing list