Undue importance given to path delay during sync

[curby]

Perhaps a better idea would be to take the ten samples, remove samples with outlying offsets, and average the rest? The goal is achieving a consistent offset and path delay, not necessarily the lowest path delay.

Example Javascript console log of lag-based selection causing trouble.

[ServerDate] Set target to -40454 +/- 35 ms.
[ServerDate] sample: 1, offset: -6053.5 +/- 20.5 ms
[ServerDate] sample: 2, offset: 8.5 +/- 91.5 ms
[ServerDate] sample: 3, offset: 8.5 +/- 31.5 ms
[ServerDate] sample: 4, offset: 8.5 +/- 31.5 ms
[ServerDate] sample: 5, offset: -19.5 +/- 59.5 ms
[ServerDate] sample: 6, offset: 26.5 +/- 49.5 ms
[ServerDate] sample: 7, offset: 7 +/- 32 ms
[ServerDate] sample: 8, offset: 8.5 +/- 31.5 ms
[ServerDate] sample: 9, offset: 7.5 +/- 31.5 ms
[ServerDate] sample: 10, offset: 7.5 +/- 32.5 ms
[ServerDate] Set target to -6053.5 +/- 20.5 ms (+ 34400.5 ms).
[ServerDate] Difference between target and offset too high (34400.5 ms); skipping amortization.

[curby]

I found what causes the problem: when you click on any link on which the page is displayed and then hit the back button (tested in Chrome, others may also be affected), the first two lines in the console log snippet above ("Set target to" and "sample: 1") will always have large target/offset values. If that first sample also happens to have the lowest path delay, its (incorrect) offset will be used as the new target.

In the end, there are two issues:

1. Sample should not be blindly chosen on the basis of lowest path delay alone.
2. Ensure that variables are appropriately handled if browser back/forward buttons are used. (Moved to #21)

[David Braun]

Thanks for the bug report (#21).

Regarding point #1, I'm not convinced yet. The meaning of the path delay is it's the precision of our data (see the paper* referenced in README). Although my programming instincts guide me to do as you're suggesting, e.g., taking an average, I believe when I thought this through (or read the paper) that I was convinced this was the wrong approach and the best answer comes from the smallest delay.

If you're interested, read the paper and then tell me what you think.

*"Probabilistic clock synchronization" by Flaviu Cristian Cristian, F. (1989), "Probabilistic clock synchronization", Distributed Computing (Springer) 3 (3): 146–158, DOI:10.1007/BF01784024