| Re: [chrony-users] Polling intervals between peers |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
On Thu, 28 Feb 2019, cfanygapa wrote:
Hi
I am using 4 own (internal) Chrony servers which are synced from web
(external) NTP sources.
Additionally, my own servers are all in peer relation to each other.
NTP’s documentation
(https://www.eecis.udel.edu/~mills/ntp/html/assoc.html#poll) has the
following sentence regarding peers:
“With symmetric modes the most stable behavior results when both peers are
configured in symmetric active mode with matching poll intervals of 6 (64 s)”
Does the same recommendation apply for peers set up in Chrony?
If yes, does it have any explanation why polling=6 is better for peers
instead of something like “minpoll 2 maxpoll 4 polltarget 30” if peers are in
local network with short distance between each other?
There is a tradeoff between short poll intervals and worse rate setting. On a
short time, the rate will fluctuate more (as one could expect, since the rate
error is something like the reading noise divided by the time elapsed) Now
chrony does not use the same kind of algorithm that NTP does. It keeps lots of
measurements and does fitting to them, which reduces the noise and essentially
gives a longer elapsed time. You thus do not pay as big a price for reading
your peers or the UTC source more fequently as does NTP.
Reading more frequently clearly keeps the clocks in closer sync, but as I said
may make the rates worse which will mean that if you clock every looses all
its sources, it will wander off much more rapidly than if the rate is better
controlled.
Ie, the NTP suggestions are not transferable to chrony. As far as I know noone
has done the kind of analysis of chrony that Mills and others did for NTP. It
should be done.
I’ve done a simple test ... configured my sever A to peers B, C and D with
“minpoll 2 maxpoll 6 polltarget 30” to observe how polling will change.
A B C are in the same subnet/VLAN (Peer delay ~0.0001s), D is in distant
backup localization but still with good link and short distance (Peer delay
~0.001s). With mentioned “minpoll 2 maxpoll 6 polltarget 30” settings, A->B
The program will estimate the errror in part by using the round trip time
(after all the error caused by assymetry in the travel time cannot be larger
than the total travel time.) Thus the imputed error will be larger for the
remote one than for the local ones. It tries to calculate how much it helps to
read more frequently and if the error is big due to round trip error, then
there is no point in trying to reduce it by making more frequent measurements.
and A->C (so polls to very close hosts) ends up with max Poll=2 for most of
the time while A->D (so to distant peer) always raise towards Poll=6.
Is that explainable somehow or I am looking into non-existing issue and I
should go to sleep leaving defaults and letting Chrony to do its calculate
job?
Example sources output:
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
...
=+ b.foo.bar.net 2 2 377 5 +31us[ +31us] ± 5290us
=+ c.foo.bar.net 2 2 377 4 +48us[ +48us] ± 5128us
=+ d.foo.bar.net 2 6 377 30 -32us[ -30us] ± 6927us
Example sourcestats output:
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
...
b.foo.bar.net 8 7 29 -1.290 3.407 +37us 16us
c.foo.bar.net 46 22 181 +0.007 0.124 +40us 13us
d.foo.bar.net 30 12 26m +0.031 0.065 -236us 43us
On the other hand, I would like to understand what I’m doing as whole topic
of minpoll/maxpoll/polltarget is still a bit non-clear to me despite of
pretty good info in chrony’s FAQ page.
Should I simply observe “NP” + “Span” fields as an indication of any poll
values tuning?
Thanks in advance
Tom
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with
"unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the
subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.