The libntp resumee... - NTP

This is a discussion on The libntp resumee... - NTP ; Hello David, > > When I say "restrict" it is our own system that decides that ">x ms" > > offset is too bad and prevents ntpd from talking to it any further with a > > "restrict" command. If ...

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

Thread: The libntp resumee...

  1. Re: The libntp resumee...

    Hello David,

    > > When I say "restrict" it is our own system that decides that ">x ms"
    > > offset is too bad and prevents ntpd from talking to it any further with a
    > > "restrict" command. If all 2 servers of an "other host" are "restricted",
    > > it will crash the software.

    >
    > You are overriding NTP's selection algorithms. Effectively you are no
    > longer running NTP.


    How would it be difference from using the restrict command manually?

    And why would it not be NTP?

    > > All of that is own our making and control.
    > >
    > > Regarding the poll values. I am not sure why we do it the external NTPs
    > > as well. Could be that the dispersion can be brought down quicker this
    > > way

    >
    > You are misusing "dispersion". Dispersion is an estimate of worst case
    > drift and reading resolution errors.


    Well, dispersion is going down only with more samples to base estimation on,
    isn't it? And we need that quick, if we want the server to influence the
    hosts behind it quickly, say after a "NTP LAN" failure ended (some people
    have dedicated LANs for NTP).

    > > on "entry hosts" and allow the "other hosts" to synchronize faster with
    > > them, or could be that we never considered it worthwhile to optimize it
    > > away. Well yes, but between 2 queries from the same client the ntpd will
    > > have made a certain adjustment. If the client gets to know this value, it
    > > will have to

    >
    > ntpd is making adjustments at least every 4 seconds (old versions) and
    > as often as every clock tick. It does this by adjusting frequency not
    > by directly adjusting time.


    I was not concerned with how the kernel makes the adjustments, but rather that
    the a fixed time change over the period is known. The slew rate is known,
    isn't it?

    Let me use a car analogy, these things work. :-)

    Lets assume a three lane high way with 3 cars that try to drive at the same
    speed. The car to the left is driving at (near) constant speed. The driver in
    the middle accelerates and braces according to his motor behaviour as well as
    the observed difference in speed between him and the other one. Now what
    should the driver to the right do?

    In my view, he could take the acceleration of his neighbour into account when
    making estimates of his own error.

    Best regards,
    Kay Hayen

  2. Re: The libntp resumee...

    kayhayen@gmx.de (Kay Hayen) writes:

    >Hello David,


    >> > When I say "restrict" it is our own system that decides that ">x ms"
    >> > offset is too bad and prevents ntpd from talking to it any further with a
    >> > "restrict" command. If all 2 servers of an "other host" are "restricted",
    >> > it will crash the software.

    >>
    >> You are overriding NTP's selection algorithms. Effectively you are no
    >> longer running NTP.


    >How would it be difference from using the restrict command manually?


    >And why would it not be NTP?


    >> > All of that is own our making and control.
    >> >
    >> > Regarding the poll values. I am not sure why we do it the external NTPs
    >> > as well. Could be that the dispersion can be brought down quicker this
    >> > way

    >>
    >> You are misusing "dispersion". Dispersion is an estimate of worst case
    >> drift and reading resolution errors.


    >Well, dispersion is going down only with more samples to base estimation on,
    >isn't it? And we need that quick, if we want the server to influence the
    >hosts behind it quickly, say after a "NTP LAN" failure ended (some people
    >have dedicated LANs for NTP).


    >> > on "entry hosts" and allow the "other hosts" to synchronize faster with
    >> > them, or could be that we never considered it worthwhile to optimize it
    >> > away. Well yes, but between 2 queries from the same client the ntpd will
    >> > have made a certain adjustment. If the client gets to know this value, it
    >> > will have to

    >>
    >> ntpd is making adjustments at least every 4 seconds (old versions) and
    >> as often as every clock tick. It does this by adjusting frequency not
    >> by directly adjusting time.


    >I was not concerned with how the kernel makes the adjustments, but rather that
    >the a fixed time change over the period is known. The slew rate is known,
    >isn't it?


    >Let me use a car analogy, these things work. :-)


    >Lets assume a three lane high way with 3 cars that try to drive at the same
    >speed. The car to the left is driving at (near) constant speed. The driver in
    >the middle accelerates and braces according to his motor behaviour as well as
    >the observed difference in speed between him and the other one. Now what
    >should the driver to the right do?


    The cars have the road as a reference. However without the road, how does
    car 3 know that car 2 is accelerating and decelerating and that it is not
    hiw own car that is misbehaving? He does not. All he
    can do is collect more cars and use the average behaviour to determine who
    is behaving badly.

    With two other cars only as a reference there is no way of deciding which
    is weird.

    And if he has the road as a reference, then use the road, not either of the
    other cars ( ie buy yourself a GPS receiver with PPS and then you will not
    have to worry about what other cars are doing).


    >In my view, he could take the acceleration of his neighbour into account when
    >making estimates of his own error.


    >Best regards,
    >Kay Hayen


  3. Re: The libntp resumee...

    Kay Hayen wrote:
    > Hello David,
    >
    >>> When I say "restrict" it is our own system that decides that ">x ms"
    >>> offset is too bad and prevents ntpd from talking to it any further with a
    >>> "restrict" command. If all 2 servers of an "other host" are "restricted",
    >>> it will crash the software.

    >> You are overriding NTP's selection algorithms. Effectively you are no
    >> longer running NTP.

    >
    > How would it be difference from using the restrict command manually?
    >
    > And why would it not be NTP?
    >
    >>> All of that is own our making and control.
    >>>
    >>> Regarding the poll values. I am not sure why we do it the external NTPs
    >>> as well. Could be that the dispersion can be brought down quicker this
    >>> way

    >> You are misusing "dispersion". Dispersion is an estimate of worst case
    >> drift and reading resolution errors.

    >
    > Well, dispersion is going down only with more samples to base estimation on,
    > isn't it? And we need that quick, if we want the server to influence the
    > hosts behind it quickly, say after a "NTP LAN" failure ended (some people
    > have dedicated LANs for NTP).
    >
    >>> on "entry hosts" and allow the "other hosts" to synchronize faster with
    >>> them, or could be that we never considered it worthwhile to optimize it
    >>> away. Well yes, but between 2 queries from the same client the ntpd will
    >>> have made a certain adjustment. If the client gets to know this value, it
    >>> will have to

    >> ntpd is making adjustments at least every 4 seconds (old versions) and
    >> as often as every clock tick. It does this by adjusting frequency not
    >> by directly adjusting time.

    >
    > I was not concerned with how the kernel makes the adjustments, but rather that
    > the a fixed time change over the period is known. The slew rate is known,
    > isn't it?
    >
    > Let me use a car analogy, these things work. :-)
    >
    > Lets assume a three lane high way with 3 cars that try to drive at the same
    > speed. The car to the left is driving at (near) constant speed. The driver in
    > the middle accelerates and braces according to his motor behaviour as well as
    > the observed difference in speed between him and the other one. Now what
    > should the driver to the right do?
    >
    > In my view, he could take the acceleration of his neighbour into account when
    > making estimates of his own error.


    Why should the driver in the right lane not ignore the driver in the
    middle and try to match his speed to the leftmost driver? It seems to
    me that this is analogous to preferring the stratum one server to the
    stratum two server!

  4. Re: The libntp resumee...

    Unruh wrote:
    > kayhayen@gmx.de (Kay Hayen) writes:
    >
    >> Hello David,

    >
    >>>> When I say "restrict" it is our own system that decides that ">x ms"
    >>>> offset is too bad and prevents ntpd from talking to it any further with a
    >>>> "restrict" command. If all 2 servers of an "other host" are "restricted",
    >>>> it will crash the software.
    >>> You are overriding NTP's selection algorithms. Effectively you are no
    >>> longer running NTP.

    >
    >> How would it be difference from using the restrict command manually?

    >
    >> And why would it not be NTP?

    >
    >>>> All of that is own our making and control.
    >>>>
    >>>> Regarding the poll values. I am not sure why we do it the external NTPs
    >>>> as well. Could be that the dispersion can be brought down quicker this
    >>>> way
    >>> You are misusing "dispersion". Dispersion is an estimate of worst case
    >>> drift and reading resolution errors.

    >
    >> Well, dispersion is going down only with more samples to base estimation on,
    >> isn't it? And we need that quick, if we want the server to influence the
    >> hosts behind it quickly, say after a "NTP LAN" failure ended (some people
    >> have dedicated LANs for NTP).

    >
    >>>> on "entry hosts" and allow the "other hosts" to synchronize faster with
    >>>> them, or could be that we never considered it worthwhile to optimize it
    >>>> away. Well yes, but between 2 queries from the same client the ntpd will
    >>>> have made a certain adjustment. If the client gets to know this value, it
    >>>> will have to
    >>> ntpd is making adjustments at least every 4 seconds (old versions) and
    >>> as often as every clock tick. It does this by adjusting frequency not
    >>> by directly adjusting time.

    >
    >> I was not concerned with how the kernel makes the adjustments, but rather that
    >> the a fixed time change over the period is known. The slew rate is known,
    >> isn't it?

    >
    >> Let me use a car analogy, these things work. :-)

    >
    >> Lets assume a three lane high way with 3 cars that try to drive at the same
    >> speed. The car to the left is driving at (near) constant speed. The driver in
    >> the middle accelerates and braces according to his motor behaviour as well as
    >> the observed difference in speed between him and the other one. Now what
    >> should the driver to the right do?

    >
    > The cars have the road as a reference. However without the road, how does
    > car 3 know that car 2 is accelerating and decelerating and that it is not
    > hiw own car that is misbehaving? He does not. All he
    > can do is collect more cars and use the average behaviour to determine who
    > is behaving badly.


    Car 3 has a speedometer!

    >
    > With two other cars only as a reference there is no way of deciding which
    > is weird.
    >
    > And if he has the road as a reference, then use the road, not either of the
    > other cars ( ie buy yourself a GPS receiver with PPS and then you will not
    > have to worry about what other cars are doing).
    >
    >
    >> In my view, he could take the acceleration of his neighbour into account when
    >> making estimates of his own error.

    >
    >> Best regards,
    >> Kay Hayen


  5. Re: The libntp resumee...

    On 2008-09-08, Martin Burnicki wrote:

    > If I understand Kay correctly then the problem is that he responded
    > via the questions@ list and the moderation bit was set there, which
    > prevented some of his articles from being gatewayed to the usenet.


    When messages are held for moderation they are not sent to the
    mailing-list. _None_ of the list subscribers (which includes the
    gateway) see those messages until they are released.

    > In Kay's original thread Steve Kostecke mentioned he had removed the
    > moderation bit for Kay, but obviously that did not fully help.


    I stated that I released Kay's messages but that I left the moderation
    bit alone and deferred to the list-master.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  6. Re: The libntp resumee...

    Kay Hayen wrote:
    >
    >
    > How would it be difference from using the restrict command manually?


    Because manual use would normally be based on significant thought and
    measurements over an extended period.
    >
    > And why would it not be NTP?


    Because a key part of NTP is the algorithm used to identify and reject
    unreliable sources of time. These actually work better if you have many
    sources.

    > >

    > Well, dispersion is going down only with more samples to base estimation on,


    The calculation initially assumes that the source jitter might be very
    large until it has evidence to the contrary.

    > isn't it? And we need that quick, if we want the server to influence the
    > hosts behind it quickly, say after a "NTP LAN" failure ended (some people
    > have dedicated LANs for NTP).


    iburst covers that.

    >
    > I was not concerned with how the kernel makes the adjustments, but rather that
    > the a fixed time change over the period is known. The slew rate is known,
    > isn't it?


    The actual change in time in any period should be zero, within
    statistical error. The real excess slew rate should also be zero within
    statistical error. The assumed length of a tick, which is probably the
    reciprocal of what you mean by the slew rate, is continuously varying.
    You would need to integrate this to get the excess number of ticks over
    a period, which is, I think your concept of error.

    (The big argument between chrony and ntpd is about whether ntpd really
    gives the best estimate of true time for real inputs.)

    >
    > Let me use a car analogy, these things work. :-)
    >
    > Lets assume a three lane high way with 3 cars that try to drive at the same
    > speed. The car to the left is driving at (near) constant speed. The driver in
    > the middle accelerates and braces according to his motor behaviour as well as
    > the observed difference in speed between him and the other one. Now what
    > should the driver to the right do?
    >
    > In my view, he could take the acceleration of his neighbour into account when
    > making estimates of his own error.


    Analogies are always unsafe in fora, but the second car doesn't actually
    know its acceleration (remember, if they could actually see the road,
    they would use that as reference). All it knows is how hard its driver
    is pushing on the accelerator.

    Moreover, the drivers are looking at each other through mirrors that are
    vibrating violently and unpredictably, such that the apparent position
    of the neighbours is varying much more than their true relevant
    position. To a significant extent the mirrors are moving independently
    of each other (this probably requires that the third driver actually be
    the middle one, to make the physical model sensible).

  7. Re: The libntp resumee...

    "Richard B. Gilbert" writes:

    >Unruh wrote:
    >> kayhayen@gmx.de (Kay Hayen) writes:
    >>
    >>> Hello David,

    >>
    >>>>> When I say "restrict" it is our own system that decides that ">x ms"
    >>>>> offset is too bad and prevents ntpd from talking to it any further with a
    >>>>> "restrict" command. If all 2 servers of an "other host" are "restricted",
    >>>>> it will crash the software.
    >>>> You are overriding NTP's selection algorithms. Effectively you are no
    >>>> longer running NTP.

    >>
    >>> How would it be difference from using the restrict command manually?

    >>
    >>> And why would it not be NTP?

    >>
    >>>>> All of that is own our making and control.
    >>>>>
    >>>>> Regarding the poll values. I am not sure why we do it the external NTPs
    >>>>> as well. Could be that the dispersion can be brought down quicker this
    >>>>> way
    >>>> You are misusing "dispersion". Dispersion is an estimate of worst case
    >>>> drift and reading resolution errors.

    >>
    >>> Well, dispersion is going down only with more samples to base estimation on,
    >>> isn't it? And we need that quick, if we want the server to influence the
    >>> hosts behind it quickly, say after a "NTP LAN" failure ended (some people
    >>> have dedicated LANs for NTP).

    >>
    >>>>> on "entry hosts" and allow the "other hosts" to synchronize faster with
    >>>>> them, or could be that we never considered it worthwhile to optimize it
    >>>>> away. Well yes, but between 2 queries from the same client the ntpd will
    >>>>> have made a certain adjustment. If the client gets to know this value, it
    >>>>> will have to
    >>>> ntpd is making adjustments at least every 4 seconds (old versions) and
    >>>> as often as every clock tick. It does this by adjusting frequency not
    >>>> by directly adjusting time.

    >>
    >>> I was not concerned with how the kernel makes the adjustments, but rather that
    >>> the a fixed time change over the period is known. The slew rate is known,
    >>> isn't it?

    >>
    >>> Let me use a car analogy, these things work. :-)

    >>
    >>> Lets assume a three lane high way with 3 cars that try to drive at the same
    >>> speed. The car to the left is driving at (near) constant speed. The driver in
    >>> the middle accelerates and braces according to his motor behaviour as well as
    >>> the observed difference in speed between him and the other one. Now what
    >>> should the driver to the right do?

    >>
    >> The cars have the road as a reference. However without the road, how does
    >> car 3 know that car 2 is accelerating and decelerating and that it is not
    >> hiw own car that is misbehaving? He does not. All he
    >> can do is collect more cars and use the average behaviour to determine who
    >> is behaving badly.


    >Car 3 has a speedometer!


    Yes, that is with reference to the road. Car three should thus completely
    ignore the other two cars and use his speedometer.

    Ie, put up a GPS receiver with a PPS and use that as your time source, and
    ignore all the other ntp time sources, except perhaps as sanity checks (eg
    if you r speedometer breaks you should get to know about it by occasionally
    looking at the other cars)



    >>
    >> With two other cars only as a reference there is no way of deciding which
    >> is weird.
    >>
    >> And if he has the road as a reference, then use the road, not either of the
    >> other cars ( ie buy yourself a GPS receiver with PPS and then you will not
    >> have to worry about what other cars are doing).
    >>
    >>
    >>> In my view, he could take the acceleration of his neighbour into account when
    >>> making estimates of his own error.

    >>
    >>> Best regards,
    >>> Kay Hayen


  8. Re: The libntp resumee...

    Steve,

    Steve Kostecke wrote:
    > On 2008-09-08, Martin Burnicki wrote:
    >> In Kay's original thread Steve Kostecke mentioned he had removed the
    >> moderation bit for Kay, but obviously that did not fully help.

    >
    > I stated that I released Kay's messages but that I left the moderation
    > bit alone and deferred to the list-master.


    Sorry, I mis-remembered this.

    Has the moderation bit for Kay been set because he posted to the questions@
    list without having subscribed to the list?

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  9. Re: The libntp resumee...


    >The "rules" about how often to query a daemon are not all that
    >complicated. The fact that there ARE rules is due to some history;
    >google for "Netgear Wisconsin" for the sordid details. For a "second
    >opinion" google for "DLink PHK".


    There is a good summary at:

    NTP server misuse and abuse
    http://en.wikipedia.org/wiki/NTP_ser...suse_and_abuse

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


  10. Re: The libntp resumee...

    Unruh wrote:
    >
    > Yes, that is with reference to the road. Car three should thus completely
    > ignore the other two cars and use his speedometer.
    >
    > Ie, put up a GPS receiver with a PPS and use that as your time source, and
    > ignore all the other ntp time sources, except perhaps as sanity checks (eg
    > if you r speedometer breaks you should get to know about it by occasionally
    > looking at the other cars)


    A)One GPS to each box or
    B) a single GPS with PPS line to all boxes?

    A:
    Doesn't that impact reliability?

    You add the failure probability of a GPS-unit to each Box
    where one failure will make the whole system fail.

    What about doing startup of all involved boxes from the (outside)
    upstream timeserver?

    a question in this context:

    could I use something like this for a group of boxes to sync:

    server $external_upstream_host

    foreach box $neighbours
    peer $box

    ########################

    uwe



  11. Re: The libntp resumee...

    On 2008-09-09, Martin Burnicki wrote:

    > Has the moderation bit for Kay been set because he posted to the questions@
    > list without having subscribed to the list?


    Kay did the right thing and subscribed to the list before posting to it.

    Posts from all new subscribers are held for moderation (i.e. "their
    moderation bit is set") until they have demostrated that they are not
    attempting to use the list in an abusive manner. This policy keeps out
    the "drive-by" spammers.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  12. Re: The libntp resumee...

    Uwe Klein writes:

    >Unruh wrote:
    >>
    >> Yes, that is with reference to the road. Car three should thus completely
    >> ignore the other two cars and use his speedometer.
    >>
    >> Ie, put up a GPS receiver with a PPS and use that as your time source, and
    >> ignore all the other ntp time sources, except perhaps as sanity checks (eg
    >> if you r speedometer breaks you should get to know about it by occasionally
    >> looking at the other cars)


    >A)One GPS to each box or
    >B) a single GPS with PPS line to all boxes?


    Whichever you want. Up to you.

    >A:
    >Doesn't that impact reliability?


    >You add the failure probability of a GPS-unit to each Box
    >where one failure will make the whole system fail.


    So, that is why ntp has backup servers. You have a single failure point
    anyway-- the network. It goes down, and nothing can get the time.



    >What about doing startup of all involved boxes from the (outside)
    >upstream timeserver?


    ???


    >a question in this context:


    >could I use something like this for a group of boxes to sync:


    >server $external_upstream_host


    >foreach box $neighbours
    > peer $box


    >########################


    >uwe




  13. Re: The libntp resumee...

    Unruh wrote:
    > Uwe Klein writes:
    >
    >
    >>Unruh wrote:
    >>
    >>>Yes, that is with reference to the road. Car three should thus completely
    >>>ignore the other two cars and use his speedometer.
    >>>
    >>>Ie, put up a GPS receiver with a PPS and use that as your time source, and
    >>>ignore all the other ntp time sources, except perhaps as sanity checks (eg
    >>>if you r speedometer breaks you should get to know about it by occasionally
    >>>looking at the other cars)

    >
    >
    >>A)One GPS to each box or
    >>B) a single GPS with PPS line to all boxes?

    >
    >
    > Whichever you want. Up to you.
    >
    >
    >>A:
    >>Doesn't that impact reliability?

    >
    >
    >>You add the failure probability of a GPS-unit to each Box
    >>where one failure will make the whole system fail.

    >
    >
    > So, that is why ntp has backup servers. You have a single failure point
    > anyway-- the network. It goes down, and nothing can get the time.



    That actually is _three_ different scenarios.

    time over the network:

    network fails
    1: time
    2: the system as a whole

    failure of network infrastructure
    thus does not add to the probability of the complete system failing.

    time over PPS/GPS 1 unit with signaling to each box:

    network fails
    2: the system as a whole

    GPS fails
    1: time
    -> the system as a whole

    This adds up to a higher failure rate/probability.

    time over PPS/GPS unit per box:

    network fails
    2: the system as a whole

    GPS fails
    1: time
    -> the system as a whole

    This adds up to a higher failure rate/probability.

    With the added disadvantage that GPS failure overall
    is single failure times number of boxes.


    uwe

  14. Re: The libntp resumee...

    Unruh wrote:
    > Uwe Klein writes:
    >
    >> Unruh wrote:
    >>> Yes, that is with reference to the road. Car three should thus completely
    >>> ignore the other two cars and use his speedometer.
    >>>
    >>> Ie, put up a GPS receiver with a PPS and use that as your time source, and
    >>> ignore all the other ntp time sources, except perhaps as sanity checks (eg
    >>> if you r speedometer breaks you should get to know about it by occasionally
    >>> looking at the other cars)

    >
    >> A)One GPS to each box or
    >> B) a single GPS with PPS line to all boxes?

    >
    > Whichever you want. Up to you.
    >
    >> A:
    >> Doesn't that impact reliability?

    >
    >> You add the failure probability of a GPS-unit to each Box
    >> where one failure will make the whole system fail.

    >
    > So, that is why ntp has backup servers. You have a single failure point
    > anyway-- the network. It goes down, and nothing can get the time.
    >



    If the possibility of failure of your network or your internet
    connection worries you, you can use a modem and a telephone line as a
    backup! Or you can get a GPS receiver, WWV/WWVH/WWVB receiver or an
    atomic clock of your very own. Most sites don't bother because their
    requirements are not that tight. FWIW, a system that has been
    synchronized by NTP will tend to stay close to the correct time for a
    reasonable period of time as long as the environment does not change
    significantly. If the network fails AND the air conditioning fails you
    are in trouble!


  15. Re: The libntp resumee...

    Uwe Klein writes:

    >Unruh wrote:
    >> Uwe Klein writes:
    >>
    >>
    >>>Unruh wrote:
    >>>
    >>>>Yes, that is with reference to the road. Car three should thus completely
    >>>>ignore the other two cars and use his speedometer.
    >>>>
    >>>>Ie, put up a GPS receiver with a PPS and use that as your time source, and
    >>>>ignore all the other ntp time sources, except perhaps as sanity checks (eg
    >>>>if you r speedometer breaks you should get to know about it by occasionally
    >>>>looking at the other cars)

    >>
    >>
    >>>A)One GPS to each box or
    >>>B) a single GPS with PPS line to all boxes?

    >>
    >>
    >> Whichever you want. Up to you.
    >>
    >>
    >>>A:
    >>>Doesn't that impact reliability?

    >>
    >>
    >>>You add the failure probability of a GPS-unit to each Box
    >>>where one failure will make the whole system fail.

    >>
    >>
    >> So, that is why ntp has backup servers. You have a single failure point
    >> anyway-- the network. It goes down, and nothing can get the time.



    >That actually is _three_ different scenarios.


    >time over the network:


    >network fails
    > 1: time
    > 2: the system as a whole


    > failure of network infrastructure
    > thus does not add to the probability of the complete system failing.


    >time over PPS/GPS 1 unit with signaling to each box:


    >network fails
    > 2: the system as a whole


    >GPS fails
    > 1: time
    > -> the system as a whole


    > This adds up to a higher failure rate/probability.


    >time over PPS/GPS unit per box:


    >network fails
    > 2: the system as a whole


    >GPS fails
    > 1: time
    > -> the system as a whole


    > This adds up to a higher failure rate/probability.


    > With the added disadvantage that GPS failure overall
    > is single failure times number of boxes.



    So, put a GPS connected to each box. That will be a stratum 0 source and
    will be selected by ntp. If that fails, have each of the other machines as
    a backup. They will be stratum 1 source. Then have the system go out onto
    the world wide net to pool.ntp. Those will be stratum 2 or lower. Each
    backs up the otehr. Thus each machine will gets its time from GPS (usec
    precision) It that fails, they get it from the local machines ( 10s of usec
    precision) If that all fails they get it from the net ( ms precision) It
    that all fails, you are SOOL. You probably have other worries anyway.

    How many belts and braces you want is entirely up to you.

    I would have one GPS on one machine. Everything gets their time from that,
    unless it fails in which case pool.ntp would act as a backup. But it is
    entirely up to you.

    >uwe


  16. Re: The libntp resumee...

    Kay Hayen wrote:
    > What worried me more was how often we can query the local ntpd before it will
    > have an adverse effect. Meantime I somehow I sought to convince me I should
    > be able to convince myself that ntpq requests are served at a different
    > priority (other socket) than ntpd requests are. I didn't find 2 sockets
    > though.
    >


    They aren't. It's the same socket and each packet is responded to in
    turn irrespective of the content. It's also not possible to create a
    separate socket unless we have a separate command channel and that does
    not currently exist and is nowhere defined in the protocol.

    >> Briefly, you use the defaults for MINPOLL and MAXPOLL. You may use the
    >> "iburst" keyword in a server statement for fast startup. You may use
    >> the "burst" keyword ONLY with the permission of the the server's owner.
    >> 99.99% of NTP installations will work very well using these rules". If
    >> yours does not, ask here for help!

    >
    > Now speaking about our system, not the middleware, with connections as
    > follows:
    >
    > External NTPs <-> 2 entry hosts <-> 8 other hosts.
    >
    > And iburst and minpoll=maxpoll=5 to improve the results.


    This indicates that you don't understand NTP. You should never ever
    change the minpoll and maxpoll values unless you understand the NTP
    algorithms in detail and understand the consequences of changing them.
    The default values were very carefully chosen to provide a balance
    between various conflicting requirements to provide the most stable
    clock discipline over a wide range of environments. You are
    undersampling at the start of NTP and then oversampling as it starts to
    stabilize the discipline loop.

    >
    > Currently we observe that both entry hosts can both become restricted due to
    > large offsets on other hosts, so they become restricted and that will make
    > the software refuse to go on. Ideally that would not happen.
    >


    If the servers that it uses become divergent it will be unable to pick
    the "best" one and it will become unsynchronized.

    > I will try to formulate questions:
    >
    > When the other hosts synchronize to the entry hosts of our system, don't the
    > other hosts ntpd know when and how much these entry hosts changed their time
    > due to input?
    >
    > Would NTP would be more robust if we would configure routing on the entry
    > hosts, so that they can all speak directly with the external NTPs on their
    > own?
    >


    Yes since the stratum will be lower so that the error budget will also
    be lower.

    > Is the use of ntpdate before starting ntpd recommended and/or does the iburst
    > option replace it?
    >


    ntpdate is deprecated and is not normally needed. Make sure you start
    ntpd with the -g option to step the clock initially to close to the
    correct tick.

    Danny
    > Best regards,
    > Kay Hayen


  17. Re: The libntp resumee...

    Danny Mayer wrote:
    > Kay Hayen wrote:


    >> And iburst and minpoll=maxpoll=5 to improve the results.

    >
    > This indicates that you don't understand NTP. You should never ever
    > change the minpoll and maxpoll values unless you understand the NTP
    > algorithms in detail and understand the consequences of changing them.
    > The default values were very carefully chosen to provide a balance
    > between various conflicting requirements to provide the most stable


    Those conflicting requirements make assumptions about the environment in
    which NTP is operating. Those assumptions probably aren't valid when
    the servers are on the same high speed, low traffic, network. Having
    said that, one shouldn't just set minpoll and maxpoll low, but should
    actually measure the results and find optimum values for the actual
    conditions.

    > clock discipline over a wide range of environments. You are
    > undersampling at the start of NTP and then oversampling as it starts to
    > stabilize the discipline loop.


    ntpd always oversamples. Changing the limits limits the range of filter
    time constants used. Setting it low, improves convergence on startup,
    and re-convergence after a temperature change, which is why there is so
    much use of it - ntpd is failing to meet a market demand, and setting
    both these low has become the urban folklore solution. It also tends to
    minimise the value of "offset" at other times, but that is not
    necessarily good, as offset is not the same thing as error, and,
    ideally, would be uncorrelated with it.

    (ntpd starts to back off the time constant long before the startup
    transient is complete, so keeping it artificially low helps there. For
    temperature changes, it takes time for the time constant to ramp down,
    which is avoided by keeping it low.)

    The reasons for not doing it are that it makes ntpd try to follow short
    term variations in offset, which are likely to be due to network
    conditions, rather than true time errors, and it makes the frequency
    less stable, which means that short durations are measured less
    accurately and time will diverge more quickly if connections to the
    servers is lost. It also imposes an unnecessary load on the servers.

    > ntpdate is deprecated and is not normally needed. Make sure you start
    > ntpd with the -g option to step the clock initially to close to the
    > correct tick.


    -g doesn't step the clock, it simply allows the clock to be stepped by
    more than 1000s, the first time. Clock stepping is still subject to the
    128ms minimum offset. Both numbers are configurable, although changing
    them may disable some functions.


  18. Re: The libntp resumee...

    On Tue, Sep 9, 2008 at 2:52 PM, Richard B. Gilbert
    wrote:
    > FWIW, a system that has been
    > synchronized by NTP will tend to stay close to the correct time for a
    > reasonable period of time as long as the environment does not change
    > significantly. If the network fails AND the air conditioning fails you
    > are in trouble!


    That is, of course, precisely what happens in many long-term power
    outages. Typical UPS battery run times in a datacenter are in minutes,
    not hours. And UPS rarely backup the cooling system. If you don't have
    a working generator on standby with plenty of fuel, you're up the
    proverbial creek.

    Even if you have the generators, you have to be careful. A colocation
    provider recently had an outage that was interesting. A truck ran into
    their (exterior) transformers, cutting utility power. No problem, they
    have generators, right?. Well, their water chillers could not re-start
    fast enough after the generators came on line, so the rapidly
    increasing temperature caused shut down about 1/3 of the servers in
    their datacenter. All told, their SLA credits amounted to millions of
    dollars.

    Focusing on extreme redundancy for one piece of your infrastructure
    (time) is sort of pointless if you don't have full tested redundancy
    in the lower layers of the system (physcial plant, power, cooling,
    network, etc.)
    --
    RPM

  19. Re: The libntp resumee...

    mayer@ntp.isc.org (Danny Mayer) writes:

    ....

    >>> Briefly, you use the defaults for MINPOLL and MAXPOLL. You may use the
    >>> "iburst" keyword in a server statement for fast startup. You may use
    >>> the "burst" keyword ONLY with the permission of the the server's owner.
    >>> 99.99% of NTP installations will work very well using these rules". If
    >>> yours does not, ask here for help!

    >>
    >> Now speaking about our system, not the middleware, with connections as
    >> follows:
    >>
    >> External NTPs <-> 2 entry hosts <-> 8 other hosts.
    >>
    >> And iburst and minpoll=maxpoll=5 to improve the results.


    >This indicates that you don't understand NTP. You should never ever
    >change the minpoll and maxpoll values unless you understand the NTP
    >algorithms in detail and understand the consequences of changing them.
    >The default values were very carefully chosen to provide a balance
    >between various conflicting requirements to provide the most stable
    >clock discipline over a wide range of environments. You are
    >undersampling at the start of NTP and then oversampling as it starts to
    >stabilize the discipline loop.


    The lower value on startup is to try to make ntp responsive at the
    beginning, because it is so slow to correct errors. The longer value on
    running is twofold-- to reduce the network demands on servers ( probably
    the most important) and to increase the baseline for drift determination (
    because of NTPs memoryless design) The former is important if you are using
    public servers. The latter is important if you loose network connectivity
    for days at a time. If you use your own server, and your network is stable,
    a shorter maxpoll is better-- better control and faster response to
    computer clock changes.




    >>
    >> Currently we observe that both entry hosts can both become restricted due to
    >> large offsets on other hosts, so they become restricted and that will make
    >> the software refuse to go on. Ideally that would not happen.
    >>


    >If the servers that it uses become divergent it will be unable to pick
    >the "best" one and it will become unsynchronized.


    >> I will try to formulate questions:
    >>
    >> When the other hosts synchronize to the entry hosts of our system, don't the
    >> other hosts ntpd know when and how much these entry hosts changed their time
    >> due to input?


    No idea what this means. All a client gets is the offset of its clock with
    respect to the server clock, and an estimate of the dispersion of the
    server's clock. I do not know what "how much these entry hosts changed
    their time due to input" means, but my guess is that the answer is "No, the
    clients do not get any information about the internal workings of the
    server"

    >>
    >> Would NTP would be more robust if we would configure routing on the entry
    >> hosts, so that they can all speak directly with the external NTPs on their
    >> own?
    >>


    >Yes since the stratum will be lower so that the error budget will also
    >be lower.


    That depends on your routers. If you have routers with bad
    latency/dispersion, it may be worse due to network delays/variability.


    >> Is the use of ntpdate before starting ntpd recommended and/or does the iburst
    >> option replace it?
    >>


    >ntpdate is deprecated and is not normally needed. Make sure you start
    >ntpd with the -g option to step the clock initially to close to the
    >correct tick.


    >Danny
    >> Best regards,
    >> Kay Hayen


  20. Re: The libntp resumee...

    David,

    The ntpd parameter constellation is indeed tuned for a necessarily wide
    range of scenarios and may not be optimal for any particular case. From
    an engineering point of view the solution for the minpoll/maxpoll issue
    is obvious. Determine the Allan intercept as described in several
    places, my papers and my book. The poll interval is carefully set at
    1/32 the time constant, which should be at the intercept. So set minpoll
    and maxpoll to the log2 of that value. Yes, the loop is purposely
    oversampled with respect to the time constant, but not with respect to
    the Allan intercept.

    The Allan deviation characteristic displayed in the briefings on the NTP
    project page should give a hint how the intercept varies with different
    operating systems and network links. Indeed, if you have a fast LAN,
    PCnet NIC and 3-GHz machine, the optimum poll interval is probably more
    like 4 (16 s), but probably not 3 (8 s), as that invites increased
    vulnerability to frequency surges.

    The poll adjust algorithm does not do what you expect. See line 644 et
    seq in ntp_loopfilter.c and the commentary there. This algorithm is the
    result of literally 25 years of experiment and refinement. It is not
    necessarily designed for rapid initial convergence; it is designed to be
    sensitive to frequency surges once convergence has stabilized. The
    frequency file avoids initial convergence if restarted after that.

    Dave

    David Woolley wrote:
    > Danny Mayer wrote:
    >
    >> Kay Hayen wrote:

    >
    >
    >>> And iburst and minpoll=maxpoll=5 to improve the results.

    >>
    >>
    >> This indicates that you don't understand NTP. You should never ever
    >> change the minpoll and maxpoll values unless you understand the NTP
    >> algorithms in detail and understand the consequences of changing them.
    >> The default values were very carefully chosen to provide a balance
    >> between various conflicting requirements to provide the most stable

    >
    >
    > Those conflicting requirements make assumptions about the environment in
    > which NTP is operating. Those assumptions probably aren't valid when
    > the servers are on the same high speed, low traffic, network. Having
    > said that, one shouldn't just set minpoll and maxpoll low, but should
    > actually measure the results and find optimum values for the actual
    > conditions.
    >
    >> clock discipline over a wide range of environments. You are
    >> undersampling at the start of NTP and then oversampling as it starts to
    >> stabilize the discipline loop.

    >
    >
    > ntpd always oversamples. Changing the limits limits the range of filter
    > time constants used. Setting it low, improves convergence on startup,
    > and re-convergence after a temperature change, which is why there is so
    > much use of it - ntpd is failing to meet a market demand, and setting
    > both these low has become the urban folklore solution. It also tends to
    > minimise the value of "offset" at other times, but that is not
    > necessarily good, as offset is not the same thing as error, and,
    > ideally, would be uncorrelated with it.
    >
    > (ntpd starts to back off the time constant long before the startup
    > transient is complete, so keeping it artificially low helps there. For
    > temperature changes, it takes time for the time constant to ramp down,
    > which is avoided by keeping it low.)
    >
    > The reasons for not doing it are that it makes ntpd try to follow short
    > term variations in offset, which are likely to be due to network
    > conditions, rather than true time errors, and it makes the frequency
    > less stable, which means that short durations are measured less
    > accurately and time will diverge more quickly if connections to the
    > servers is lost. It also imposes an unnecessary load on the servers.
    >
    >> ntpdate is deprecated and is not normally needed. Make sure you start
    >> ntpd with the -g option to step the clock initially to close to the
    >> correct tick.

    >
    >
    > -g doesn't step the clock, it simply allows the clock to be stepped by
    > more than 1000s, the first time. Clock stepping is still subject to the
    > 128ms minimum offset. Both numbers are configurable, although changing
    > them may disable some functions.
    >


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2