Very large offset and jitter values afterreboot

[email]nb@komeda-berlin.de[/email] (Nicola Berndt) writes:
[color=blue]
>Unruh schrieb:[color=green]
>> [email]nb@komeda-berlin.de[/email] (Nicola Berndt) writes:
>>[color=darkred]
>>>>> 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
>>>> You've not had your first 8 samples yet. You haven't actually had
>>>> enough for ntpd to act on the data. You can speed that up with iburst,
>>>> but ntpd will still take a long time to get a very tight lock. jitter
>>>> will reduce as you get to the eight samples. The good? think, is that
>>>> you are more than 128ms out, so that ntpd will step the time, to zero
>>>> the offset, once it gets enough samples.[/color]
>>
>>[color=darkred]
>>> Just tried the iburst option, but I had to figure it only works with the
>>> server command, not on refclocks.[/color]
>>
>> Oops forgot you have a gps clock. chrony does not work with refclocks.
>>
>>[color=darkred]
>>> What really puzzles me, is the stoical 600 ms offset after rebooting.
>>> Since it is always returning having more or less the same amount, I
>>> should really be able to get rid of it, no?[/color]
>>
>> It sounds like your rtc has problems. You can use hwclock to compensate for
>> rtc problems.[/color][/color]
[color=blue]
>Well, I tried 'hwclock --systohc' with no different result. More
>suggestions?[/color]

Try using the --directisa option both when you write the rtc on
shutdown and when you read it on bootup. If you have a very modermn machine
with HPET the rtc driver is badly munged. It should only be out by about
13ms, not 600 however.

Also look at the /etc/adjtime file



[color=blue]
>nb@komeda-berlin.de[/color]
[color=blue]
>tel: +49 30 / 6730 1395
>fax: +49 30 / 6730 1394
>gsm: +49 163 / 243 6802
>________________________________[/color]

[email]nb@komeda-berlin.de[/email] (Nicola Berndt) writes:
[color=blue]
>Unruh schrieb:[color=green]
>> [email]nb@komeda-berlin.de[/email] (Nicola Berndt) writes:
>>[color=darkred]
>>> 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..[/color]
>>[color=darkred]
>>> 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?[/color]
>>
>>
>> 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.
>>[/color]
>Don't know chrony yet, I'll look into it. Thx![/color]

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.

"David J Taylor" <david-taylor@blueyonder.neither-this-bit.nor-this-part.co.uk> writes:
[color=blue]
>Nicola Berndt wrote:[color=green]
>> Richard B. Gilbert schrieb:[/color]
>[][color=green][color=darkred]
>>> 600 ms seems to be a large error for a warm start. Are you using
>>> "-g" to start ntpd? Forgive me if this has already been asked and
>>> answered.[/color]
>>
>> Yes, I do. Strange, right?[/color][/color]
[color=blue]
>Is there any chance that the PPS you are using is 400ms or 600ms long, and
>you are actually syncing off the wrong edge of the pulse - and not the
>edge which co-incides with the UTC second?[/color]

He is not using pps-- his pps line is too noisy. He is using nmea strings.
Now, we know that the nmea string is long (esp at the default 4800bd)
so it might be that ( needs to use one of the fudges to adjust the time)



[color=blue]
>Cheers,
>David[/color]

Hello Nicola,

On Sunday, August 24, 2008 at 16:12:51 +0000, Nicola Berndt wrote:
[color=blue]
> I did a 'hwclock --systohc' once things are settled, but with no luck.[/color]

First verify that hwclock worked well, immediatly looking at the
adjtimex "system-cmos" offset value:

| # hwclock --systohc ; adjtimex --compare=1
| --- current --- -- suggested --
| cmos time system-cmos error_ppm tick freq tick freq
| 1220000702 0.000007

If the offset is not a sane few microseconds, then let's see if
hwclock --systohc --debug can reveal something.


Serge.
--
Serge point Bets arobase laposte point net