Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 2.4-9-g6cd5583

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev 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, 30 Jun 2016, Miroslav Lichvar wrote:

On Thu, Jun 30, 2016 at 08:02:53AM -0700, Bill Unruh wrote:
Another question is what one takes as the "no-assymmetry" delay ( ie the
minimum delay). The lowest delay? Ovr what time period? Can one imagine weird
situations in which the minimum is a bad estimate? Over how long a period does
one take the minimum? It would be a mistake to take 0 for that minimum.

At least for start, it could be the minimum delay from samples that
are used in the linear regression (up to 64 samples). This value is
already used for few other things. In my experiments it worked very
nicely. We can increase the number later or work with a time interval
instead of a number of samples if necessary.

I guess the question is what one does if it jumps around. Eg, if the network
suddenly suffers a one-way delay which extends over hours. This would make the
offset jump around too. Ie, does one use a "sticky averaging" Ie, if that
minimum increases slowly slew the minimum to the new value, but if the minimum
decreases, rapidly slew to that value.

Certainly on my network ( a very limited sample I agree) the delays seem to be
almost all one way.


One really weird effect I found was that I have one machine connected to a
Sure GPS, which seems to have quite a large fluctuation. (or for which the
interrupt processing seems to have a large fluctuation-- impossible to figure
out which of course.) but a few times this week, for hours at a time ( 3-6
hrs) the GPS time seems to be much smoother (the fluctuations in slope are
much less) and at the same time, the delay times to the other machines are
smaller, and no longer bimodal. (the delay time seems to have two clumps
aroung 16us and 24us-- see for example boson in the graphs-- the lower graph
is the offset(blue)  and the delay(pink) Note that the transition to bimodal
is at the same time as the GPS slope becomes much noisier (info is the gps
driven one-- using the serial port interrupt with the Linux serial port driver. )
The only thing I could imagine is that there is something messing with the
interupts which affects both the serial port interrupts and the network card
interrups at the same time.  Anyone seen anything like this befoe?

All run with minpoll 4 maxpoll 4. which is clearly why the fluctuations in the
rate of the gps system get transferred to the others. The only one with the
default min and maxpoll is dilaton, whose rate curve is much smoother, simply
because of the much longer averaging.




--
Miroslav Lichvar

--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/