1

I have recently been doing a specific timing analysis of the performance of NTP under controlled conditions.  The experiment I performed was conceptually quite simple.  I have an NTP server running somewhere on my network (this is my own server with its own integrated GPS receiver).

  • on a specific machine, I turn off the NTP client
  • I manually offset the machine's system time by N ms (where I tried N = 50 ms and 500 ms)
  • at once, I turn on the machine's NTP client
  • and I monitor the behavior of the machine's system time to see how it brings the system time back in synch with NTP time.
  • Finally, I repeat the above operations LOTS (hundreds) of times to get good statistics on that.

To answer one of the comments here, I make it clear that the utility acting as ntp client is: chronyd and the utility acting as ntp server is whatever program is running on the NTP server hardware : SyncServer S600.

Here's what I observed.  First, the NTP client takes 5 seconds of "thinking" before it does anything.  Then, once it starts acting on the machine's system time, it adjusts that system time continuously at a rate of 100 ms per second (in other words, if the offset between the machine's system time and the NTP time was 500 ms, it takes 5 seconds to bring that offset back down close to 0 ms). This behavior is visible in the attached plot:

NTP timing graph

SO, as a non-NTP expert, I wonder:

  • where are the settings/configuration for NTP to behave in that manner?
  • specifically, what is it doing for those 5 seconds of waiting?
  • where is the configuration for that slew rate of 100 ms per second?
  • Finally, not shown in here, but somehow, NTP actually changes the drift rate or the frequency of the system clock.  I know this because, after having left NTP on for some time, if I turn it off, then the drift between the system time and the NTP time remains almost zero (or very low), at least much much lower than if I had just rebooted that machine from scratch. So there is some information of the adjustment done by NTP that remains locked in the system time even after turning NTP off. Where and how is that done?

I realise that's a few different questions, but I'm trying to dig deeper to understand the behavior of NTP, and if all of those are hardwired in the server (or client) or if those are configuration changeable.

Improve this question
0

1 Answer 1

Reset to default
1

Then, once it starts acting on the machine's system time, it adjusts that system time continuously at a rate of 100 ms per second

This is called slewing. You can control it with corrtimeratio and maxslewrate.

The purpose is to ensure that the clock always moves forward.

specifically, what is it doing for those 5 seconds of waiting?

Checking multiple servers and observing system clock.

Finally, not shown in here, but somehow, NTP actually changes the drift rate or the frequency of the system clock.

NTP measures how much the system clock deviates from true time in PPM, and tells the kernel this. This is called clock disciplining.

Improve this answer
3
  • Hi, thanks for the answer. Do these actions (corrtimeratio and maxslewrate, and clock disciplining) happen on the client or on the server side ?
    – Denis Barkats
    Commented Jun 7 at 9:58
  • Client. The server only replies with time and some misc information about it. What the client does with the reply is up to the client.
    – vidarlo
    Commented Jun 7 at 10:19
  • Regarding the clock disciplining, do you know where I can find a kernel module, or some kind of script to inquire exactly what is happening in there. Does a file get changed that lets me figure out what has changed or does an internal parameter get modified ? Thanks.
    – Denis Barkats
    Commented Jun 25 at 20:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .