Preliminary results of using GPS to look for clock skew

[Dave Taht]

On Fri, Sep 23, 2011 at 2:09 AM, Jan Ceuleers <jan.ceuleers at gmail.com> wrote:
> On 09/22/2011 04:24 AM, Jonathan Morton wrote:
>>
>> When the *network* is loaded, the latency to the NTP server changes. That
>> is likely to confuse ntpd - it certainly did when I lived on an analogue
>> modem.
>
> Look at the huff'n'puff filter for how ntpd addresses this concern.
>
> http://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html

In the case of the cosmic background bufferbloat detector idea, I'm
interested in collecting the data
that ntp is currently *filtering away* as a means to measure various
delays across a wide base of machines,
thus collecting rawstats on the client seems like the best approach.
The point is not to derive accurate time
from multiple, possibly badly varying, data sources, but to see how
badly varying the data sources are!

It would be best to be doing so passively, however, at the server, and
I've been toying with the idea of
creating a new ntp message type to do so. With clients often behind
nat there is no good way to
supply what a ntp host thinks is the current time to a data collecting
server elsewhere.

The huff n puff filter is a great idea, however I note it relies on
ntp running for a long time, and many (most?)
clients restart ntp on every interface change (example, a dhcp
refresh, or wakeup from suspend)

Secondly, adding the refclock with noselect keyword seems like a
useful means of comparison.

Thirdly - as much as I would like to get a PPS signal, that seems
impossible with the hardware we are
currently playing with. That said, delays/variations of 10ms are not a
real problem as the bufferbloat signal
can often be measured in close order of seconds.

>
> Jan
> _______________________________________________
> Bloat-devel mailing list
> Bloat-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat-devel
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com