> > 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
