General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Neil Davies <neil.davies@pnsol.com>
To: Hal Murray <hmurray@megapathdsl.net>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Steam In Home Streaming on ath9k wifi
Date: Fri, 24 Nov 2017 09:34:59 +0000	[thread overview]
Message-ID: <AB261D18-7F22-4B61-884D-8018C8A12598@pnsol.com> (raw)
In-Reply-To: <20171124092021.DC01D40605C@ip-64-139-1-69.sjc.megapath.net>


[-- Attachment #1.1: Type: text/plain, Size: 2720 bytes --]


> On 24 Nov 2017, at 09:20, Hal Murray <hmurray@megapathdsl.net> wrote:
> 
> 
> neil.davies@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.
> 
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 4379 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2017-11-24  9:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-21 19:08 Hal Murray
2017-11-22 10:31 ` Neil Davies
2017-11-23 17:48   ` Caleb Cushing
2017-11-24  9:20   ` Hal Murray
2017-11-24  9:34     ` Neil Davies [this message]
2017-11-26  7:25       ` Caleb Cushing
2017-11-26  7:29         ` Caleb Cushing
2017-11-26  7:55           ` Jan Ceuleers
2017-11-26 10:05             ` Jonathan Morton
2017-11-26 10:53               ` Jan Ceuleers
2017-11-26 10:55                 ` Jonathan Morton
2017-11-26 11:54                 ` Steinar H. Gunderson
2017-11-26 13:03                   ` Jan Ceuleers
2017-11-26 13:05                     ` Jan Ceuleers
2017-11-26 13:13                       ` Steinar H. Gunderson
2017-11-26 17:53               ` Dave Taht
2017-11-26 18:43                 ` Jan Ceuleers
2017-11-26 23:11                   ` Dave Taht
2017-12-04  7:24                     ` Caleb Cushing
  -- strict thread matches above, loose matches on Subject: below --
2017-11-18 22:14 Caleb Cushing
2017-11-19 16:28 ` Toke Høiland-Jørgensen
2017-11-19 21:18   ` Caleb Cushing
2017-11-19 21:27     ` Toke Høiland-Jørgensen
2017-11-19 22:03       ` Caleb Cushing
2017-11-19 22:13         ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AB261D18-7F22-4B61-884D-8018C8A12598@pnsol.com \
    --to=neil.davies@pnsol.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=hmurray@megapathdsl.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox