Re: [chrony-dev] [GIT] chrony/chrony.git branch, master, updated. 1.25-pre1-18-g20a4340

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

Ok I think I have figured out what is happening. The way in which the weights
are used in the program is as if a set of w_i measurements were made at the
point x_i, with each of them yielding the value y_i. But the estimate of the
standard deviation goes as 1/sqrt(N) where N is the total number of
measurements. Ie, as the w_i grow, the variance decreases as 1/W=1/sum W_i

As you say this is unstable. I think at present the best thing would be to
revert to the old 1+(distance_i-Min_dist)/Min_dist. Alternativey you could
use something like

M= (Min_dist+sd)
This essentially makes M the larger of the Min_dist and the standard
deviation and then divide by that instead of by Min_dist. This means that if
the stadard deviation is smaller than the min distance, then one uses the
min distance, but is the standard deviation is larger, then you use that.

Alternatively you could divide the weights by the mean weight to normalise
the weights. This should prevent the runaway, but it still leaves open why you
would divide by sd rather than by the min_dist

Ie, I am not at all clear on what the theory is that you are applying in
deciding that you want to use the standard deviation rather than the min-dist.


On Wed, 13 Apr 2011, Miroslav Lichvar wrote:

> On Wed, Apr 13, 2011 at 11:16:48AM -0700, Bill Unruh wrote:
> > Adding a constant to the
> > distance (assuming this did not change the min_distance) still changes the
> > weights in yours (and a lot if sd gets small) .
>
> I meant adding a constant to all distances.
>
> > If you wanted you
> > could put in sd+min_distance as the divisor. But this seems the
> > wrong thing to do anyway,
> > because really the importance of small differences in the distance should
> > always remain small.
>
> Why? A significant part of the distance is static delay corresponding
> to the length of the path which the signal has travel through. I just
> wanted to remove that from the weight calculation.
>
> > Also, if a server is further away, it IS less reliable. There could be a
> > constant offset-- outgoing times being a set amount more than incoming. Ie, if
> > a server has a round trip of 1 sec, and another has a roundtrip of 1ms, even
> > with the same jitter I would trust the second more.
>
> The selection algorithm takes care of that.
>
> If there is a constant offset, no change in weight calculation will
> help. But if the paths are symmetric, we'll track both sources equally
> well, no matter how far it is.

--
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/

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