[Bloat] Steam In Home Streaming on ath9k wifi

[Neil Davies]

> On 24 Nov 2017, at 09:20, Hal Murray <hmurray at megapathdsl.net> wrote:
> 
> 
> neil.davies at pnsol.com said:
>> There are a few more issues - the relative drift between the two clocks
>> can be as high as 200ppm, though typically 50-75ppm is what we observe, but
>> this drift is monotonic.
> 
> 200 ppm seems pretty high, but not off scale.  If ntpd is running and not
> getting confused by long queuing delays, it should correct the drift to well
> under 1 ppm.  If you turn on loopstats, you can graph it.

I’m saying that is the maximum rate of drift between two clocks even
when they are under NTP control. As you say below the clock rates
are not completely stable they are temperature dependent.
When we did this with the guys at CERN we could
correlate the results with the workload (see below for references).

We’ve got ~1M experiments using this approach across various networks,
the numbers are what we are seeing in practice.

The caveat is that, after a while (i.e several 100s) the clock drift can make
a significant difference (i.e a few ms) in the one-way delay estimation.

> 
> If you are blasting the network and adding long queuing delays, ntpd can
> easily get confused.
> 
> There is another quirk to keep in mind.  The temperature coefficient of the
> crystal is ballpark of 1 ppm per C.  Things can change significantly if an
> idle system starts flinging lots of bits around.
> 
> 
>> Also NTP can make changes at one (or both) ends - they show up as distinct
>> direction changes in the drift.
> 
> I'm not sure what you mean by "direction change".  I'd expect a graph of the
> time offset vs time to be linear and the slope would have a sharp change if
> ntpd changed it's "drift" correction and/or maybe a rounded bend as a system
> warmed up.

Don’t forget you are measuring the difference in the rates between two NTP clocks,
hence the change when one of the NTP systems decides to change the drift rate
the relative rate can change direction.

> 
> ----------
> 
> Are you happy with whatever you are doing?   Should we try to set things up
> so ntpd works well enough?  How close would you like the times to be?  …
> 

Yep, we’re very happy - we don’t care that there is a linear clock drift (we
can correct for that) and the step changes are infrequent and can be eliminated
from the long term analysis.

You might find §4.4 (esp §4.4.5) and §5.6 in
https://cds.cern.ch/record/1504817/files/CERN-THESIS-2013-004.pdf <https://cds.cern.ch/record/1504817/files/CERN-THESIS-2013-004.pdf>
interesting.  It illustrates these sort of issues.


> 
> 
> 
> --
> These are my opinions.  I hate spam.
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171124/aeb34a6a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20171124/aeb34a6a/attachment-0001.sig>