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

Richard B. Gilbert rgilbert88 at comcast.net
Mon Aug 25 13:46:09 UTC 2008

Nicola Berndt wrote:
> 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?

If the temperature of the machine has changed significantly since the 
drift file was written, ntpd will start with an incorrect value for 
drift.  If you are doing a cold start, it is usually best to delete the 
drift file.  The drift file is overwritten with a new value every hour.
>> 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.
> Regards,
> ../nico berndt

The drift file is written once per hour and contains the then current 
value of the drift in Parts Per Million.  Ideally this value will be in 
the range -100 to +100.   This allows a warm start to use a reasonable 
approximation of the current drift correction.  When doing a cold start, 
the drift file should be deleted prior to starting ntpd.

More information about the questions mailing list