chrony and ntp comparison-- ADSL hookup - NTP

This is a discussion on chrony and ntp comparison-- ADSL hookup - NTP ; I have now run some absolute time discipline tests using chrony and ntp The server is a GPS PPM disciplined clock using ntp. The client is a machine on an ADSL line. The round trip between server and client is ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: chrony and ntp comparison-- ADSL hookup

  1. chrony and ntp comparison-- ADSL hookup

    I have now run some absolute time discipline tests using chrony and ntp
    The server is a GPS PPM disciplined clock using ntp. The client is a
    machine on an ADSL line. The round trip between server and client is about
    16ms, which is about 100 times longer than the round trip times used
    earlier in the previous tests I posted.

    In each case I run the GPS PPM to measure the offset of the computer clock
    vs the GPS (It is a parallel port interrupt routine which on each interrupt
    reads the system clock and saves it in a buffer readable from /dev/gpsint.
    Ie, I measure the system time each time it receives a pulse from the GPS
    Garmin 18LVC receiver. Since this has an mean accuracy of about 2usec, its
    noise is negligible.

    The mean in both cases is about -.3ms. Ie the adsl trip is assymetric as to
    outgoing and return but about .6ms.
    In the case of ntp the variance in the readings is about .32ms. For chrony,
    the variance is about .11 msec, 1/3 of the variance of ntp. This is in
    confomity with what I found for the client on the same subnet as the clock.

    Now, chrony is much more aggresive in decreasing the poll interval when the
    statistics gets bad, so the mean poll time for chrony was 36sec while for
    ntp it was 127 sec (in both cases minpoll was 4 and maxpoll was 7).
    Since the noise is dominated by the random transmission times, and not the
    frequency drift of the osillator in the computer, this should not make any
    difference. (the variations in the drift are about 1ppm, and in 128 sec,
    that is only .1ms ) However, I will alter chrony to make it less agressive in
    decreasing the poll interval, and I hope increasing its mean poll time. If that
    does not work I will set minpoll to 6 for chrony.

    However the indications are that chrony is again more accurate than is ntp
    in disciplining the clock.

    Note that seems a reasonably stringent test of the two programs in a situation in
    which the transmission noise dominates the error budget, rather than the
    frequency drift noise as in the test on the same subnet.


  2. Re: chrony and ntp comparison-- ADSL hookup

    Bill Unruh wrote:
    > The round trip between server and client is
    > about 16ms, which is about 100 times longer than the round trip times
    > used
    > earlier in the previous tests I posted.

    []
    > Now, chrony is much more aggresive in decreasing the poll interval
    > when the statistics gets bad, so the mean poll time for chrony was
    > 36sec while for
    > ntp it was 127 sec (in both cases minpoll was 4 and maxpoll was 7).


    I beilieve that this is still unrepresentative:

    - delay values I see are more like 30msec, not 16msec

    - the default for min and max poll are 6 and 10 (IIRC), and not 4 and 7

    David



  3. Re: chrony and ntp comparison-- ADSL hookup

    "David J Taylor" writes:

    >Bill Unruh wrote:
    >> The round trip between server and client is
    >> about 16ms, which is about 100 times longer than the round trip times
    >> used
    >> earlier in the previous tests I posted.

    >[]
    >> Now, chrony is much more aggresive in decreasing the poll interval
    >> when the statistics gets bad, so the mean poll time for chrony was
    >> 36sec while for
    >> ntp it was 127 sec (in both cases minpoll was 4 and maxpoll was 7).


    >I beilieve that this is still unrepresentative:


    Unrepresentitive of what? Of your particular situation? Of course. Run your
    own tests if you really think that your situation is so different that ntp
    would run differently on your system than mine. I am giving you data points
    you may do with them what you want.

    >- delay values I see are more like 30msec, not 16msec


    I just jumped by a factor of 100 in delay and showed it makes no difference
    ( or rather that chrony does even better in a case where delay noise
    dominates the noise sources) and you worry about factors of 2. Next you
    will say that I live in Canada which is not representative. You may
    discount my data all you want, I really do not care.


    >- the default for min and max poll are 6 and 10 (IIRC), and not 4 and 7



    And so? Exactly how is this supposed to make a difference?




  4. Re: chrony and ntp comparison-- ADSL hookup

    Bill Unruh wrote:
    > The round trip between server and client is
    > about 16ms, which is about 100 times longer than the round trip times
    > used
    > earlier in the previous tests I posted.
    >[]
    >> Now, chrony is much more aggresive in decreasing the poll interval
    >> when the statistics gets bad, so the mean poll time for chrony was
    >> 36sec while for
    >> ntp it was 127 sec (in both cases minpoll was 4 and maxpoll was 7).


    >I beilieve that this is still unrepresentative:


    >- delay values I see are more like 30msec, not 16msec


    >- the default for min and max poll are 6 and 10 (IIRC), and not 4 and 7


    >David




  5. Re: chrony and ntp comparison-- ADSL hookup

    Bill Unruh writes:

    >I have now run some absolute time discipline tests using chrony and ntp
    >The server is a GPS PPM disciplined clock using ntp. The client is a
    >machine on an ADSL line. The round trip between server and client is about
    >16ms, which is about 100 times longer than the round trip times used
    >earlier in the previous tests I posted.


    >In each case I run the GPS PPM to measure the offset of the computer clock
    >vs the GPS (It is a parallel port interrupt routine which on each interrupt
    >reads the system clock and saves it in a buffer readable from /dev/gpsint.
    >Ie, I measure the system time each time it receives a pulse from the GPS
    >Garmin 18LVC receiver. Since this has an mean accuracy of about 2usec, its
    >noise is negligible.


    >The mean in both cases is about -.3ms. Ie the adsl trip is assymetric as to
    >outgoing and return but about .6ms.
    >In the case of ntp the variance in the readings is about .32ms. For chrony,
    >the variance is about .11 msec, 1/3 of the variance of ntp. This is in
    >confomity with what I found for the client on the same subnet as the clock.


    >Now, chrony is much more aggresive in decreasing the poll interval when the
    >statistics gets bad, so the mean poll time for chrony was 36sec while for
    >ntp it was 127 sec (in both cases minpoll was 4 and maxpoll was 7).
    >Since the noise is dominated by the random transmission times, and not the
    >frequency drift of the osillator in the computer, this should not make any
    >difference. (the variations in the drift are about 1ppm, and in 128 sec,
    >that is only .1ms ) However, I will alter chrony to make it less agressive in
    >decreasing the poll interval, and I hope increasing its mean poll time. If that
    >does not work I will set minpoll to 6 for chrony.


    >However the indications are that chrony is again more accurate than is ntp
    >in disciplining the clock.


    >Note that seems a reasonably stringent test of the two programs in a situation in
    >which the transmission noise dominates the error budget, rather than the
    >frequency drift noise as in the test on the same subnet.



    One more data point. I altered chrony not to be so ready to decrease the
    poll interval when the jitter grows. In my current run of .6 days, chrony
    has an average poll interval of 80 sec (minpoll 4 maxpoll 7) rather than
    the 36 with the original version. (Note that the time averaged poll
    interval-- ie if you took the poll interval at each second and averaged
    those-- is 108 sec. Ie most of the time is at maxpoll of 128s)
    In this case the variance of the chrony readings decreased slightly to 98usec from
    about 112usec. As I expected increasing the number of readings ( which
    decreases chrony's timebase over which it estimates the offset and slope)
    actually makes things slightly worse, rather than better.

    To summarize, chrony has a factor of slightly less than 4 better variance than ntp
    in the offset of the computer clock as compared with "true time" ( A GPS
    PPS receiver on the client machine). Both ntp and chrony are using as their server a GPS PPS
    controlled system whose "error" is about 3usec, two orders of magnitude
    less than than the variance produced by the ADSL delays.

    Note that the local GPS on teh client is NOT used to discipline the clock
    in any way. It is purely a measurement tool.

    The GPS on the server and client are identical (both Garmin GPS 18LVC
    running into the parallel port and triggering timed interrupts). They are
    separated by 6km. horizontally and about 80 meters vertically.

    It is interesting that both ntp and chrony agree that ADSL introduces about
    a .3ms bias into the time. (Both agree that the computer clock disciplined
    by both ntp and chrony via the adsl connection is about .3ms slow of true
    time.)


  6. Re: chrony and ntp comparison-- ADSL hookup

    Unruh wrote:
    []
    >> - the default for min and max poll are 6 and 10 (IIRC), and not 4
    >> and 7

    >
    >
    > And so? Exactly how is this supposed to make a difference?


    It means that your tests are not carried out on an "out of the box"
    configuration, and therefore perhaps less useful than they might otherwise
    be. It's possible that some servers would see min/maxpoll of 4 and 7 as
    abusive.

    Testing with the ADSL hookup is a useful extra, though.

    Cheers,
    David



  7. Re: chrony and ntp comparison-- ADSL hookup

    "David J Taylor" writes:

    >Unruh wrote:
    >[]
    >>> - the default for min and max poll are 6 and 10 (IIRC), and not 4
    >>> and 7

    >>
    >>
    >> And so? Exactly how is this supposed to make a difference?


    >It means that your tests are not carried out on an "out of the box"
    >configuration, and therefore perhaps less useful than they might otherwise
    >be. It's possible that some servers would see min/maxpoll of 4 and 7 as
    >abusive.


    And no "out of box" test is possible. Neither ntp ( althoug it is much
    closer) or chrony are set up to do so.
    Right now I do not care what servers find abusive. I am using my own
    server, so I decide what is abusive. I am not advocating these parameters,
    I am using them to test ntp and chrony. ALL of the tests indicate that
    chrony disciplines the clock about a factor of 2-3 better than does ntp.
    I have seen no evidence to the contrary, nor any reason to believe that any
    different situation would turn that around. I think, but do not know, that
    the habit of ntp of throwing away 85% of its measurements (clock-filter) is
    behind this. I think that the tradeoff of reducing the effect of delay spikes
    on the timing is more than outweighed by using fewer data points to beat
    down the statistics of the noise. That combined with the long time constant
    of ntp which makes it badly behaved in the case of drift fluctuations is
    what I believe makes ntp worse than chrony.
    Chrony is by no means perfect. It is complicated, at present it works only
    under Linux essentially, it has some design weirnesses as well. But I was
    interested to test the very different design philosophies of chrony against
    ntp. (Recall that chrony was written by one person, and was more or less
    completed about 10 years ago and has not had much if any tuning since. It
    is a pretty impressive piece of work).



    >Testing with the ADSL hookup is a useful extra, though.


    >Cheers,
    >David




  8. Re: chrony and ntp comparison-- ADSL hookup

    Unruh wrote:
    > "David J Taylor" writes:
    >
    >
    >>Unruh wrote:
    >>[]
    >>
    >>>>- the default for min and max poll are 6 and 10 (IIRC), and not 4
    >>>>and 7
    >>>
    >>>
    >>>And so? Exactly how is this supposed to make a difference?

    >>

    >
    >>It means that your tests are not carried out on an "out of the box"
    >>configuration, and therefore perhaps less useful than they might otherwise
    >>be. It's possible that some servers would see min/maxpoll of 4 and 7 as
    >>abusive.

    >
    >
    > And no "out of box" test is possible. Neither ntp ( althoug it is much
    > closer) or chrony are set up to do so.
    > Right now I do not care what servers find abusive. I am using my own
    > server, so I decide what is abusive. I am not advocating these parameters,
    > I am using them to test ntp and chrony. ALL of the tests indicate that
    > chrony disciplines the clock about a factor of 2-3 better than does ntp.


    Testing ntpd and chrony using a local server or servers is not a very
    realistic test of "real world" performance!

    Try configuring both with the same set of four to ten internet servers.
    Set up a stratum 1 server using GPS or a cesium clock as a reference
    to serve as a standard to measure with. Collect statistics for a month
    or so.

    Then tell us what you learned.


  9. Re: chrony and ntp comparison-- ADSL hookup

    Richard B. Gilbert wrote:
    > Set up a stratum 1 server using GPS or a cesium clock as a reference to
    > serve as a standard to measure with. Collect statistics for a month or so.


    As I understand it, his time reference is considerably better than the
    GPS based system that you describe here.

  10. Re: chrony and ntp comparison-- ADSL hookup

    Richard B. Gilbert wrote:

    > Testing ntpd and chrony using a local server or servers is not a very
    > realistic test of "real world" performance!


    16ms is not a local server. It is a reasonable value for a corporate
    internet connection for a medium to large company.

  11. Re: chrony and ntp comparison-- ADSL hookup

    "Richard B. Gilbert" writes:

    >Unruh wrote:
    >> "David J Taylor" writes:
    >>
    >>
    >>>Unruh wrote:
    >>>[]
    >>>
    >>>>>- the default for min and max poll are 6 and 10 (IIRC), and not 4
    >>>>>and 7
    >>>>
    >>>>
    >>>>And so? Exactly how is this supposed to make a difference?
    >>>

    >>
    >>>It means that your tests are not carried out on an "out of the box"
    >>>configuration, and therefore perhaps less useful than they might otherwise
    >>>be. It's possible that some servers would see min/maxpoll of 4 and 7 as
    >>>abusive.

    >>
    >>
    >> And no "out of box" test is possible. Neither ntp ( althoug it is much
    >> closer) or chrony are set up to do so.
    >> Right now I do not care what servers find abusive. I am using my own
    >> server, so I decide what is abusive. I am not advocating these parameters,
    >> I am using them to test ntp and chrony. ALL of the tests indicate that
    >> chrony disciplines the clock about a factor of 2-3 better than does ntp.


    >Testing ntpd and chrony using a local server or servers is not a very
    >realistic test of "real world" performance!


    >Try configuring both with the same set of four to ten internet servers.
    > Set up a stratum 1 server using GPS or a cesium clock as a reference
    >to serve as a standard to measure with. Collect statistics for a month
    >or so.


    >Then tell us what you learned.


    You are starting to sound like the cigarette people when it was pointed out
    that smoking might cause cancer.

    I was trying to test the algorithms NOT the programs as a whole.

    I am not advocating that the world rush out and abandon NTP and alkl run
    chonry. Too many problems. Chrony does not do refclocks. chrony does not
    handle leap seconds. chrony runs only on Linux ( well a bit on a few others
    but not many). However where chrony does run it "beats the pants off" ntp.
    This suggests that the algorithm in chrony is a better clock discipline
    algorithm than ntp's. Has this been tested extensively? No. Is it a
    foolproof conclusion? No. But ALL the evidence at present is that chrony's
    algorithm beats ntp's. If you believe that there are conditions under which
    ntp's would beat chrony's it now becomes your duty to suggest why and
    where. "You have not done enough tests" is the response of someone with a
    completely closed mind.

    I really do not care what you believe about ntp since you have zero data to
    back up your position. I am not claiming that ntp fails. It is a robust,
    well tested algorithm. It works and is certainly "good enough" for almost
    everyone who uses it. I am asking if it is the best we can do. My data
    suggests it is not.

    Note the my latest test was NOT using a local server. It was a remoTE
    stratum 1 server, over an ADSL hookup with a 16ms delay.
    It had 100 times the mean delay and 10 times or more the variance in that
    delay of the "local" test.
    And exactly what would you expect to find if I ran it for a month rather
    than a day? Would you really expect something about the chrony algorithm to
    show up in a month? What? I suspect you have no idea whatsoever as to
    what the chrony algorithm is so you could not if you wanted to.


    And I used a GPS PPS as the reference source on the ADSL client to measure
    the clock offset with.


  12. Re: chrony and ntp comparison-- ADSL hookup

    Bill,

    You hint that it is now the responibility of the NTP crew to rebut your
    claims. Please see the great detail in Chapter 6 of my book, which
    reports on the resulrs of hundreds of experiments with onboard
    oscillators, PPS signals, LANs and various Internet paths all over the
    globe. Included are wedge scattergrams, CDF funtions and time and
    frequency plots, some covering thousands of hours.

    I've said many times that you are not comparing chrony and NTP on a
    level field. If you crank the NTP time constant comparable to yours, I
    strongly expect the two will perform in very similar fashion. In your
    particular LAN the Allan intercept, or when the phase noise about equals
    the flicker noise, could be somewhat lower than assumed as default by
    NTP, but the default depends on a number of considerations other than to
    minimize the risetime.

    The only scientific question of interest here is whether a
    linear-regression loop is better or worse than a phase-lock loop. Let's
    not waste time on issues other than that. You can test that by changing
    probably only a couple lines in your code. Be sure the risetime and
    overshoot characteristics are similar.

    Dave

    Unruh wrote:

    > "Richard B. Gilbert" writes:
    >
    >
    >>Unruh wrote:
    >>
    >>>"David J Taylor" writes:
    >>>
    >>>
    >>>
    >>>>Unruh wrote:
    >>>>[]
    >>>>
    >>>>
    >>>>>>- the default for min and max poll are 6 and 10 (IIRC), and not 4
    >>>>>>and 7
    >>>>>
    >>>>>
    >>>>>And so? Exactly how is this supposed to make a difference?
    >>>>
    >>>>It means that your tests are not carried out on an "out of the box"
    >>>>configuration, and therefore perhaps less useful than they might otherwise
    >>>>be. It's possible that some servers would see min/maxpoll of 4 and 7 as
    >>>>abusive.
    >>>
    >>>
    >>>And no "out of box" test is possible. Neither ntp ( althoug it is much
    >>>closer) or chrony are set up to do so.
    >>>Right now I do not care what servers find abusive. I am using my own
    >>>server, so I decide what is abusive. I am not advocating these parameters,
    >>>I am using them to test ntp and chrony. ALL of the tests indicate that
    >>>chrony disciplines the clock about a factor of 2-3 better than does ntp.

    >
    >
    >>Testing ntpd and chrony using a local server or servers is not a very
    >>realistic test of "real world" performance!

    >
    >
    >>Try configuring both with the same set of four to ten internet servers.
    >> Set up a stratum 1 server using GPS or a cesium clock as a reference
    >>to serve as a standard to measure with. Collect statistics for a month
    >>or so.

    >
    >
    >>Then tell us what you learned.

    >
    >
    > You are starting to sound like the cigarette people when it was pointed out
    > that smoking might cause cancer.
    >
    > I was trying to test the algorithms NOT the programs as a whole.
    >
    > I am not advocating that the world rush out and abandon NTP and alkl run
    > chonry. Too many problems. Chrony does not do refclocks. chrony does not
    > handle leap seconds. chrony runs only on Linux ( well a bit on a few others
    > but not many). However where chrony does run it "beats the pants off" ntp.
    > This suggests that the algorithm in chrony is a better clock discipline
    > algorithm than ntp's. Has this been tested extensively? No. Is it a
    > foolproof conclusion? No. But ALL the evidence at present is that chrony's
    > algorithm beats ntp's. If you believe that there are conditions under which
    > ntp's would beat chrony's it now becomes your duty to suggest why and
    > where. "You have not done enough tests" is the response of someone with a
    > completely closed mind.
    >
    > I really do not care what you believe about ntp since you have zero data to
    > back up your position. I am not claiming that ntp fails. It is a robust,
    > well tested algorithm. It works and is certainly "good enough" for almost
    > everyone who uses it. I am asking if it is the best we can do. My data
    > suggests it is not.
    >
    > Note the my latest test was NOT using a local server. It was a remoTE
    > stratum 1 server, over an ADSL hookup with a 16ms delay.
    > It had 100 times the mean delay and 10 times or more the variance in that
    > delay of the "local" test.
    > And exactly what would you expect to find if I ran it for a month rather
    > than a day? Would you really expect something about the chrony algorithm to
    > show up in a month? What? I suspect you have no idea whatsoever as to
    > what the chrony algorithm is so you could not if you wanted to.
    >
    >
    > And I used a GPS PPS as the reference source on the ADSL client to measure
    > the clock offset with.
    >


  13. Re: chrony and ntp comparison-- ADSL hookup

    "David L. Mills" writes:

    >Bill,


    >You hint that it is now the responibility of the NTP crew to rebut your
    >claims. Please see the great detail in Chapter 6 of my book, which


    No. I state that IF someone claims that my results are wrong, it is their
    duty to state why, and present the basis for that claim. Simply telling me
    that I have not done enough measurements without any justifiation as to why
    more measurements might change the results is unacceptable.

    >reports on the resulrs of hundreds of experiments with onboard
    >oscillators, PPS signals, LANs and various Internet paths all over the
    >globe. Included are wedge scattergrams, CDF funtions and time and
    >frequency plots, some covering thousands of hours.


    As I said, ntp IS a well tested stable program. I do not doubt that at all.
    The only question is whether or not it is the best possible. I have
    concentrated on testing the algorithm by contrasting it with a very
    different algorithm for clock discipline.

    Chrony had definite failures. It has not refclock routines, which is a
    serious lack. It runs on only Linux which is a serious limitation. HOwever,
    from the algorithmic point of view it does seem to have definite
    advantages-- speed of adaptation to changes, and accuracy of clock
    discipline seem to be two of them.



    >I've said many times that you are not comparing chrony and NTP on a
    >level field. If you crank the NTP time constant comparable to yours, I
    >strongly expect the two will perform in very similar fashion. In your
    >particular LAN the Allan intercept, or when the phase noise about equals
    >the flicker noise, could be somewhat lower than assumed as default by


    That was why I tested two very different systems. In one the Allan
    intercept is definitely smaller than the default. But it is also one where
    the flicker noise does not follow the model assumed by you and Allan-- and
    it is what a real system produces. In the other the Allan intercept is
    almost certainly much larger than the default. Chrony makes no assumptions
    about the Allan intercept or the behaviour of the flicker noise. ntp does.


    >NTP, but the default depends on a number of considerations other than to
    >minimize the risetime.


    Sure, no question, one of the key being stability of the feedback loop.
    Chrony on the other hand has no feedback loop. (well at second order it
    does, but then ntp's is also more complex than a simple feedback loop with
    its clock filter, and huff and puff filters, etc).



    >The only scientific question of interest here is whether a
    >linear-regression loop is better or worse than a phase-lock loop. Let's
    >not waste time on issues other than that. You can test that by changing
    >probably only a couple lines in your code. Be sure the risetime and
    >overshoot characteristics are similar.


    There is not loop. There is no "risetime" or overshoot. To put is most
    simply, chrony measures the slope and the offset by doing a linear
    regression on the raw time (No change in offset or slope by the clock
    discipline), and then corrects both the slope and the offset of the clock.
    It does not do this with a feedback loop. Thus risetime and overshoot are
    not relevant parameters. It is a very different clock discipline routine
    than ntp's.

    "Feedback" does enter but in a very different way. The number of points
    used to do the linear regression is adaptive-- fewer are used if the
    "linear plus noise" hypothesis is bad. That is a feedback of sorts, but
    very hard to analyse. In the ADSL case, the linear regression is always the
    max number of points (64) because the noise is (almost) all random
    fluctuations of the delay. In the case of low transmission noise, the
    regression tends to be shorter ( eg 20 points but fluctuating) because the
    drift fluctutations dominate. Ie the system automatically adapts to the
    actual "Allan intercept" rather than some assumed one.


    I agree that concentrating on the algorithms is what I want to do.
    I also agree that my measurements are preliminary and have been done on a
    very finite number of systems. But also that at this point simply doing
    "more of the same" is not very useful. If there is some reason to believe
    that there are situations in which ntp will outperform chrony, and which I,
    or someone else, can carry out comparisons for such systems, that would
    certainly be worthwhile.

    I purchased a second GPS precisely to be able to make real comparisons
    between the two. And I am surprized at how well chrony had done. (And I
    have learned a lot both about how ntp and chrony work).

    My biggest surprize with ntp is the clock-filter, in which 85% of the data
    is discarded. While I understand why, it really really feels uncomfortable
    discarding so much data. Even if the data were completely dominated by
    gaussian transmission noise (ie the case in which extra data can be used to
    beat down the variance) ntp chucks 85% of the data. Looking at the data,
    and doing the Pie plots, the justification in my ADSL case for this is
    extremely tenuous. Maybe there exist cases where it were justified( your
    road to Mandalay examples) but surely it would be better to determine
    whether you are in such a situation rather than assuming youare in the
    worst of all possible worlds. (If 85% of the data really is junk, I do not
    believe the remaining 15 % either. In my case, maybe 5% is junk-- ie highly
    biased delays. Chrony is set up to get rid of some of that-- if the deleay
    is greater than 50% greater than the minimum for example). but adapts the
    linear regression to take care of the rest.







    >Dave


    >Unruh wrote:


    >> "Richard B. Gilbert" writes:
    >>
    >>
    >>>Unruh wrote:
    >>>
    >>>>"David J Taylor" writes:
    >>>>
    >>>>
    >>>>
    >>>>>Unruh wrote:
    >>>>>[]
    >>>>>
    >>>>>
    >>>>>>>- the default for min and max poll are 6 and 10 (IIRC), and not 4
    >>>>>>>and 7
    >>>>>>
    >>>>>>
    >>>>>>And so? Exactly how is this supposed to make a difference?
    >>>>>
    >>>>>It means that your tests are not carried out on an "out of the box"
    >>>>>configuration, and therefore perhaps less useful than they might otherwise
    >>>>>be. It's possible that some servers would see min/maxpoll of 4 and 7 as
    >>>>>abusive.
    >>>>
    >>>>
    >>>>And no "out of box" test is possible. Neither ntp ( althoug it is much
    >>>>closer) or chrony are set up to do so.
    >>>>Right now I do not care what servers find abusive. I am using my own
    >>>>server, so I decide what is abusive. I am not advocating these parameters,
    >>>>I am using them to test ntp and chrony. ALL of the tests indicate that
    >>>>chrony disciplines the clock about a factor of 2-3 better than does ntp.

    >>
    >>
    >>>Testing ntpd and chrony using a local server or servers is not a very
    >>>realistic test of "real world" performance!

    >>
    >>
    >>>Try configuring both with the same set of four to ten internet servers.
    >>> Set up a stratum 1 server using GPS or a cesium clock as a reference
    >>>to serve as a standard to measure with. Collect statistics for a month
    >>>or so.

    >>
    >>
    >>>Then tell us what you learned.

    >>
    >>
    >> You are starting to sound like the cigarette people when it was pointed out
    >> that smoking might cause cancer.
    >>
    >> I was trying to test the algorithms NOT the programs as a whole.
    >>
    >> I am not advocating that the world rush out and abandon NTP and alkl run
    >> chonry. Too many problems. Chrony does not do refclocks. chrony does not
    >> handle leap seconds. chrony runs only on Linux ( well a bit on a few others
    >> but not many). However where chrony does run it "beats the pants off" ntp.
    >> This suggests that the algorithm in chrony is a better clock discipline
    >> algorithm than ntp's. Has this been tested extensively? No. Is it a
    >> foolproof conclusion? No. But ALL the evidence at present is that chrony's
    >> algorithm beats ntp's. If you believe that there are conditions under which
    >> ntp's would beat chrony's it now becomes your duty to suggest why and
    >> where. "You have not done enough tests" is the response of someone with a
    >> completely closed mind.
    >>
    >> I really do not care what you believe about ntp since you have zero data to
    >> back up your position. I am not claiming that ntp fails. It is a robust,
    >> well tested algorithm. It works and is certainly "good enough" for almost
    >> everyone who uses it. I am asking if it is the best we can do. My data
    >> suggests it is not.
    >>
    >> Note the my latest test was NOT using a local server. It was a remoTE
    >> stratum 1 server, over an ADSL hookup with a 16ms delay.
    >> It had 100 times the mean delay and 10 times or more the variance in that
    >> delay of the "local" test.
    >> And exactly what would you expect to find if I ran it for a month rather
    >> than a day? Would you really expect something about the chrony algorithm to
    >> show up in a month? What? I suspect you have no idea whatsoever as to
    >> what the chrony algorithm is so you could not if you wanted to.
    >>
    >>
    >> And I used a GPS PPS as the reference source on the ADSL client to measure
    >> the clock offset with.
    >>


+ Reply to Thread