Not-So-Newbie question - NTP

This is a discussion on Not-So-Newbie question - NTP ; OK, so I first set up NTP about 11 years ago. Pointed the (NIS/NFS!) server at a Stratum 1 clock and then multicast time out to anyone who wanted it (I set up all the workstations to listen to multicast ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Not-So-Newbie question

  1. Not-So-Newbie question

    OK, so I first set up NTP about 11 years ago. Pointed the (NIS/NFS!)
    server at a Stratum 1 clock and then multicast time out to anyone who
    wanted it (I set up all the workstations to listen to multicast - I think
    that was the default if you enabled NTP in Solaris).

    I've since been playing with it in ever more complicated scenarios and now
    have two Stratum 1 clocks (and probably a 3rd soon) and several Stratum 2s
    for user access.

    Yesterday, I added another Stratum 2 to the group and for some reason, it
    seems to be taking a long time to get stabilized. Part of the problem, I
    think, is that it's running off a Knoppix CD (it's an NPAD test system). I
    worked around the fact that the drift file, by default, had 0.00 in it, but
    I don't think that's an issue since I've restarted the daemon a number of
    times tweaking things. Other systems of the same HW type didn't take this
    long.

    My real question is this: What am I really looking at in the offset and
    jitter columns? What makes a "good server" in terms of ntpq -p output?
    Low offset? Low jitter? Some combination?

    --
    Peter Laws / N5UWY
    National Weather Center / Network Operations Center
    University of Oklahoma Information Technology
    plaws@ou.edu
    -----------------------------------------------------------------------
    Feedback? Contact my director, Craig Cochell, craigc@ou.edu. Thank you!

  2. Re: Not-So-Newbie question

    Peter,

    Peter Laws wrote:
    [...]
    > Yesterday, I added another Stratum 2 to the group and for some reason, it
    > seems to be taking a long time to get stabilized. Part of the problem, I
    > think, is that it's running off a Knoppix CD (it's an NPAD test system). I
    > worked around the fact that the drift file, by default, had 0.00 in it,
    > but I don't think that's an issue since I've restarted the daemon a number
    > of
    > times tweaking things. Other systems of the same HW type didn't take this
    > long.


    Maybe it's a problem of the Linux kernel version you are using. There have
    been quite a few reports where recent kernels were unable to keep good time
    on certain hardware. If the system clock timekeeping is bad (with jitter)
    then ntpd has not much chance to discipline it.

    > My real question is this: What am I really looking at in the offset and
    > jitter columns? What makes a "good server" in terms of ntpq -p output?
    > Low offset? Low jitter? Some combination?


    Depending on what causes the jitter and offset. If timekeeping by the kernel
    is poor the this may also cause high jitter and offsets.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: Not-So-Newbie question

    Martin Burnicki wrote:
    > Peter,
    >
    > Peter Laws wrote:
    > [...]
    >> Yesterday, I added another Stratum 2 to the group and for some reason, it
    >> seems to be taking a long time to get stabilized. Part of the problem, I
    >> think, is that it's running off a Knoppix CD (it's an NPAD test system). I


    >
    > Maybe it's a problem of the Linux kernel version you are using. There have



    Turns out I'm just not patient enough. This particular system takes a long
    time to stabilize. I talked to the folks that put together the Knoppix ISO
    and they are going to fix the drift file issue in the next release. I
    could do it myself, but this is a network speed test system and it's much
    easier for me to just be able to 1) reboot if there is any kind of
    compromise and 2) swap CDs and reboot if there is an update to the image.



    >
    >> My real question is this: What am I really looking at in the offset and
    >> jitter columns? What makes a "good server" in terms of ntpq -p output?
    >> Low offset? Low jitter? Some combination?

    >
    > Depending on what causes the jitter and offset. If timekeeping by the kernel
    > is poor the this may also cause high jitter and offsets.


    I'm really looking for more general answers to this question.

    I know (or think I know) that delay is just a measure of how far away
    another server is, offset is just how far off the local system thinks the
    distant server is from the One True Time, and low jitter is good ...

    But .... how low does jitter have to be to be "good enough"? How do the
    three relate to one another?



    --
    Peter Laws / N5UWY
    National Weather Center / Network Operations Center
    University of Oklahoma Information Technology
    plaws@ou.edu
    -----------------------------------------------------------------------
    Feedback? Contact my director, Craig Cochell, craigc@ou.edu. Thank you!

  4. Re: Not-So-Newbie question

    Peter Laws wrote:
    > Martin Burnicki wrote:
    >> Depending on what causes the jitter and offset. If timekeeping by the
    >> kernel is poor the this may also cause high jitter and offsets.

    >
    > I'm really looking for more general answers to this question.
    >
    > I know (or think I know) that delay is just a measure of how far away
    > another server is, offset is just how far off the local system thinks the
    > distant server is from the One True Time, and low jitter is good ...
    >
    > But .... how low does jitter have to be to be "good enough"? How do the
    > three relate to one another?


    I think this is one of the basic questions. Of course the lower the jitter
    the better the results since (simply spoken) the packet turnaround times
    are then constant and thus can be determined and compensated.

    However, in practice the jitter can be large or small, but it will never be
    zero. So it's good to configure several upstream time source (especially if
    they are NTP servers on the internet), let ntpd determine the offset and
    jitter of each time source, and let ntpd decide which time sources to use
    to yield the best possible time synchronization.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

+ Reply to Thread