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

Richard B. Gilbert rgilbert88 at comcast.net
Mon Aug 25 00:10:49 UTC 2008

Nicola Berndt wrote:
> Richard B. Gilbert schrieb:
>>Nicola Berndt wrote:
>>>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  
>>> GPS_NMEA(0)     .GPS.            0 l    9   64   37    0.000  -580.75 
>>>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.

> 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".

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.

Last but not least, ntpd uses some complex algorithms to discipline the 
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.

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

More information about the questions mailing list