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 ...
-
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!
-
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
-
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!
-
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