ntpd PLL and clock overshoot - NTP

This is a discussion on ntpd PLL and clock overshoot - NTP ; Guys, In all kernels I have seen over the last several years the adjtime() system call is implemented in the kernel/kern_clock.c kernel module. There may be a library wrapper for it, but the actual adjustment is done in the kernel ...

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

Thread: ntpd PLL and clock overshoot

  1. Re: ntpd PLL and clock overshoot

    Guys,

    In all kernels I have seen over the last several years the adjtime()
    system call is implemented in the kernel/kern_clock.c kernel module.
    There may be a library wrapper for it, but the actual adjustment is done
    in the kernel at each timer interrupt.

    Dave

    Uwe Klein wrote:

    > Hal Murray wrote:
    >
    >> [100% overshoot]
    >>
    >>
    >>> I believe that Dave Mills has already explained that the problem is
    >>> due to changes in the adjtime() routine in both Sun Solaris and Unix.
    >>> This being the case, the choices would seem to be:
    >>> a. Live with it.
    >>> b. Get Sun and the Linux developers to back out the change to
    >>> adjtime() that broke ntpd.
    >>> c. Provide a custom adjtime() for each platform affected. I suspect
    >>> that the routine in question runs in kernel mode and may be part of
    >>> the kernel so that this may be easier said than done!

    >>
    >>
    >>
    >> I assume the fix is something simple like replacing a select with
    >> a simple assignment.
    >>
    >> For Linux, it would help some of us if somebody would track down
    >> the place that needs fixing and publish a diff. I took a quick
    >> scan and didn't find it, but my kernel may be before somebody added
    >> that tweak.
    >>

    > any specifics where to look?
    >
    > the public visible adjtime(x) seems to live in glibc.
    >
    > uwe



  2. Re: ntpd PLL and clock overshoot

    user@domain.invalid wrote:
    > Guys,
    >
    > In all kernels I have seen over the last several years the adjtime()
    > system call is implemented in the kernel/kern_clock.c kernel module.
    > There may be a library wrapper for it, but the actual adjustment is done
    > in the kernel at each timer interrupt.


    Hey user ;-)

    Which Linux SemiMajor version (are you | is being) referencing : 2.[0,2,4,6] ?

    PRE:
    i don't know **** about ntpd related timehandling with linux (yet).
    I've done realtime stuff on linux 2.2, 2.4 ( started with 2.6 ).
    up to now i have used one ntpd synced (black)box to do bookkeeping on
    timeslip of my embedded and rather undermuscled (SC400/8MB) RT thingies.
    fixing slip by adjusting my timeconstants, doing nothing against jitter.
    ( time corrections do not reach the RT clock anyway.)

    Which Linux SemiMajor version are you referencing 2.[0,2,4,6] ?
    recent sources of linux 2.6.1n seem to be extensively revamped. the mentioned
    files and functions are not present.
    "something" seems to have been moved into the high resolution timer stuff.
    How current is the ntpd developers picture of recent linux ?

    POST:
    I am in the process of building and deploying distributed sweep receivers
    (that replace a single 4 Band receiver at the end of several hundred feet of koax)
    that have to run in sync ( <10ms ).
    my interest here is do i stay with my current method or can i leverage
    ntpd to do housekeeping for my little boxes and adjust hardware clockrate
    in some way ( VCXO, or just heating up the builtin Xtal )

    uwe


  3. Re: ntpd PLL and clock overshoot

    Uwe,

    I have made the point on past occasions that NTP may be more valuable as
    a hardware/software canary than as a clock winder.

    Guys,

    Please forgive the broken "from" line in some of my messages.
    Apparently, the problem is not in the news server here, but may be in
    Netscape 7.2, which I have been using for some time and didn't use to do
    that offense. Workin' on it.

    Dave

    Uwe Klein wrote:
    > David L. Mills wrote:
    >
    >> With all of the machines here, including FreeBSD, Solaris, HP-UX,
    >> SunOS, Tru64 and HP-UX, the loop response in steady state is as I
    >> reported earlier. The results with Linux are highly suspect, as at
    >> least in some cases the timer interrupt frequency has been changed
    >> significantly without compensation in the kernel parameters. I have
    >> recommended to avoid Linux in any case involving precision timekeeping.

    >
    >
    > Hello Dave,
    > there is at least one issue with APIC routed interupts on linux running
    > on nVidia nForce 1 and 2 based Boards resulting in a too fast and
    > irregular clock.
    >
    > It seems the timer interrupt is handled _twice_ on occasion.
    >
    > I have A7N266-E and A7N8X-E boards produce this problem with various
    > kernels
    > in the 2.6.1n range.
    >
    > The same boards ran ntpd on linux 2.4 and no APIC routing just perfect.
    >
    > Symtoms:
    > The clock starts to run ahead by ~8-900ppm resulting in hard correction
    > of -.5 to -1.5 seconds every couple of hours. Adjusting the system tick
    > value
    > results in symetric corrections +.5 .. -.5 which would indicate an
    > extremely
    > unstable clock.
    >
    > This started out for me as a problem with ntpd not syncing
    > BUT is now Linux/Hardware related with ntpd being the whistle-blower.
    >
    > One of the reasons i started reading this group some weeks ago.
    >
    > uwe


  4. Re: ntpd PLL and clock overshoot

    David L. Mills wrote:
    > Uwe,
    >
    > I have made the point on past occasions that NTP may be more valuable as
    > a hardware/software canary than as a clock winder.


    Hello Dave,
    I like canarys that can do other tricks as well ;-)

    actually i have been a happy ntpd-user both on my home-network and for
    the stuff i have running at my customers site (watching the radio sun)
    for years without having to do any source-diving.
    I had some starting problems with "iburst" and the initial request interval
    ( over ISDN dial on demand PPP ) but those have been fixed for a long time
    now.

    uwe


  5. Re: ntpd PLL and clock overshoot

    In article ,
    David L. Mills wrote:

    > You are victim of faulty engineering intuition. See Chapter 4 in The
    > Book. See the graphs therein showing the response to initial


    Don't have easy access to the book, but looking at the PDF version
    of NTP Clock Discipline Principles, dated 2004-08-24, the case we are
    discussing here starts in state FSET, gets a type 0 event and
    goes to TSET, with no side effects, then gets another type 0 event and
    transitions to state SYNC, resetting the stepout timer and starting
    to feed the semi-linear part of the control loop. It does this because
    the initial error is only 90ms and because there is an ntp.drift
    file.

    That effectively short circuits the state machine logic after only one
    sample, so the start up behaviour is completely dominated by the PLL/FLL.

    The person reporting the symptom knows he is using an accurate radio
    clock and probably believes that the true phase noise is 100 microseconds
    or less, but actually sees the phase take significant time to reach zero
    error and then proceed to overshoot to 9ms in the other direction.

    It looks to me that the only way that he is going to get fast convergence
    under these conditions is by tinkering the step limit to 1ms or less
    (better: several standard deviations larger than the expected phase
    noise). However tinkering is discouraged and sometimes causes other
    features to be turned off.

    His other option, I suppose, is to deliberately set the clock wrongly
    so that it is guaranteed to be out by more than 128ms.

    Basically, you only get the good performance documented in the PDF file
    if the initial error is either negligible, or is quite large.

    > Your scenario where the operator slings the frequency as the response
    > crosses zero is equivalent to a frequency-lock model which disregards
    > the initial phase error. This is in fact the model for the initial
    > frequency estimate when the frequency file has not yet been created.


    That is a transition from zero frequency correction to the estimated
    required correction. The scenario I was considering was a transition from
    a maximum (positive or negative) correction to the nominal value.

    By the way, looking at the state diagram in that PDF file, I can only make
    sense of it if I assume that the arcs from SYNC for events 1 and 2 have
    had their labels mixed up.

  6. Re: ntpd PLL and clock overshoot

    In article ,
    "user@domain.invalid" (David Mills???????) wrote:

    > Look more carefully at the clock state machine. If the initial offset is
    > greater than the step threshold, the clock is set, which results in an


    In the case in question, it was just under 90ms, so this condition
    is not true.

    > initial offset of zero. After the stepout interval the frequency is
    > measured and corrected, but the phase at that time could be quite large,


    There's no frequency measurement because the offset was less than the
    time limit, and, I presume, this wasn't the very first time that ntpd
    was started.

    > threshold, ordinary linear mode results. This is NOT overshoot, just an
    > initial phase error.


    But it's not applicable here because there has been no use of the 900
    second stepout timer.

    > If the initial offset is less than the step threshold, the freqjuency
    > measurement is made, but the phase is disciplined normally during the


    Only if it starts in state NSET, i.e no ntp.drift. Although the
    person making the original 10% overshoot report really ought to confirm
    this, I'd be very surprised if there weren't a valid ntp.drift file,
    in which case it starts in state FSET and, because the initial offset
    is less than 128ms, almost immediately goes into the FLL/PLL phase.

    > stepout interval. Again, this could result in a phase offset after the
    > stepout interval, but this is NOT overshoot.


    But, again, its a scenario that doesn't apply here.

  7. Re: ntpd PLL and clock overshoot

    David Woolley wrote:

    > In article ,
    > David L. Mills wrote:
    >
    >
    >>You are victim of faulty engineering intuition. See Chapter 4 in The
    >>Book. See the graphs therein showing the response to initial

    >
    >
    > Don't have easy access to the book, but looking at the PDF version
    > of NTP Clock Discipline Principles, dated 2004-08-24, the case we are
    > discussing here starts in state FSET, gets a type 0 event and
    > goes to TSET, with no side effects, then gets another type 0 event and
    > transitions to state SYNC, resetting the stepout timer and starting
    > to feed the semi-linear part of the control loop. It does this because
    > the initial error is only 90ms and because there is an ntp.drift
    > file.
    >
    > That effectively short circuits the state machine logic after only one
    > sample, so the start up behaviour is completely dominated by the PLL/FLL.
    >
    > The person reporting the symptom knows he is using an accurate radio
    > clock and probably believes that the true phase noise is 100 microseconds
    > or less, but actually sees the phase take significant time to reach zero
    > error and then proceed to overshoot to 9ms in the other direction.


    I have seen EXACTLY this behavior with ntpd and my Motorola Oncore.
    Ntpd started up with a 90 millisecond positive offset, overshot to minus
    nine milliseconds. . . . It took about thirty minutes get really
    tight synchronization. Solaris 8.

  8. Re: ntpd PLL and clock overshoot

    Davod.

    In the semi-linear scenario you describe, and with the default poll
    interval of 64 s, the response crosses zero in about 3000 s. The zero
    crossing is directly dependent on the poll interval, but the overshoot
    is not. Setting the poll interval to 16 s results in a zero crossing of
    about 750 s. It can't be set less than that because the adjustment
    interval is fixed at 1 s. With the kernel code the poll interval can in
    principle be set less than 16 s, but that extreme is really not a good idea.

    Setting the step threshold less than the default has no effect other
    than the state machine, but would make the Lamporter among use real
    squirrely. Most squirrels want to set it higher.

    I'm not sure what the agenda here has become, but I think just about
    anything that can be said about it has been said.

    Dave

    David Woolley wrote:
    > In article ,
    > David L. Mills wrote:
    >
    >
    >>You are victim of faulty engineering intuition. See Chapter 4 in The
    >>Book. See the graphs therein showing the response to initial

    >
    >
    > Don't have easy access to the book, but looking at the PDF version
    > of NTP Clock Discipline Principles, dated 2004-08-24, the case we are
    > discussing here starts in state FSET, gets a type 0 event and
    > goes to TSET, with no side effects, then gets another type 0 event and
    > transitions to state SYNC, resetting the stepout timer and starting
    > to feed the semi-linear part of the control loop. It does this because
    > the initial error is only 90ms and because there is an ntp.drift
    > file.
    >
    > That effectively short circuits the state machine logic after only one
    > sample, so the start up behaviour is completely dominated by the PLL/FLL.
    >
    > The person reporting the symptom knows he is using an accurate radio
    > clock and probably believes that the true phase noise is 100 microseconds
    > or less, but actually sees the phase take significant time to reach zero
    > error and then proceed to overshoot to 9ms in the other direction.
    >
    > It looks to me that the only way that he is going to get fast convergence
    > under these conditions is by tinkering the step limit to 1ms or less
    > (better: several standard deviations larger than the expected phase
    > noise). However tinkering is discouraged and sometimes causes other
    > features to be turned off.
    >
    > His other option, I suppose, is to deliberately set the clock wrongly
    > so that it is guaranteed to be out by more than 128ms.
    >
    > Basically, you only get the good performance documented in the PDF file
    > if the initial error is either negligible, or is quite large.
    >
    >
    >>Your scenario where the operator slings the frequency as the response
    >>crosses zero is equivalent to a frequency-lock model which disregards
    >>the initial phase error. This is in fact the model for the initial
    >>frequency estimate when the frequency file has not yet been created.

    >
    >
    > That is a transition from zero frequency correction to the estimated
    > required correction. The scenario I was considering was a transition from
    > a maximum (positive or negative) correction to the nominal value.
    >
    > By the way, looking at the state diagram in that PDF file, I can only make
    > sense of it if I assume that the arcs from SYNC for events 1 and 2 have
    > had their labels mixed up.


  9. Re: ntpd PLL and clock overshoot

    Richard,

    You say the initial offset starts out at +90 ms and then "overshoots to
    -9 ms". It can't do that; the PLL/FLL impulse response with default poll
    interval crosses zero in about 3000 s, then about 6
    percent. Even if you set the poll interval to the minimum 16 s, the zero
    crossing would be about 750 s with identical overshoot.

    What you describe looks like the clock is being set directly, not
    disciplined by the PLL/FLL loop, or the adjtime() system call is broken,
    as discussed previously. The discipline loop acts as a lowpass filter;
    it cannot torque the offset "quickly" as you describe.

    I do assume your ntpd code is relatively recent, like in the last year
    or two. While some details of the ntpd initial training states have
    changed in minor ways, the semi-linear PLL/FLL loop has been unchanged
    for some time. The old xntpd code was seriously broken in this area and
    displayed ntpq data that could be in serious error.

    Dave

    Richard B. Gilbert wrote:

    > David Woolley wrote:
    >
    >> In article ,
    >> David L. Mills wrote:
    >>
    >>
    >>> You are victim of faulty engineering intuition. See Chapter 4 in The
    >>> Book. See the graphs therein showing the response to initial

    >>
    >>
    >>
    >> Don't have easy access to the book, but looking at the PDF version
    >> of NTP Clock Discipline Principles, dated 2004-08-24, the case we are
    >> discussing here starts in state FSET, gets a type 0 event and
    >> goes to TSET, with no side effects, then gets another type 0 event and
    >> transitions to state SYNC, resetting the stepout timer and starting
    >> to feed the semi-linear part of the control loop. It does this because
    >> the initial error is only 90ms and because there is an ntp.drift
    >> file.
    >>
    >> That effectively short circuits the state machine logic after only one
    >> sample, so the start up behaviour is completely dominated by the PLL/FLL.
    >>
    >> The person reporting the symptom knows he is using an accurate radio
    >> clock and probably believes that the true phase noise is 100 microseconds
    >> or less, but actually sees the phase take significant time to reach zero
    >> error and then proceed to overshoot to 9ms in the other direction.

    >
    >
    > I have seen EXACTLY this behavior with ntpd and my Motorola Oncore. Ntpd
    > started up with a 90 millisecond positive offset, overshot to minus
    > nine milliseconds. . . . It took about thirty minutes get really
    > tight synchronization. Solaris 8.


  10. Re: ntpd PLL and clock overshoot

    David L. Mills wrote:
    > Richard,
    >
    > You say the initial offset starts out at +90 ms and then "overshoots to
    > -9 ms". It can't do that; the PLL/FLL impulse response with default poll
    > interval crosses zero in about 3000 s, then about 6
    > percent. Even if you set the poll interval to the minimum 16 s, the zero
    > crossing would be about 750 s with identical overshoot.
    >
    > What you describe looks like the clock is being set directly, not
    > disciplined by the PLL/FLL loop, or the adjtime() system call is broken,
    > as discussed previously. The discipline loop acts as a lowpass filter;
    > it cannot torque the offset "quickly" as you describe.
    >
    > I do assume your ntpd code is relatively recent, like in the last year
    > or two. While some details of the ntpd initial training states have
    > changed in minor ways, the semi-linear PLL/FLL loop has been unchanged
    > for some time. The old xntpd code was seriously broken in this area and
    > displayed ntpq data that could be in serious error.
    >
    > Dave
    >
    > Richard B. Gilbert wrote:
    >
    >> David Woolley wrote:
    >>
    >>> In article ,
    >>> David L. Mills wrote:


    Pretty recent:

    sunblok_$ ntpq -crv
    assID=0 status=04c4 leap_none, sync_uhf_clock, 12 events,
    event_peer/strat_chg,
    version="ntpd 4.2.1p241-RC@1.1498 Wed Apr 26 20:16:54 EDT 2006 (1)",
    processor="sun4u", system="SunOS/5.8", leap=00, stratum=1,
    precision=-21, rootdelay=0.000, rootdispersion=0.371, peer=42873,
    refid=GPS, reftime=c8dfa4cd.4c7f32bc Tue, Oct 17 2006 14:51:57.298,
    poll=4, clock=c8dfa4d4.d4e8a36a Tue, Oct 17 2006 14:52:04.831, state=4,
    offset=0.000, frequency=12.473, jitter=0.001, noise=0.001,
    stability=0.000

    I'll save the log file and the stats files the next time I'm forced to
    restart it. We used to have almost monthly power outrages which
    necessitated a a warm restart but a neighbor was persuaded to trim some
    trees that were actually touching the power lines and it's been months
    since the power went off!

  11. Re: ntpd PLL and clock overshoot

    Dave,

    user@domain.invalid wrote:
    > I beg to seriously differ. To the extent the z transform of the impulse
    > response preserves the poles and zeros of the poplynomial
    > representation, the digital NTP loop behaves as an analog loop, at least
    > in the linear regime of operation.
    >
    > The initial frequency estimate measures only the frequency offset; the
    > phase offset is left to fend for itsel, which could indeed result in an
    > initial offset exceeding the "overshoot" target. The purpose of the
    > state machine in the first place is to allow large initial poll
    > intervals, as with telephone modem services.


    It's been a long time since I've learned the basics of control, and I'm not
    as familiar with the maths as you are. However, I've heard many people
    saying that the current implementation of the control loop is very slow,
    whereas it has converged faster in earlier implementations of ntpd.

    I've run some simple tests on Windows 2000 machine which has a single
    upstram NTP server configured. The upstream server is a GPS based stratum-1
    machine under Linux on the local LAN, and the time differences on the
    client have been computed between the local system time and a GPS PCI card
    plugged into the client.

    Please note the initial offset of a few milliseconds which is intentional in
    order to see how the filters converge. This is the result of a recent
    ntp-dev version ntp-4.2.3p51:
    http://www.meinberg.de/download/ntp/...p-4.2.3p51.pdf
    You see it takes about 100000 seconds (more than a day!) to get from about
    15 milliseconds down to about 2 milliseconds offset.

    As a comparison I've done the same once more with a pretty old version of
    ntpd, ntp-4.0.99:
    http://www.meinberg.de/download/ntp/...ntp-4.0.99.pdf
    The older implementation of ntpd is compensating the initial offset in about
    20000 seconds, more than 5 hours, which is still more than one would
    expect.

    We can take a closer look at the startup of 4.0.99:
    http://www.meinberg.de/download/ntp/...99.startup.pdf

    During the first 200 seconds we see the initial step of the system time, and
    the drift of the system time while the tick adjustment value is at its
    default value.

    Then ntpd starts to correct the initial offset properly in less than 300
    seconds. This looks like it was going to converge properly. However,
    unfortunately at a 10 ms offset the filter algorithm seems to switch and
    the following correction is still very poor compared to the initial
    correction.

    I think even though a very slow correction could be useful for some systems
    with polling rates of 36 hours and more, most installed instances of ntpd
    could provide much better performance with a faster control loop.

    And, this does not seem to be a Windows problem since we also have observed
    this slow convergence under different operating systems.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  12. Re: ntpd PLL and clock overshoot

    Martin Burnicki wrote:
    > Then ntpd starts to correct the initial offset properly in less than 300
    > seconds. This looks like it was going to converge properly. However,
    > unfortunately at a 10 ms offset the filter algorithm seems to switch and
    > the following correction is still very poor compared to the initial
    > correction.


    Martin, the 10 ms behavior is pretty much a given, since the OS clock
    works at the same 10 ms resolution!

    The realtime thread hack to interpolate between OS ticks does help, but
    NTPD still needs a lot of statistical data to be able to settle down at
    offset values well below the OS tick!

    Terje

    --
    -
    "almost all programming can be viewed as an exercise in caching"

  13. Re: ntpd PLL and clock overshoot

    Terje,

    Terje Mathisen wrote:
    > Martin Burnicki wrote:
    >> Then ntpd starts to correct the initial offset properly in less than 300
    >> seconds. This looks like it was going to converge properly. However,
    >> unfortunately at a 10 ms offset the filter algorithm seems to switch and
    >> the following correction is still very poor compared to the initial
    >> correction.

    >
    > Martin, the 10 ms behavior is pretty much a given, since the OS clock
    > works at the same 10 ms resolution!


    This is not quite true. At least in Windows 2000 the clock tick interval
    seems to depend on the CPU speed or whatever. I've seen nominal tick reload
    values of 100144 (10.0144 ms tick interval) on older systems, whereas the
    same version of the OS installed on a system with more CPU power had
    156250, resulting in a timer tick interval of 15.6250 ms. Except some very
    old machines I have no more machines around here which use the 10 ms tick
    interval.

    > The realtime thread hack to interpolate between OS ticks does help, but
    > NTPD still needs a lot of statistical data to be able to settle down at
    > offset values well below the OS tick!


    From what I've seen the interpolation thread works very well to increase the
    resolution of the system clock beyond the 10 or 15 millisecond limit, at
    least to 1 ms or so. So the ntpd filters should not be aware of a 10 ms
    limit.

    And we also see that ntpd can discipline the system time down to the 1 or 2
    ms level. However, this takes _very_ long for recent implementations. Older
    implementations achieved this much faster, though this also had not been
    optimal.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  14. Re: ntpd PLL and clock overshoot

    Uwe,

    I upgraded to Netscape 7.2 on the hope that would fix the bogus from
    address. Stay tuned.

    Using Linux of any version anywhere here is strictly forbidden. Does
    that answer your question?

    Dave

    Uwe Klein wrote:
    > user@domain.invalid wrote:
    >
    >> Guys,
    >>
    >> In all kernels I have seen over the last several years the adjtime()
    >> system call is implemented in the kernel/kern_clock.c kernel module.
    >> There may be a library wrapper for it, but the actual adjustment is
    >> done in the kernel at each timer interrupt.

    >
    >
    > Hey user ;-)
    >
    > Which Linux SemiMajor version (are you | is being) referencing :
    > 2.[0,2,4,6] ?
    >
    > PRE:
    > i don't know **** about ntpd related timehandling with linux (yet).
    > I've done realtime stuff on linux 2.2, 2.4 ( started with 2.6 ).
    > up to now i have used one ntpd synced (black)box to do bookkeeping on
    > timeslip of my embedded and rather undermuscled (SC400/8MB) RT
    > thingies.
    > fixing slip by adjusting my timeconstants, doing nothing against
    > jitter.
    > ( time corrections do not reach the RT clock anyway.)
    >
    > Which Linux SemiMajor version are you referencing 2.[0,2,4,6] ?
    > recent sources of linux 2.6.1n seem to be extensively revamped. the
    > mentioned
    > files and functions are not present.
    > "something" seems to have been moved into the high resolution timer stuff.
    > How current is the ntpd developers picture of recent linux ?
    >
    > POST:
    > I am in the process of building and deploying distributed sweep
    > receivers
    > (that replace a single 4 Band receiver at the end of several hundred
    > feet of koax)
    > that have to run in sync ( <10ms ).
    > my interest here is do i stay with my current method or can i leverage
    > ntpd to do housekeeping for my little boxes and adjust hardware
    > clockrate
    > in some way ( VCXO, or just heating up the builtin Xtal )
    >
    > uwe
    >


  15. Re: ntpd PLL and clock overshoot

    Martin,

    I don't know wehat to tell you. I have about two dozen machines nearby
    that do not behave as you report. First, be sure to understand the phase
    (offset) response is strictly proportional to the poll interval. At the
    default poll interval of 64 s, the offset crosses zero in about 3000 s.
    However, if there is significant frequency error, that can take much
    longer (hours to a day) to converge. Meanwhile, the poll interval might
    have ramped up due the intended design, so the convergence can be much
    longer. That is the intended design; once the initial phase/frequency
    transient has subsided, the time offsets in a configuration like yours
    are normally less than 100 microseconds. See rackety.udel.edu and/or
    pogo.udel.edu with ntpq for nominal behavior.

    Dave

    Martin Burnicki wrote:

    > Dave,
    >
    > user@domain.invalid wrote:
    >
    >>I beg to seriously differ. To the extent the z transform of the impulse
    >>response preserves the poles and zeros of the poplynomial
    >>representation, the digital NTP loop behaves as an analog loop, at least
    >>in the linear regime of operation.
    >>
    >>The initial frequency estimate measures only the frequency offset; the
    >>phase offset is left to fend for itsel, which could indeed result in an
    >>initial offset exceeding the "overshoot" target. The purpose of the
    >>state machine in the first place is to allow large initial poll
    >>intervals, as with telephone modem services.

    >
    >
    > It's been a long time since I've learned the basics of control, and I'm not
    > as familiar with the maths as you are. However, I've heard many people
    > saying that the current implementation of the control loop is very slow,
    > whereas it has converged faster in earlier implementations of ntpd.
    >
    > I've run some simple tests on Windows 2000 machine which has a single
    > upstram NTP server configured. The upstream server is a GPS based stratum-1
    > machine under Linux on the local LAN, and the time differences on the
    > client have been computed between the local system time and a GPS PCI card
    > plugged into the client.
    >
    > Please note the initial offset of a few milliseconds which is intentional in
    > order to see how the filters converge. This is the result of a recent
    > ntp-dev version ntp-4.2.3p51:
    > http://www.meinberg.de/download/ntp/...p-4.2.3p51.pdf
    > You see it takes about 100000 seconds (more than a day!) to get from about
    > 15 milliseconds down to about 2 milliseconds offset.
    >
    > As a comparison I've done the same once more with a pretty old version of
    > ntpd, ntp-4.0.99:
    > http://www.meinberg.de/download/ntp/...ntp-4.0.99.pdf
    > The older implementation of ntpd is compensating the initial offset in about
    > 20000 seconds, more than 5 hours, which is still more than one would
    > expect.
    >
    > We can take a closer look at the startup of 4.0.99:
    > http://www.meinberg.de/download/ntp/...99.startup.pdf
    >
    > During the first 200 seconds we see the initial step of the system time, and
    > the drift of the system time while the tick adjustment value is at its
    > default value.
    >
    > Then ntpd starts to correct the initial offset properly in less than 300
    > seconds. This looks like it was going to converge properly. However,
    > unfortunately at a 10 ms offset the filter algorithm seems to switch and
    > the following correction is still very poor compared to the initial
    > correction.
    >
    > I think even though a very slow correction could be useful for some systems
    > with polling rates of 36 hours and more, most installed instances of ntpd
    > could provide much better performance with a faster control loop.
    >
    > And, this does not seem to be a Windows problem since we also have observed
    > this slow convergence under different operating systems.
    >
    > Martin


  16. Re: ntpd PLL and clock overshoot

    Terje,

    I put a good deal of effort in the detailed calculations, especially the
    rounding issues. Even with uninterpolated 10-ms tick interval, the
    results are surprisingly good. In fact, I have tested it with tinkered
    1-s tick (!) and it ain't half bad.

    Dave

    Terje Mathisen wrote:

    > Martin Burnicki wrote:
    >
    >> Then ntpd starts to correct the initial offset properly in less than 300
    >> seconds. This looks like it was going to converge properly. However,
    >> unfortunately at a 10 ms offset the filter algorithm seems to switch and
    >> the following correction is still very poor compared to the initial
    >> correction.

    >
    >
    > Martin, the 10 ms behavior is pretty much a given, since the OS clock
    > works at the same 10 ms resolution!
    >
    > The realtime thread hack to interpolate between OS ticks does help, but
    > NTPD still needs a lot of statistical data to be able to settle down at
    > offset values well below the OS tick!
    >
    > Terje
    >


  17. Re: ntpd PLL and clock overshoot

    user@domain.invalid wrote:

    > Uwe,
    >
    > I upgraded to Netscape 7.2 on the hope that would fix the bogus from
    > address. Stay tuned.
    >


    Dave,

    Netscape 7.2 didn't do a thing for your address problem!

    In Netscape mail, click on Edit and select Mail and Newsgroup Account
    Settings. That should both show you what Netscape Mail thinks your
    address is and also allow you to change it!



  18. Re: ntpd PLL and clock overshoot

    user@domain.invalid wrote:
    > Uwe,
    >
    > I upgraded to Netscape 7.2 on the hope that would fix the bogus from
    > address. Stay tuned.
    >
    > Using Linux of any version anywhere here is strictly forbidden. Does
    > that answer your question?

    Hey user,

    Hm, I'l find a non offending name for it.

    Do the NTPoliceD's need search warants
    or will they just smash my port 123 to pieces ?


    uwe

  19. Re: ntpd PLL and clock overshoot

    "Martin Burnicki" wrote in message
    news:lcsh04-btd.ln1@gateway.py.meinberg.de...

    > [...] At least in Windows 2000 the clock tick interval seems to depend
    > on the CPU speed or whatever. I've seen nominal tick reload values
    > of 100144 (10.0144 ms tick interval) on older systems, whereas the
    > same version of the OS installed on a system with more CPU power had
    > 156250, resulting in a timer tick interval of 15.6250 ms.


    That still doesn't mean that the time can't be queried to better than
    1/100 or 1/64 of a second.

    Is it possible that installing a .Net framework changes the clock tick
    from 100Hz to 64Hz?

    Groetjes,
    Maarten Wiltink



  20. Re: ntpd PLL and clock overshoot

    Maarten,

    Maarten Wiltink wrote:
    > "Martin Burnicki" wrote in message
    > news:lcsh04-btd.ln1@gateway.py.meinberg.de...
    >
    >> [...] At least in Windows 2000 the clock tick interval seems to depend
    >> on the CPU speed or whatever. I've seen nominal tick reload values
    >> of 100144 (10.0144 ms tick interval) on older systems, whereas the
    >> same version of the OS installed on a system with more CPU power had
    >> 156250, resulting in a timer tick interval of 15.6250 ms.

    >
    > That still doesn't mean that the time can't be queried to better than
    > 1/100 or 1/64 of a second.


    Don't know what you mean here. Event though some of the Windows APIs return
    time stamps in 100 nanosecond resolution, those time stamps have exactly
    the same value during a whole timer tick interval. After the next timer
    tick the time stamp has increased by the interval time.

    I've written a little command line utility for Windows called wclkres which
    continuously reads those Windows system time stamps and prints the
    difference whenever the value of the returned time stamp changes:
    http://www.meinberg.de/download/util...clkres-1.1.zip

    The behaviour mentioned above is exactly the reason why the Windows port of
    ntpd runs a real time thread which interpolates the system time between 2
    timer ticks using the Windows performance counter.

    > Is it possible that installing a .Net framework changes the clock tick
    > from 100Hz to 64Hz?


    I don't think this is the reason. I've installed the same W2K version from
    the same CD on different machines, and on the older slower ones the tick
    adjust value was 100144 while on faster machines it was 156250.

    Don't know what XP and newer does on slow machines, though. On all current
    installations I've seen the tick value is 156250, but this may me because
    all those machines have fast CPUs.

    I've written a little command line utility for Windows called log_adj which
    also displays the current tick adjustment value and its offset from the
    default tick value:
    http://www.meinberg.de/download/util...og_adj-1.4.zip

    The readme file in the ZIP archive explains what the program does.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2