Unruh schrieb:
> [EMAIL PROTECTED] (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!
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
