[ntp:questions] Making a clock tell the wrong time?

Mike K Smith mks-usenet at dsl.pipex.com
Tue Mar 10 12:44:41 UTC 2009


> > For testing purposes I want to configure an NTP server to run with a
> > small but known offset. I would like to test at the following offset
> > values 25, 90, 180, 350 and 2500ms.
>
> What is this test intended to prove?
I want to understand how long it takes in practice for an offset to be
propagated from stratum 1 servers through a set of stratum 2 servers
to a stratum 3 client.

I want to see how the poll intervals vary at stratum 2 and 3 in
response to changing time.

I want to verify that a monitoring system which is meant to raise an
alarm when a clock shows an offset greeater than a particular
threshold, does in fact raise that alarm.

This is on an isolated lab network. There are real stratum 1 servers
available, synced to GPS as well as my pseudo-stratum 1 test server.
By using multiple virtual IP addresses I can set the test server to
emulate a majority of clocks so the stratum 2 servers will prefer the
time from my test clock.

> Setting the Undiscplined Local Clock to stratum 0 instead of the default
> stratum 5 does not make it a better "clock". What are you trying to
> accomplish with this?
When my test clock is sitting alongside one or more genuine stratum 1
clocks I want to be sure that the time it presents is treated equally
by the clock selection and filtering algorithms. It would be treated
differently if it ran at stratum 5 alongside a set of stratum 1s.

> > with a fudge line to set the time1 parameter to 90ms.
>
> > The server showed a 90ms offset after the first poll of the local
> > clock, but within a few poll cycles it had discarded the offset.
>
> That's because ntpd disciplined the clock to amortize that offset.
>
> Once this has happened, the clock is now operating at the 90ms offset.
>
> Isn't this what you wanted?

What you describe is what I expected. What I wanted was for that
offset to be reflected in the time output by the ntpd.
What I saw was a very slow slew, which generated about 3ms offset in
an hour - this is just under 1ppm which I would expect from a free-
running local clock which has a fairly current drift correction..

When you talk about the offset being amortized, do you mean that it
has passed to the kernel and the kernel then applies a slew to make
the change?

I repeated the test with an offset of 180ms in the hope that instead
of seeing a slew I would see a step in the output time from ntpd
(after the stepout threshold had elapsed), but again the ntpd just
showed a very small offset.

It may well be that this is normal behaviour for the local clock
driver.
I am now working to configure a serial input to this PC which I think
will use the fudge value in the way that I want.








More information about the questions mailing list