Very large offset and jitter values afterreboot - NTP

This is a discussion on Very large offset and jitter values afterreboot - NTP ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: Very large offset and jitter values afterreboot

  1. Very large offset and jitter values afterreboot

    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

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

    Nicola Berndt wrote:
    >
    > I have now successfully set up my machine to use a usb-gpd-mouse to set


    Not a good idea. USB serial ports have high latency and jitter and NMEA
    feeds also tend to have high jitter, as they are designed for
    navigation, not for time. You need a PPS signal on an ISA or PCI serial
    port interface.

    > 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


    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.

    >
    > The problem is, that this takes rather long and the computer's job
    > actually is, to provide exact time outdoors right after booting..


    It is possible to get within about 10ms in two or three minutes.

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

    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.


  4. Re: Very large offset and jitter values afterreboot

    David Woolley schrieb:
    > Nicola Berndt wrote:
    >
    >> I have now successfully set up my machine to use a usb-gpd-mouse to set
    >>

    >
    > Not a good idea. USB serial ports have high latency and jitter and NMEA
    > feeds also tend to have high jitter, as they are designed for
    > navigation, not for time. You need a PPS signal on an ISA or PCI serial
    > port interface.
    >
    >

    I konw, but setting up pps failed due to noise on my pps line, wich I
    had not time to really investigate yet. There is a thread connected to
    that some days earlier on this list. I need the nmea-time for now, in
    order to get things started.. PPS will follow very soon..
    >> 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
    >>

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

    Thx for the iburs hint, I will try that.

    Still very strange is that offset, wich also occurs when using
    network-server from a ntp-pool..
    >> The problem is, that this takes rather long and the computer's job
    >> actually is, to provide exact time outdoors right after booting..
    >>

    >
    > It is possible to get within about 10ms in two or three minutes.
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.org
    > https://lists.ntp.org/mailman/listinfo/questions
    >


  5. Re: Very large offset and jitter values afterreboot

    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?

    Best regards,
    .../nico berndt

  6. Re: Very large offset and jitter values afterreboot

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

    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?

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

    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.

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


    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.




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

    Nicola Berndt wrote:
    >>> 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.
    >
    > 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?


    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.


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

    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.

    Also as stated use the -g flag to ntpd


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

    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.



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

    "Richard B. Gilbert" 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.





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

    Nicola Berndt wrote:

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


    Maybe you should first try to find out whether the initial system clock is
    off by 600 ms after reboot, in which case the problem is due to the
    mainboard's RTC, or whether the first NMEA string(s) after power-up are
    sent with that time offset

    Run

    ntpq -c as

    to get the list of associaton IDs from your running NTP daemon, and then run

    ntpq -c "rv assid"

    where you replace assid by the association ID listed by the first command.
    This displays ntpd's filter values. If do this after the first few samples
    the the output should show whether all NMEA strings show the 600 ms offset,
    or only the first (few) entries.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  13. Re: Very large offset and jitter values afterreboot

    Richard B. Gilbert schrieb:
    > 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.


    I actually said "a computer that /cannot take a reboot/". You are
    talking a computer that needs rebooting ... Think of a laptop for
    instance, that runs on batteries. It simply cannot run forever.

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

    >
    > 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".


    I am using a u-blox LEA-4H module, wich can do binary and text modes and
    provides a pps signal on a separate line. The pps part gives me trouble
    at the moment though (noise) and I will either change the module or fix
    the problems soon. Not an option for right now, though.

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


    Why would I have an incorrect value in the drift file? Might that cause
    my offset? As I understood it, the driftfile is being written to over a
    longer period of time and is used to correct a general drift of the
    clock. This might vary under different temperatures maybe, but should be
    rather stable besides, no?

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


    Sure, but /initially/ set the clock quickly and then go on with all the
    ntp-goodies for timekeeping should be in it. That is what I am looking
    for. Being as fast as possible as precise as possible and getting better
    from there on.

    > If you understand such things as phase locked loops (I don't) you'll
    > find the math in RFC-1305.


    Regards,
    .../nico berndt

  14. Re: Very large offset and jitter values afterreboot

    Richard B. Gilbert schrieb:
    > Nicola Berndt wrote:
    >>>> 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.
    >>
    >> 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?

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

  15. Re: Very large offset and jitter values afterreboot

    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?

    nb@komeda-berlin.de

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

  16. Re: Very large offset and jitter values afterreboot

    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!

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

    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?

    Cheers,
    David



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

    Nicola Berndt wrote:

    > I konw, but setting up pps failed due to noise on my pps line, wich I
    > had not time to really investigate yet. There is a thread connected to


    Were you using a direct ISA or PCI interface for the PPS signal? If not
    you can expect a large jitter, if not the multiple counts that you
    reported. Is the PPS being properly level converted to RS 232C level?

    > Thx for the iburs hint, I will try that.


    It's been pointed out that iburst doesn't work for reference clocks.
    There is an implicit assumption that reference clocks are used on proper
    servers and that people only want speed ups on pure clients.

    >
    > Still very strange is that offset, wich also occurs when using
    > network-server from a ntp-pool..


    I'm not sure that I would expect better than 1 second accuracy, reading
    the RTC from the kernel (this is the sort of thing that may vary between
    kernel releases, though). You may find that using hwclock to read the
    RTC does wait for the second boundary. (The RTC can only be read to one
    second, however, one can wait for the change in seconds.)

    You should also expect a significant skew between NMEA time and the true
    seconds, which will be exacerbated by the USB interface.


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

    Nicola Berndt wrote:
    > Richard B. Gilbert schrieb:
    >> 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.

    >
    > I actually said "a computer that /cannot take a reboot/". You are
    > talking a computer that needs rebooting ... Think of a laptop for
    > instance, that runs on batteries. It simply cannot run forever.
    >
    >>> 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?
    >>>

    >> 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".

    >
    > I am using a u-blox LEA-4H module, wich can do binary and text modes and
    > provides a pps signal on a separate line. The pps part gives me trouble
    > at the moment though (noise) and I will either change the module or fix
    > the problems soon. Not an option for right now, though.
    >
    >> 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.

    >
    > Why would I have an incorrect value in the drift file? Might that cause
    > my offset? As I understood it, the driftfile is being written to over a
    > longer period of time and is used to correct a general drift of the
    > clock. This might vary under different temperatures maybe, but should be
    > rather stable besides, no?


    If the temperature of the machine has changed significantly since the
    drift file was written, ntpd will start with an incorrect value for
    drift. If you are doing a cold start, it is usually best to delete the
    drift file. The drift file is overwritten with a new value every hour.
    >
    >> 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.

    >
    > Sure, but /initially/ set the clock quickly and then go on with all the
    > ntp-goodies for timekeeping should be in it. That is what I am looking
    > for. Being as fast as possible as precise as possible and getting better
    > from there on.
    >
    >> If you understand such things as phase locked loops (I don't) you'll
    >> find the math in RFC-1305.

    >
    > Regards,
    > ../nico berndt


    The drift file is written once per hour and contains the then current
    value of the drift in Parts Per Million. Ideally this value will be in
    the range -100 to +100. This allows a warm start to use a reasonable
    approximation of the current drift correction. When doing a cold start,
    the drift file should be deleted prior to starting ntpd.

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

    Richard B. Gilbert wrote:

    >
    > If the temperature of the machine has changed significantly since the
    > drift file was written, ntpd will start with an incorrect value for
    > drift. If you are doing a cold start, it is usually best to delete the
    > drift file. The drift file is overwritten with a new value every hour.


    You would need a large temperature variation to justify this. If the
    devices were exposed to the elements it might be justified. It would
    rarely be justified if they were in living space.

    One consequence of deleting the file is that it forces a frequency
    calibration, which means that, once there are enough samples (about 6)
    to set the clock, it will be allowed to free run for about 15 minutes
    before having any further corrections applied. If you want a tight lock
    in less than 20 minutes, you need a drift file.

+ Reply to Thread
Page 1 of 2 1 2 LastLast