Very large offset and jitter values afterreboot - NTP

This is a discussion on Very large offset and jitter values afterreboot - NTP ; nb@komeda-berlin.de (Nicola Berndt) writes: >Unruh schrieb: >> nb@komeda-berlin.de (Nicola Berndt) writes: >> >>>>> 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 >>>> ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: Very large offset and jitter values afterreboot

  1. Re: Very large offset and jitter values after reboot

    nb@komeda-berlin.de (Nicola Berndt) writes:

    >Unruh schrieb:
    >> nb@komeda-berlin.de (Nicola Berndt) writes:
    >>
    >>>>> 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.

    >>
    >>
    >>> Just tried the iburst option, but I had to figure it only works with the
    >>> server command, not on refclocks.

    >>
    >> Oops forgot you have a gps clock. chrony does not work with refclocks.
    >>
    >>
    >>> 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?

    >>
    >> It sounds like your rtc has problems. You can use hwclock to compensate for
    >> rtc problems.


    >Well, I tried 'hwclock --systohc' with no different result. More
    >suggestions?


    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




    >nb@komeda-berlin.de


    >tel: +49 30 / 6730 1395
    >fax: +49 30 / 6730 1394
    >gsm: +49 163 / 243 6802
    >________________________________


  2. Re: Very large offset and jitter values after reboot

    nb@komeda-berlin.de (Nicola Berndt) writes:

    >Unruh schrieb:
    >> nb@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.




  3. Re: Very large offset and jitter values after reboot

    "David J Taylor" writes:

    >Nicola Berndt wrote:
    >> Richard B. Gilbert schrieb:

    >[]
    >>> 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.

    >>
    >> Yes, I do. Strange, right?


    >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?


    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)




    >Cheers,
    >David




  4. Re: Very large offset and jitter values after reboot

    Hello Nicola,

    On Sunday, August 24, 2008 at 16:12:51 +0000, Nicola Berndt wrote:

    > I did a 'hwclock --systohc' once things are settled, but with no luck.


    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

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2