Skip to main content
Unix & Linux

Return to Question

added 346 characters in body
Source Link
Denis Barkats
Denis Barkats
  • 11
  • 2

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.

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.

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.

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.

Fixed typos and formatting; improved capitalization and punctuation.
Source Link
G-Man Says 'Reinstate Monica'
G-Man Says 'Reinstate Monica'
  • 24k
  • 29
  • 76
  • 130

Where can I find the configuration/setting for ntpNTP to explain the specific behavior observed in an ntp clientNTP client?

I have recently been doing a specific timing analysis of the of the performance of ntpNTP under controlled conditions. The  The experiment I performed performed was conceptually quite simple. I have  I have an ntpNTP server running somewhere on my network    (this is a 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 = 50ms and 500ms) - 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.

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

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

ntp timingNTP timing graph

SO, as nona non-ntpNTP expert, I wonder: - where are the settings/configuration for ntp to behave in that manner ? - specifically, what is it doing for those 5seconds of waiting ? - where is the configuration for that slew rate of 100ms 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 then 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 adjustement done by ntp that remains locked in the system time even after turning ntp off. Where and how is that done ?

  • 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, but I'm trying to dig dig deeper to understand the behavior of ntp and ifNTP, and if all of those are hardwired in the server (or client) or if or if those are configuration changeable  .

Thanks

Where can I find the configuration/setting for ntp to explain the specific behavior observed in an ntp client?

I have recently been doing a specific timing analysis of the 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 a 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 = 50ms and 500ms) - 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.

Here's what I observed. First , ntp client takes 5seconds 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 100ms per second (in other words, if the offset between the machine's system time and the ntp time was 500ms, it takes 5seconds to bring that offset back down close to 0ms). This behavior is visible in the attached plot

ntp timing

SO, as non-ntp expert, I wonder: - where are the settings/configuration for ntp to behave in that manner ? - specifically, what is it doing for those 5seconds of waiting ? - where is the configuration for that slew rate of 100ms 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 then 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 adjustement 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  .

Thanks

Where can I find the configuration/setting for NTP to explain the specific behavior observed in an NTP client?

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.

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.

Source Link
Denis Barkats
Denis Barkats
  • 11
  • 2

Where can I find the configuration/setting for ntp to explain the specific behavior observed in an ntp client?

I have recently been doing a specific timing analysis of the 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 a 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 = 50ms and 500ms) - 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.

Here's what I observed. First , ntp client takes 5seconds 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 100ms per second (in other words, if the offset between the machine's system time and the ntp time was 500ms, it takes 5seconds to bring that offset back down close to 0ms). This behavior is visible in the attached plot

ntp timing

SO, as non-ntp expert, I wonder: - where are the settings/configuration for ntp to behave in that manner ? - specifically, what is it doing for those 5seconds of waiting ? - where is the configuration for that slew rate of 100ms 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 then 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 adjustement 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 .

Thanks