Stabilizing the drift file? - NTP

This is a discussion on Stabilizing the drift file? - NTP ; Hi, did anybody else have the problem, to have to stabilize the frequency discipline faster than the normal 15 minutes to hours? Does any solution exist? We have here the requirement to have a replaced board (a fresh one from ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Stabilizing the drift file?

  1. Stabilizing the drift file?


    Hi,

    did anybody else have the problem, to have to stabilize the frequency discipline
    faster than the normal 15 minutes to hours? Does any solution exist?

    We have here the requirement to have a replaced board (a fresh one from the factory,
    where a correct content of the drift file is unknown) up after 5 minutes in a cluster,
    which also means, that its time does not stray more than 10ms (within the cluster).

    Any tips?
    We tried here to "play" with minpoll, burst, initial drift files (value 0).


    Regards, Robert


  2. Re: Stabilizing the drift file?

    "Robert Wachinger" wrote in message
    news:ek175f$sp9$1@daniel-new.mch.sbs.de...
    [...]
    > We have here the requirement to have a replaced board (a fresh one
    > from the factory, where a correct content of the drift file is
    > unknown) up after 5 minutes in a cluster, which also means, that
    > its time does not stray more than 10ms (within the cluster).
    >
    > Any tips?
    > We tried here to "play" with minpoll, burst, initial drift files
    > (value 0).


    Iburst would start you with a low offset. But that has really
    absolutely nothing to do with intrinsic frequency error.

    Can you run (NTP on) the board outside the cluster? Your problem is
    that you don't know the correct drift value. It seems simple then:
    you should find out.

    I'm not sure if limiting maxpoll is guaranteed to keep your offset
    low the way running ntpdate often would; frankly I doubt it.

    Doesn't the cluster allow you to add nodes in standby mode?

    Groetjes,
    Maarten Wiltink



  3. Re: Stabilizing the drift file?

    Maarten Wiltink wrote:
    > "Robert Wachinger" wrote in message
    > news:ek175f$sp9$1@daniel-new.mch.sbs.de...
    > [...]
    >> We have here the requirement to have a replaced board (a fresh one
    >> from the factory, where a correct content of the drift file is
    >> unknown) up after 5 minutes in a cluster, which also means, that
    >> its time does not stray more than 10ms (within the cluster).
    >>
    >> Any tips?
    >> We tried here to "play" with minpoll, burst, initial drift files
    >> (value 0).


    > Iburst would start you with a low offset. But that has really
    > absolutely nothing to do with intrinsic frequency error.


    > Can you run (NTP on) the board outside the cluster? Your problem is
    > that you don't know the correct drift value. It seems simple then:
    > you should find out.


    That would mean additional manual handling (and is therefore costful).

    > I'm not sure if limiting maxpoll is guaranteed to keep your offset
    > low the way running ntpdate often would; frankly I doubt it.


    So no idea, to reduce the time until a drift value is stable enough.

    > Doesn't the cluster allow you to add nodes in standby mode?


    Hm, nice idea. Maybe that could work ...

    Regards, Robert


  4. Re: Stabilizing the drift file?

    Robert Wachinger wrote:
    > Hi,
    >
    > did anybody else have the problem, to have to stabilize the frequency discipline
    > faster than the normal 15 minutes to hours? Does any solution exist?
    >
    > We have here the requirement to have a replaced board (a fresh one from the factory,
    > where a correct content of the drift file is unknown) up after 5 minutes in a cluster,
    > which also means, that its time does not stray more than 10ms (within the cluster).
    >
    > Any tips?
    > We tried here to "play" with minpoll, burst, initial drift files (value 0).
    >
    >
    > Regards, Robert
    >


    Use "iburst" on all your server statements in ntp.conf. Be sure to use
    -q as an option when you start ntpd. This may not be enough but there
    is not much more you can do. A very good server or several very good
    servers may also help. The goodness of a server is strongly dependent
    on the quality of the network path between the server and your client.

    Is it possible to run this new board standalone before joining the
    cluster? If so, that could get you a valid drift file.

  5. Re: Stabilizing the drift file?


    Hi Dave,

    mills@udel.edu wrote:
    > Robert,


    > I've had this discussion literally hundreds of times over the last 25
    > years.


    So this seems to be a heavy case of a FAQ. (I did not find a proper topic
    in the FAQ, hope I was not too blind).

    Nevertheless: Thank you for your clear answer. It helps.

    Robert


  6. Re: Stabilizing the drift file?

    mills@udel.edu wrote :

    > When first starting ntpd without the drift file, by default the state
    > machine takes fifteen minutes to directly compute the initial frequency
    > estimate within about 1 PPM, then enables the native clock discipline
    > algorithm.


    Hi Dave.

    You statement is correct for the complete variety of platforms ntp
    supports.
    However, on a Linux system (with at least 1us time resolution) you can
    get reasonable estimates for the drift much faster.
    Have a look at my script in
    https://ntp.isc.org/bugs/show_bug.cgi?id=742
    Changing the stepout as you proposed should give the same results (on
    Linux).
    Unfortunately, I didn't understand the meaning of 'stepout' from the
    documentation. ;-(

    Bye
    Juergen


  7. Re: Stabilizing the drift file?

    Juergen,

    No, you can't always measure the frequency accurately. It depends on the
    initial offset when you start and what happens after the initial
    frequency measurement. As most folks don't want to set the clock
    directly unless forced, the daemon allows an initial offset of up to the
    step threshold (128 ms) and does the best it can after the stepout
    interval (900 s). Note that the code carefully separates the frequency
    measurement from the time offset measurement, so even after an accurate
    frequency measurement the discipline has to wrangle both the time and
    frequency when the initial time is as much as 128 ms in error. This
    initial transient can take several hours to dissipate.

    This could be avoided by forcefully setting the clock at initial
    startup, but in some systems the setting function can have a large error
    in and of itself. The only workaround would be to disable all
    applications until the residual offset was within the tolerance, circa
    10 ms. Setting the stepout interval something less (300 s) moves up the
    time the discipline is enabled, but brings with additional error due to
    the expected error in the offset measurements. For instance, if the
    expected error was 10 ms in a 300-s stepout interval, the maximum
    frequency error could be as high as 67 PPM. The discipline could take up
    to a day to amortize this error.

    Dave

    Juergen.Salm@siemens.com wrote:
    > mills@udel.edu wrote :
    >
    >
    >>When first starting ntpd without the drift file, by default the state
    >>machine takes fifteen minutes to directly compute the initial frequency
    >>estimate within about 1 PPM, then enables the native clock discipline
    >>algorithm.

    >
    >
    > Hi Dave.
    >
    > You statement is correct for the complete variety of platforms ntp
    > supports.
    > However, on a Linux system (with at least 1us time resolution) you can
    > get reasonable estimates for the drift much faster.
    > Have a look at my script in
    > https://ntp.isc.org/bugs/show_bug.cgi?id=742
    > Changing the stepout as you proposed should give the same results (on
    > Linux).
    > Unfortunately, I didn't understand the meaning of 'stepout' from the
    > documentation. ;-(
    >
    > Bye
    > Juergen
    >


  8. Re: Stabilizing the drift file?

    Hi Dave.

    > This could be avoided by forcefully setting the clock at initial
    > startup


    That's exactly what we do.

    You have to know that Robert an I are working on the same project.
    Robert is a systems engineer of the platform we use to build our
    device.

    The requirements of max. 100ms external offset, max. 10ms internal
    offset an 5 minutes until service availability are coming from our
    requirement specification. ;-)
    And we are always talking about a reboot scenario. So we don't need to
    compensate large offsets.

    What we do now during reboot is
    a) Measure the drift with my script for 2 seconds
    b) Set the time with ntpdate -b
    c) start ntpd with "iburst burst minpoll 4 maxpoll 6" for the
    controller blades requiring <100ms offfset and with "iburst burst
    minpoll 4 maxpoll 4" for those blades requiring <10ms among themselves

    So ntpd can start its operation with (almost) no initial offset and a
    drift that is +-2ppm away from the long-term value.
    This gives us a max. offset of <<1 ms right from the start.
    And that's what we were looking for. :-)

    Bye
    Juergen


  9. Re: Stabilizing the drift file?


    >a) Measure the drift with my script for 2 seconds


    >So ntpd can start its operation with (almost) no initial offset and a
    >drift that is +-2ppm away from the long-term value.


    Are you sure that is going to work correctly?

    If one of those readings is off by 5 microseconds, that will turn
    into an error of 2.5 ppm.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  10. Re: Stabilizing the drift file?

    Juergen,

    Assuming your system specification allows for up to 10 ms measurement
    error over two seconds, your script can result in a maximum frequency
    error of 5000 PPM. Golly.

    Dave

    Juergen.Salm@siemens.com wrote:
    > Hi Dave.
    >
    >
    >>This could be avoided by forcefully setting the clock at initial
    >>startup

    >
    >
    > That's exactly what we do.
    >
    > You have to know that Robert an I are working on the same project.
    > Robert is a systems engineer of the platform we use to build our
    > device.
    >
    > The requirements of max. 100ms external offset, max. 10ms internal
    > offset an 5 minutes until service availability are coming from our
    > requirement specification. ;-)
    > And we are always talking about a reboot scenario. So we don't need to
    > compensate large offsets.
    >
    > What we do now during reboot is
    > a) Measure the drift with my script for 2 seconds
    > b) Set the time with ntpdate -b
    > c) start ntpd with "iburst burst minpoll 4 maxpoll 6" for the
    > controller blades requiring <100ms offfset and with "iburst burst
    > minpoll 4 maxpoll 4" for those blades requiring <10ms among themselves
    >
    > So ntpd can start its operation with (almost) no initial offset and a
    > drift that is +-2ppm away from the long-term value.
    > This gives us a max. offset of <<1 ms right from the start.
    > And that's what we were looking for. :-)
    >
    > Bye
    > Juergen
    >


  11. Re: Stabilizing the drift file?

    Hi Hal.

    > If one of those readings is off by 5 microseconds, that will turn
    > into an error of 2.5 ppm.


    As I wrote, +-2ppm is fine. Even +-5ppm would be sufficient not to
    exceed 10ms offset in the transient phase after ntpd is started up.

    Bye
    Juergen


  12. Re: Stabilizing the drift file?

    Hi Dave.

    > Assuming your system specification allows for up to 10 ms measurement
    > error over two seconds, your script can result in a maximum frequency
    > error of 5000 PPM. Golly.


    With 10ms measurement error, we would never be able to fulfil the
    requirement of less than 10ms offset between the blades. ;-(

    However, the blades are communicating with each other via a gigabit
    ethernet backplane.
    The poll delay is usually less than 150us. And to cope with single
    outliers, I use '-p 8' in the script. In addition, the script uses the
    server timestamp information to calculate the duration of the
    measurement period to be independent of the potentionally hight error
    of the local clock. And I anyway have to trust the server.

    Bye
    Juergen


  13. Re: Stabilizing the drift file?

    Robert Wachinger writes:

    > Hi,
    >
    > did anybody else have the problem, to have to stabilize the frequency discipline
    > faster than the normal 15 minutes to hours? Does any solution exist?


    "Hack the daemon" is the most likely solution (despite of "iburst" and "burst").

    >
    > We have here the requirement to have a replaced board (a fresh one from the factory,
    > where a correct content of the drift file is unknown) up after 5 minutes in a cluster,
    > which also means, that its time does not stray more than 10ms (within the cluster).
    >
    > Any tips?
    > We tried here to "play" with minpoll, burst, initial drift files (value 0).


    What about not running the new board in the cluster first?

    Ulrich

  14. Re: Stabilizing the drift file?

    Ulrich Windl wrote:
    > Robert Wachinger writes:
    >
    >
    >>Hi,
    >>
    >>did anybody else have the problem, to have to stabilize the frequency discipline
    >>faster than the normal 15 minutes to hours? Does any solution exist?

    >
    >
    > "Hack the daemon" is the most likely solution (despite of "iburst" and "burst").
    >
    >
    >>We have here the requirement to have a replaced board (a fresh one from the factory,
    >>where a correct content of the drift file is unknown) up after 5 minutes in a cluster,
    >>which also means, that its time does not stray more than 10ms (within the cluster).
    >>
    >>Any tips?
    >>We tried here to "play" with minpoll, burst, initial drift files (value 0).

    >
    >
    > What about not running the new board in the cluster first?
    >
    > Ulrich

    Does it have to play "nice" or work as a "reliable server" instantly?

    in case of nice ( for "single action replacement" requirements) :
    write some shellscript that evaluates the driftfile ( on a regular basis per cron).

    Start with and keep the machine mum as ntp server.

    Change ntp configuration ( per script ) when your quality requirements are met.

    Switch back ( and mail for help ) when the box misbehaves.

    uwe



  15. Re: Stabilizing the drift file?

    Juergen,

    You are badly misguided. While the resolution of your Linux (and many
    other systems) system clock might be better than a microsecond, the
    precision of reading it can be much worse, Moreover, you haven't
    calibrated for the maximum intrinsic error in reading the system clock
    upon reboot, which can be in the many milliseconds, much more if the TOY
    clock chip cannot be read to that precision. Suggesting that you can
    with confidence estimate the intrinsic clock frequency within a PPM
    after two seconds of observation is statistical irresponsibility. I said
    what I said; now we should get on to other business.

    Dave

    Juergen.Salm@siemens.com wrote:

    > mills@udel.edu wrote :
    >
    >
    >>When first starting ntpd without the drift file, by default the state
    >>machine takes fifteen minutes to directly compute the initial frequency
    >>estimate within about 1 PPM, then enables the native clock discipline
    >>algorithm.

    >
    >
    > Hi Dave.
    >
    > You statement is correct for the complete variety of platforms ntp
    > supports.
    > However, on a Linux system (with at least 1us time resolution) you can
    > get reasonable estimates for the drift much faster.
    > Have a look at my script in
    > https://ntp.isc.org/bugs/show_bug.cgi?id=742
    > Changing the stepout as you proposed should give the same results (on
    > Linux).
    > Unfortunately, I didn't understand the meaning of 'stepout' from the
    > documentation. ;-(
    >
    > Bye
    > Juergen
    >


+ Reply to Thread