[ntp:questions] Very large offset and jitter values after reboot
Unruh
unruh-spam at physics.ubc.ca
Mon Aug 25 17:57:44 UTC 2008
nb at komeda-berlin.de (Nicola Berndt) writes:
>Unruh schrieb:
>> nb at komeda-berlin.de (Nicola Berndt) writes:
>>
>>> 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..
>>
>>> 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?
>>
>>
>> You could try chrony ( assuming you are on Linux) which has the ability to
>> handle the rtc as well and correct for its errors. It settles down much
>> faster than does ntp, and gives tighter control over the clock in many
>> situations.
>>
>Don't know chrony yet, I'll look into it. Thx!
Sorry-- don't bother. chrony does not support hardware clocks ( like your
nmea clock)
It would be really nice if someone installed glue into chrony so it could
use the ntpd hardware drivers. I do not have the time or competence.
More information about the questions
mailing list