ntpdate.c unsafe buffer write - NTP

This is a discussion on ntpdate.c unsafe buffer write - NTP ; Serge, I didn't believe what you said until I checked the code and it does increase the correction by 50%, but limits the overshoot to 50 ms. Why in the would it overshoot at all? Dave Serge Bets wrote: > ...

+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 41 to 60 of 84

Thread: ntpdate.c unsafe buffer write

  1. Re: ntpdate.c unsafe buffer write

    Serge,

    I didn't believe what you said until I checked the code and it does
    increase the correction by 50%, but limits the overshoot to 50 ms. Why
    in the would it overshoot at all?

    Dave

    Serge Bets wrote:

    > Hello David,
    >
    > On Monday, February 11, 2008 at 19:03:36 +0000, David L. Mills wrote:
    >
    >
    >>Both ntpdate and ntpd -q set the offset with adjtime() and then exit.
    >>After that, stock Unix adjtime() slews the clock at rate 500 PPM,
    >>which indeed could take 256 s for an initial offset of 128 ms.

    >
    >
    > And on some systems, adjtime() calls adjtimex(ADJ_OFFSET_SINGLESHOT) to
    > do the job.
    >
    > Note that ntpdate does not stop slewing when it reaches the zero offset,
    > but voluntarily overshoots by 50%. That's why ntpdate -b (forced step)
    > or ntpd -q (exact slew until zero) are so much better.
    >
    >
    >
    >>A prudent response would be to measure the initial offset and compute
    >>the time to wait.

    >
    >
    > Thanks! That's exactly what does the slew_sleeping script:
    >
    > ------------------------------------------------------------------------
    > #!/bin/sh
    >
    > function slew_sleeping() {
    > awk '
    > {print}
    > /^ntpd: time slew .*s$/ {
    > sleep = $4 * 2000
    > if (sleep < 0)
    > sleep = -sleep
    > sleep = int(sleep + 0.999999) # rounded by excess
    > success = 1
    > }
    > /^ntpd: time set .*s$/ {
    > success = 1
    > }
    > END{
    > if (sleep) {
    > printf "wait for the end of time slew, sleeping %d seconds\n", sleep
    > system("sleep " sleep)
    > }
    > exit success
    > }
    > '
    > }
    >
    > # echo "ntpd: time slew -0.003000s" | slew_sleeping; exit
    >
    > while ntpd -gq | slew_sleeping; do :; done; ntpd
    > ------------------------------------------------------------------------
    >
    >
    > Serge.


  2. Re: ntpdate.c unsafe buffer write

    harlan,

    Once entering state 4, the only way to leave it is after two steps,
    after which the discipline is switched to measure frequency directly, as
    with no frequency file. This is an emergency recovery measure when for
    some reason the frequency file contains a value more than 128 PPM from
    the real frequency, which would ordinarily indicate a hardware fault.

    Dave

    Harlan Stenn wrote:

    > Serge,
    >
    > Interesting script - thanks. Would you like me to put it in the
    > distribution?
    >
    > This brings up an underlying question. It is possible for events to unfold
    > in a way that while in state 4, events will be such that there will be
    > future wiggles. Some of them may even take us out of state 4.
    >
    > Agreed?
    >
    > If so, what benefit do we get by using the script to delay things while we
    > are waiting for a slew to finish while in state 4?
    >
    > What difference does it make if the system in question is an client as
    > opposed to a server?
    >


  3. Re: ntpdate.c unsafe buffer write

    >>> In article , Unruh writes:

    Harlan> In terms of the behavior model of ntp, "state 4" is as good as it
    Harlan> gets. You are in the right ballpark.

    Unruh> And as has been commented on numerous times, ntp is state 4 is very
    Unruh> slow to converge to the best possible time control. This was a
    Unruh> deliberate design decision, as I understand it, so that in steady
    Unruh> state the time is averaged over a large number of samples ( not
    Unruh> helped by the fact that 85% of samples are thrown away), to reduce
    Unruh> the statistical error in the clock control. Note that at poll 7 the
    Unruh> number of actual samples averaged over in the time scale of the ntp
    Unruh> feedback loop is only about 3, so the statistical averaging even with
    Unruh> such a long time constant, is not very good.

    OK, and please don't take this the wrong way, but So What?

    For the general use case (LAN and/or WAN and/or jerky path) ntpd behaves
    well.

    As Dave recently replied, if you are only interested in LAN performance
    there are tweaks that can be made that will improve the performance.

    The current setup will Just Work regardless of the network environment.

    This, to me, is the sign of a "good piece of software".

    If somebody with extra knowledge can make a local optimization based on
    tighter specs, great.

    I suspect that if Dave can be shown that whatever chrony is doing will
    behave in the wider space that NTP covers, he will be OK making changes to
    use those algorithms.

    There may even be a way to choose different algorithms based on the behavior
    in evidence.

    But you seem to be talking about how improvements can be made and I thought
    this original thread was about how there was a *problem*.

    >> If you want something else, something you consider "better" than state 4,
    >> please make a case for this and lobby for it.


    Unruh> I think many people have lobbied for faster response. In the
    Unruh> discussion of the chrony/ntp comparison, chrony is much faster to
    Unruh> correct errors, and at least on a local network, better at
    Unruh> disciplining the clock as well ( in part I think because on such a
    Unruh> minimal round trip network, the frequency fluctuations dominate over
    Unruh> the offset measurement errors-- Ie, the Allen intercept is much lower
    Unruh> than the assumed 1500 sec. in that kind of situation-- also the drift
    Unruh> model on real systems is not well modeled by 1/f noise.) So, what I
    Unruh> think the point is that using ntpdate, one can rapidly bring the
    Unruh> clock into a few msec of the correct time, rather than waiting for
    Unruh> the feedback loop to finally eliminate that last 128msec of offset.

    OK, and again, I'm seeing you lobby for an enhancement/improvement here (and
    I'm all for that).

    David (I think) was talking about a *problem*.

    I agree with you that we can do better.

    I am trying to see if there is also a problem.

    Harlan> If folks have suggestions for improvements I welcome them.

    Harlan> If folks want something different I invite them to make a case for
    Harlan> it. Please remember the scope and complexity of the problem case.
    Harlan> It's much easier to have a simpler solution if one is prepared to
    Harlan> ignore certain problems. Another case in this point is Maildir.

    Harlan> If somebody is in the situation where they know they have specific
    Harlan> requirements for time, they are in the situation where they have
    Harlan> enough altitude on their requirements to know the costs/benefits of
    Harlan> what is involved in getting there.

    Unruh> Well, I disagree. The sign of a good piece of software is that it
    Unruh> does what it needs to do despite the user having a bad idea of how to
    Unruh> accomplish the task.

    Sounds like NTP. Folks often have pretty bad ideas about what they "need"
    to do or what problems they think they are solving by doing strange things
    and the code works anyway.

    But more to the point, what is the *problem* you are trying to solve? You
    are still communicating to me that we can do *better* and I agree with you.
    You have not yet communicated to me that there is a *problem*.

    Unruh> The use of software should not be an esoteric
    Unruh> exercise.

    While this may be a surprise to some (or painfully obvious to others), I am
    not a chime-head.

    I have had no trouble bringing up ntpd on *lots* of systems in *lots* of
    places using some real simple ntp.conf files for the client boxes and only
    slightly more complicated config files for the internal servers.

    I'm not a fan of esoterica. I like things clean and simple.

    Unruh> Let me again bring up chrony. It manages to get the system
    Unruh> into msec of the right time on a timescale of minutes, not hours. It
    Unruh> had a very different model for the clock control mechanism from
    Unruh> ntp. From what I have seen now, both in a local net system ( with
    Unruh> .2ms roundtrip times) and an adsl connection (20ms round trip times)
    Unruh> chrony also does as good a job or better than ntp at disciplining the
    Unruh> clock. I have just ordered another Garmin 18LVC so I can make
    Unruh> measurments as to how well chrony and ntp actually discipline the
    Unruh> adsl system's time to true time despite all of the noise that adsl
    Unruh> adds to the measurement process. (both ntp and chrony seem to have
    Unruh> about the same standard deviation in the measured offset, so that
    Unruh> gives no information as to how well the clock is actually
    Unruh> disciplined-- one could discipline it to 5usec and the other to
    Unruh> 100usec and you could not tell the difference from the measured times
    Unruh> which have a variance of 500usec due to round trip problems).

    OK, and since you brought it up again I'll respond again: So What?

    Again, are you saying "Hey, I see that chrony seems to do much better than
    ntpd in these areas - can we make ntpd do that well too in those same areas
    without making things worse in areas that chrony does not address?" or are
    you saying "ntpd is broken in the situation of X and here is why"? Or is it
    something else?
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  4. Re: ntpdate.c unsafe buffer write

    >>> In article <47B09E19.3020803@cag.zko.hp.com>, Tom Smith writes:

    Tom> "ntdate -b" steps the clock. That's the function under discussion. The
    Tom> one that's used nearly universally in boot sequences.

    Then change the boot sequence.

    Using "ntpdate -b" to step the clock before starting ntpd is no longer best
    common practice, and it hasn't been for a decent hunk of time.

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  5. Re: ntpdate.c unsafe buffer write

    >>> In article , "David L. Mills" writes:

    Dave,

    David> harlan, Once entering state 4, the only way to leave it is after two
    David> steps, after which the discipline is switched to measure frequency
    David> directly, as with no frequency file. This is an emergency recovery
    David> measure when for some reason the frequency file contains a value more
    David> than 128 PPM from the real frequency, which would ordinarily indicate
    David> a hardware fault.

    Thanks - what about the case where, eg, a system is operating as a local
    master (local refclock or orphan) and gets disconnected from reality for
    "long enough" that a big correction needs to be made?

    The reason I bring this up is that I'm under the impression that while we
    can *expect* that once we are in state 4 we will stay there, I think there
    are cases where we can leave state 4.

    My point here is that I'm not sure we're all on the same page with this
    discussion, and I want to point out that "sometimes things happen".

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  6. Re: ntpdate.c unsafe buffer write

    >>> In article , "David L. Mills" writes:

    David> Serge, I didn't believe what you said until I checked the code and it
    David> does increase the correction by 50%, but limits the overshoot to 50
    David> ms. Why in the would it overshoot at all?

    Dave, this is one of the many problem with ntpdate and why we wanted to
    kill it off since nobody was maintaining it.

    As I recall, somebody said "For folks who want to run ntpdate out of cron,
    we should do a bit of overshoot so we can home in on the right adjustment."

    As I recall, the thought was "If we start off with no overshoot and make our
    adjustment, the next time we run ntpdate we will make the same adjustment
    that we just did. So let's overshoot so next time we will be a bit closer".

    I didn't say the idea makes a lot of sense, but hey.

    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  7. Re: ntpdate.c unsafe buffer write


    >So, no, I am comparing apples to apples ( the offsets as determined from
    >the ntp packet exchange mechanism which both use and both report).


    Another approach is to setup a 3rd machine to watch both.

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


  8. Re: ntpdate.c unsafe buffer write

    Harlan Stenn writes:

    >>>> In article , Unruh writes:


    >Harlan> In terms of the behavior model of ntp, "state 4" is as good as it
    >Harlan> gets. You are in the right ballpark.


    >Unruh> And as has been commented on numerous times, ntp is state 4 is very
    >Unruh> slow to converge to the best possible time control. This was a
    >Unruh> deliberate design decision, as I understand it, so that in steady
    >Unruh> state the time is averaged over a large number of samples ( not
    >Unruh> helped by the fact that 85% of samples are thrown away), to reduce
    >Unruh> the statistical error in the clock control. Note that at poll 7 the
    >Unruh> number of actual samples averaged over in the time scale of the ntp
    >Unruh> feedback loop is only about 3, so the statistical averaging even with
    >Unruh> such a long time constant, is not very good.


    >OK, and please don't take this the wrong way, but So What?


    >For the general use case (LAN and/or WAN and/or jerky path) ntpd behaves
    >well.


    The question is not does it work well, but does it work the best it can.


    >As Dave recently replied, if you are only interested in LAN performance
    >there are tweaks that can be made that will improve the performance.


    No, I am interested in the behaviour in general. That is why I am trying to
    test it on an ADSL link as well.


    >The current setup will Just Work regardless of the network environment.


    >This, to me, is the sign of a "good piece of software".


    >If somebody with extra knowledge can make a local optimization based on
    >tighter specs, great.


    The question is whether or not it can be made better in general.



    >I suspect that if Dave can be shown that whatever chrony is doing will
    >behave in the wider space that NTP covers, he will be OK making changes to
    >use those algorithms.


    >There may even be a way to choose different algorithms based on the behavior
    >in evidence.


    >But you seem to be talking about how improvements can be made and I thought
    >this original thread was about how there was a *problem*.


    This original thread was about how ntpdate had an too small a buffer for a
    given use-- a very easily fixable problem. It then wandered to whether or
    not ntpdate should be axed or not. And then as an aside I mentioned further
    experiments I was doing on the comparison of chrony and ntp-- mentioned
    because one of the reasons ntpdate is used is the slow convergence of ntp
    to the true time. I mentioned that chrony has much faster convergence.
    So as sometimes happens in threads, they wander, and in this case I was at
    least partially responsible for part of the wander.




    >>> If you want something else, something you consider "better" than state 4,
    >>> please make a case for this and lobby for it.


    >Unruh> I think many people have lobbied for faster response. In the
    >Unruh> discussion of the chrony/ntp comparison, chrony is much faster to
    >Unruh> correct errors, and at least on a local network, better at
    >Unruh> disciplining the clock as well ( in part I think because on such a
    >Unruh> minimal round trip network, the frequency fluctuations dominate over
    >Unruh> the offset measurement errors-- Ie, the Allen intercept is much lower
    >Unruh> than the assumed 1500 sec. in that kind of situation-- also the drift
    >Unruh> model on real systems is not well modeled by 1/f noise.) So, what I
    >Unruh> think the point is that using ntpdate, one can rapidly bring the
    >Unruh> clock into a few msec of the correct time, rather than waiting for
    >Unruh> the feedback loop to finally eliminate that last 128msec of offset.


    >OK, and again, I'm seeing you lobby for an enhancement/improvement here (and
    >I'm all for that).


    >David (I think) was talking about a *problem*.


    >I agree with you that we can do better.


    >I am trying to see if there is also a problem.


    Too many potential problems. I am confused about which one.


    >Harlan> If folks have suggestions for improvements I welcome them.


    >Harlan> If folks want something different I invite them to make a case for
    >Harlan> it. Please remember the scope and complexity of the problem case.
    >Harlan> It's much easier to have a simpler solution if one is prepared to
    >Harlan> ignore certain problems. Another case in this point is Maildir.


    >Harlan> If somebody is in the situation where they know they have specific
    >Harlan> requirements for time, they are in the situation where they have
    >Harlan> enough altitude on their requirements to know the costs/benefits of
    >Harlan> what is involved in getting there.


    >Unruh> Well, I disagree. The sign of a good piece of software is that it
    >Unruh> does what it needs to do despite the user having a bad idea of how to
    >Unruh> accomplish the task.


    >Sounds like NTP. Folks often have pretty bad ideas about what they "need"
    >to do or what problems they think they are solving by doing strange things
    >and the code works anyway.


    Mine was a specific response to the comment that Harlan made.


    >But more to the point, what is the *problem* you are trying to solve? You
    >are still communicating to me that we can do *better* and I agree with you.
    >You have not yet communicated to me that there is a *problem*.


    Alright, one problem is the slow response of ntp to change. While I
    certainly understand why it is there, it is still a "problem". The other is
    not clear yet if it is a problem, and that is the accuracy with which ntp
    disciplines the clock to true UTC. Does it do the best it could with the
    data available to it? It is not clear yet that it is a problem-- that is
    what I am trying to measure.



    >Unruh> The use of software should not be an esoteric
    >Unruh> exercise.


    >While this may be a surprise to some (or painfully obvious to others), I am
    >not a chime-head.


    >I have had no trouble bringing up ntpd on *lots* of systems in *lots* of
    >places using some real simple ntp.conf files for the client boxes and only
    >slightly more complicated config files for the internal servers.


    >I'm not a fan of esoterica. I like things clean and simple.


    >Unruh> Let me again bring up chrony. It manages to get the system
    >Unruh> into msec of the right time on a timescale of minutes, not hours. It
    >Unruh> had a very different model for the clock control mechanism from
    >Unruh> ntp. From what I have seen now, both in a local net system ( with
    >Unruh> .2ms roundtrip times) and an adsl connection (20ms round trip times)
    >Unruh> chrony also does as good a job or better than ntp at disciplining the
    >Unruh> clock. I have just ordered another Garmin 18LVC so I can make
    >Unruh> measurments as to how well chrony and ntp actually discipline the
    >Unruh> adsl system's time to true time despite all of the noise that adsl
    >Unruh> adds to the measurement process. (both ntp and chrony seem to have
    >Unruh> about the same standard deviation in the measured offset, so that
    >Unruh> gives no information as to how well the clock is actually
    >Unruh> disciplined-- one could discipline it to 5usec and the other to
    >Unruh> 100usec and you could not tell the difference from the measured times
    >Unruh> which have a variance of 500usec due to round trip problems).


    >OK, and since you brought it up again I'll respond again: So What?


    >Again, are you saying "Hey, I see that chrony seems to do much better than
    >ntpd in these areas - can we make ntpd do that well too in those same areas
    >without making things worse in areas that chrony does not address?" or are
    >you saying "ntpd is broken in the situation of X and here is why"? Or is it
    >something else?


    The former at present.

    >--
    >Harlan Stenn
    >http://ntpforum.isc.org - be a member!


  9. Re: ntpdate.c unsafe buffer write

    Harlan Stenn wrote:
    >
    > For the general use case (LAN and/or WAN and/or jerky path) ntpd behaves
    > well.


    We are talking typical rather than general cases. In the typical case,
    1ms after 1 second is a reasonable expectation on a WAN, especially when
    a site is restarting, e.g. after a power failure, or a home system
    switching on, and, therefore, the network load is low.

  10. Re: ntpdate.c unsafe buffer write

    Dave,

    David L. Mills wrote:
    > Serge,
    >
    > The behavior after a step is deliberate. The iburst volley after a step
    > is delayed a random fraction of the poll interval to avoid implosion
    > at a busy server. An additional delay may be enforced to avoid violating
    > the headway restrictions. This is not to protect your applications; it
    > is to protect the server.


    Is it really necessary to insert a random delay after a step? There has
    already been a random delay immediately after startup, before the client
    has decided that a step was required.

    So even if a bunch of clients started up at the same time and had to step,
    they wouln't step at the same time, and thus wouldn't do the next iburst
    volley at the same time anyway.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  11. Re: ntpdate.c unsafe buffer write

    Dave,

    David L. Mills wrote:
    [...]
    > The ntpd time constant is purposely set somewhat large at 2000 s, which
    > results in a risetime of about 3000 s. This is a compromise for stable
    > acquisition for herky-jerky Internet paths and speed of convergence for
    > LANs. For typical Internet paths the Allan intercept is about 2000 s.
    > For fast LANs with nanosecond clock resolution, the Allan intercept can
    > be as low as 250s, which is what the kernel PPS loop is designed for.


    Wouldn't it make sense to adjust the time constant depending on the time
    after startup, and/or the quality of the responses from the upstream
    servers?

    I.e. the time constant could be smaller after startup to get a fast initial
    correction, and then increase depending on the requirements.

    The packet delay and jitter should also give a good indication whether an
    upstream server is on the local LAN, or on the internet. So the settings
    used to make ntpd work well for the worst cases could be used if those
    cases apply, but the limitations could be reduced in non-worst cases.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  12. Re: ntpdate.c unsafe buffer write

    Hello David,

    On Tuesday, February 12, 2008 at 2:43:06 +0000, David L. Mills wrote:

    > Just for clarity, neither the daemon nor kernel frequency is adjusted
    > in any way with ntpd -q.


    ntpd -q can make use of the driftfile to set the kernel frequency:

    | # ntpd -q -d | grep frequency
    | addto_syslog: frequency initialized -1.752 PPM from /var/lib/ntp/ntp.drift

    Note that this is plain necessary for the correct operations of ntpd -q.
    If the kernel frequency was not initialised, then a slew would not end
    right on the zero offset.


    Serge.
    --
    Serge point Bets arobase laposte point net

  13. Re: ntpdate.c unsafe buffer write

    Hello David,

    On Tuesday, February 12, 2008 at 3:03:37 +0000, David L. Mills wrote:

    > The behavior after a step is deliberate. The iburst volley after a
    > step is delayed a random fraction of the poll interval to avoid
    > implosion at a busy server.


    Ah OK, I understand now! Thank you.

    This makes me wonder: When starting ntpd -gq doing a step and quitting,
    then immediatly starting ntpd daemon, this sequence sends 2 iburst
    volleys, over around 14 seconds, without the said random delay in
    between. Is that not rude to servers? The slew_sleeping script should be
    modified to sleep some time after a step. How much? 16 to 64 s?

    | /^ntpd: time set .*s$/ {
    | sleep = 16 + int(rand() * 49)
    | success = 1
    | }


    Serge.
    --
    Serge point Bets arobase laposte point net

  14. Re: ntpdate.c unsafe buffer write

    Hello Harlan,

    On Tuesday, February 12, 2008 at 3:22:59 +0000, Harlan Stenn wrote:

    > Interesting script - thanks. Would you like me to put it in the
    > distribution?


    Excellent idea! As contrib example, or installed in bindir along with
    ntp-wait?


    > what benefit do we get by using the script to delay things while we
    > are waiting for a slew to finish while in state 4?


    I don't understand the reasoning above your questions, but can reply at
    first degree to this one: If we didn't delay after ntpd -q, then the
    daemon would be started while the slew is still in progress during some
    minutes. This is not a sane situation: The daemon gathers biased data.


    Serge.
    --
    Serge point Bets arobase laposte point net

  15. Re: ntpdate.c unsafe buffer write

    Martin,

    No, there is no random delay at startup. Each association starts one
    second after the previous one. The random backoff occurs only after a
    step. The fact that the initial backoff is small means that the client
    population is crudely synchronized and could well gang up after a step.

    There have been incremental changes over the years to randomize and even
    out the load for busy servers, some of which made folks sad. Originally,
    the code did randomize at startup, but folks hated that since it
    resulted in an initial delay averaging 30 s. Now the backoff occurs only
    when stepped, which is by every measure a rare event. I don't think a
    step has ever happend with our production servers, unless after
    extensive downtime for repair.

    You can easily modify the peer_clear() routine in ntp_proto.c to remove
    the backoff. If so, you will not be able to use any server running the
    reference implementation, as the rate violation will result in a dropped
    packet and, if configured, a KoD.

    Dave

    Martin Burnicki wrote:
    > Dave,
    >
    > David L. Mills wrote:
    >
    >>Serge,
    >>
    >>The behavior after a step is deliberate. The iburst volley after a step
    >> is delayed a random fraction of the poll interval to avoid implosion
    >>at a busy server. An additional delay may be enforced to avoid violating
    >>the headway restrictions. This is not to protect your applications; it
    >>is to protect the server.

    >
    >
    > Is it really necessary to insert a random delay after a step? There has
    > already been a random delay immediately after startup, before the client
    > has decided that a step was required.
    >
    > So even if a bunch of clients started up at the same time and had to step,
    > they wouln't step at the same time, and thus wouldn't do the next iburst
    > volley at the same time anyway.
    >
    > Martin


  16. Re: ntpdate.c unsafe buffer write

    Martin,

    The time constantis automatically adjusted for prevailing network jitter
    and oscillator wander. THe question is what choice in the configuration
    file. In the latest snapshot you can use the discard average command to
    override the minimum poll from 4 (15s) to 3 (8s), which results in a
    risetime of about 250 s. It might not be well known that the clock
    filter uses only the latest sample before the clock is set. You can
    reduce the number of samples required using the tinker maxdist command.
    Effectively, you can disable all ntpd algrotihms and set the clock on
    the first xample.

    Now, having reduced the poll interval to 8 s, you should try using a
    typical pool server, say across the Atlantic. The frequency will usually
    bounce alll over the place. It works just fine on a LAN and the poll
    interval usually ramps up to 10 (1024 s) in an hour.

    Dave

    Martin Burnicki wrote:

    > Dave,
    >
    > David L. Mills wrote:
    > [...]
    >
    >>The ntpd time constant is purposely set somewhat large at 2000 s, which
    >>results in a risetime of about 3000 s. This is a compromise for stable
    >>acquisition for herky-jerky Internet paths and speed of convergence for
    >>LANs. For typical Internet paths the Allan intercept is about 2000 s.
    >>For fast LANs with nanosecond clock resolution, the Allan intercept can
    >>be as low as 250s, which is what the kernel PPS loop is designed for.

    >
    >
    > Wouldn't it make sense to adjust the time constant depending on the time
    > after startup, and/or the quality of the responses from the upstream
    > servers?
    >
    > I.e. the time constant could be smaller after startup to get a fast initial
    > correction, and then increase depending on the requirements.
    >
    > The packet delay and jitter should also give a good indication whether an
    > upstream server is on the local LAN, or on the internet. So the settings
    > used to make ntpd work well for the worst cases could be used if those
    > cases apply, but the limitations could be reduced in non-worst cases.
    >
    > Martin


  17. Re: ntpdate.c unsafe buffer write

    Serge,

    That was removed as a significant security hazard. If you want to
    rxplicitly set the frequency, use ntptime -f. Ths scheme is designed so
    you can run ntpd until the kernel frequency has stabilized, then kill
    ntpd and run SNTP client at regular intervals. I surely wouldn't
    recommend that, but folks have their biases.

    Dave

    Serge Bets wrote:

    > Hello David,
    >
    > On Tuesday, February 12, 2008 at 2:43:06 +0000, David L. Mills wrote:
    >
    >
    >>Just for clarity, neither the daemon nor kernel frequency is adjusted
    >>in any way with ntpd -q.

    >
    >
    > ntpd -q can make use of the driftfile to set the kernel frequency:
    >
    > | # ntpd -q -d | grep frequency
    > | addto_syslog: frequency initialized -1.752 PPM from /var/lib/ntp/ntp.drift
    >
    > Note that this is plain necessary for the correct operations of ntpd -q.
    > If the kernel frequency was not initialised, then a slew would not end
    > right on the zero offset.
    >
    >
    > Serge.


  18. Re: ntpdate.c unsafe buffer write

    Serge,

    No; the server will detect that as a headway violation and drop the
    packets with, if configured, a KoD.

    Come to think of it, randomization is not really required in the latest
    snapshot, since it knows about headway and will throttle accordingly.
    Only in your case where the daemon is stopped and restarted will the
    vioation be detected at the server.

    Dave

    Serge Bets wrote:

    > Hello David,
    >
    > On Tuesday, February 12, 2008 at 3:03:37 +0000, David L. Mills wrote:
    >
    >
    >>The behavior after a step is deliberate. The iburst volley after a
    >>step is delayed a random fraction of the poll interval to avoid
    >>implosion at a busy server.

    >
    >
    > Ah OK, I understand now! Thank you.
    >
    > This makes me wonder: When starting ntpd -gq doing a step and quitting,
    > then immediatly starting ntpd daemon, this sequence sends 2 iburst
    > volleys, over around 14 seconds, without the said random delay in
    > between. Is that not rude to servers? The slew_sleeping script should be
    > modified to sleep some time after a step. How much? 16 to 64 s?
    >
    > | /^ntpd: time set .*s$/ {
    > | sleep = 16 + int(rand() * 49)
    > | success = 1
    > | }
    >
    >
    > Serge.


  19. Re: ntpdate.c unsafe buffer write

    "David L. Mills" wrote in message
    news:fosb7r$i9s$1@scrotar.nss.udel.edu...

    > No, there is no random delay at startup. Each association starts one
    > second after the previous one. The random backoff occurs only after a
    > step.


    Is there also a random backoff after an increase of the polling interval?

    Groetjes,
    Maarten Wiltink



  20. Re: ntpdate.c unsafe buffer write

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


    >>So, no, I am comparing apples to apples ( the offsets as determined from
    >>the ntp packet exchange mechanism which both use and both report).


    >Another approach is to setup a 3rd machine to watch both.


    There is no "both". ntp and chrony are run consecutively on the same
    machine-- otherwise there are real problems with the differing drift rates,
    the differing temperature sensitivities, the different load factors etc.
    And then you also add the noise from the third machine's synchronization,
    the noise in the comparison, etc.
    Anyway, all I was pointing out was that I was measuring exactly the same
    thing both for ntp and chrony.




+ Reply to Thread
Page 3 of 5 FirstFirst 1 2 3 4 5 LastLast