[ntp:questions] Very large offset and jitter values after reboot
Unruh
unruh-spam at physics.ubc.ca
Mon Aug 25 01:17:30 UTC 2008
"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:
>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.
Lets say his computer runs on a battery (it is outdoors) with a 4 hour
lifetime. And lets say that he only needs to bring up the computer for 5
min. On your suggestion, it would last for 4 hours. Bringing it up for 5
min at a time once a day would last for 80 days. Do you see the
difference?
>> 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?
ntp takes a long time to settle by design. It is due to the clock
discipline proceedure that Mills decided on.
But on a refclock you should be albe to be on poll 4 or less ( 16 sec) so
the settling time should be minutes, not hours.
>>
>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
>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.
>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