Re: polling algorithm

Klas Bengtsson wrote:

Hi David,

and thanks for your answer. But I am still a bit confused over the behaviour I see here. I have peer printouts every minute and they look like this:

Tue Aug 16 08:43:53 JST 2005
remote refid st t when poll reach delay offset jitter
==============================================================================

*148.17.101.4 148.17.100.2 2 u 984 1024 377 1.209 -0.669 0.740
+148.17.101.5 148.17.100.2 2 u 990 1024 377 1.241 -0.764 0.362

Tue Aug 16 08:44:53 JST 2005
remote refid st t when poll reach delay offset jitter
==============================================================================

148.17.101.4 148.17.100.2 2 u 19 1024 377 0.962 1998.55 1999.22
148.17.101.5 148.17.100.2 2 u 24 1024 377 1.025 1998.71 1999.47

Here the synchronisation is lost, but the poll value remains at 1024. The poll value is 1024 until the next poll (17 minutes later), and then the poll value is decreased to 64 again, and the synchronisation is back.

.
.
.

Tue Aug 16 09:00:55 JST 2005
remote refid st t when poll reach delay offset jitter
==============================================================================

148.17.101.4 148.17.100.2 2 u 981 1024 377 0.962 1998.55 1999.22
148.17.101.5 148.17.100.2 2 u 986 1024 377 1.025 1998.71 1999.47

Tue Aug 16 09:01:56 JST 2005
remote refid st t when poll reach delay offset jitter
==============================================================================

*148.17.101.4 148.17.100.2 2 u 18 64 377 0.929 1990.20 8.349
+148.17.101.5 148.17.100.2 2 u 22 64 377 0.966 1997.48 1.230

Now to my question:
If we are just dealing with a lost packet here, why is the poll value decreased to 64 seconds when the synchronisation is back again after 17 minutes?

Has it something to do with the large jitter and offset values we see? In that case I still would expect the poll value to decrease to 64 seconds when the synchronisation is lost, not when it comes back into synchronisation again.

BR,
Klas



From: "David L. Mills" <mills@xxxxxxxx>
To: questions@xxxxxxxxxxxxxxxxx
Subject: [ntp:questions] Re: polling algorithm
Date: Thu, 25 Aug 2005 19:06:54 +0000

Klas,

Think about what you said. The only way the client knows the server is reachable is to poll it. Even if the server does not answer a poll you can't conclude it has become unreachable; a packet could have been lost.

The poll interval increases in the first place because the feedback loop has stabilized and doesn't need refresh very often. The design allows for some packets to be lost and for the server quality metric (synchronization distance) to accurately reflect the maximum error relative to that server. If the server comes back online after a few polls or a couple of hours, the clock discipline process just takes over as before and reducing the poll interval is unnecessary and counterproductive.

Dave




Something very odd is going on. Somebody's clock jumped or drifted nearly two seconds in the 1024 second interval between polls. If it was your clock that jumped or drifted, you need to get it fixed in order to have any hope of keeping stable and accurate time.

If it was the server's clock(s) that jumped, you need to use better servers or get them fixed. In any event you need more servers! A configuration with two servers is the worst possible since ntpd has no means of determining which server is correct when the two differ as they almost inevitably will. Four servers are the minimum necessary to unambiguously vote out a single false ticker. A configuration with seven servers can survive two false tickers.

.

Relevant Pages

  • RE: polling algorithm
    ... Here the synchronisation is lost, but the poll value remains at 1024. ... The poll value is 1024 until the next poll, and then the poll value is decreased to 64 again, and the synchronisation is back. ...
    (comp.protocols.time.ntp)
  • Re: polling algorithm
    ... The only way the client knows the server is reachable is to poll it. ... My problem is that when the poll interval is 1024 seconds and I suddenly lose synchronisation for some reason, I would expect the NTP server to decrease the polling interval back to 64 seconds again, but it does not. ... What makes the polling interval decrease again once it has reached 1024 seconds? ...
    (comp.protocols.time.ntp)
  • Re: Best solution for mail server?
    ... stop their own automatic poll, and restart it, if they want to. ... Clearly that takes cooperation from the server you're polling. ... daemons as they see fit, on their homespace on the server. ...
    (Fedora)
  • RE: BizTalk 2006 FILE adapter polling interval
    ... For your scenario, if you put batch size to 1, then, system will get read ... immediately poll the location again. ... For Biztalk server 2006, there is a new property on the FILE adapter ...
    (microsoft.public.biztalk.general)
  • Simple ntp setup, but network issue
    ... I am still working on diagnosing my problem communicating with an ntp server. ... The address 192.168.112.10 is my dsl modem which serves as my network gateway, bison is my linux server. ... poll 4 prec -6 ...
    (comp.protocols.time.ntp)