From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound01.roaringpenguin.co.uk (outbound01.roaringpenguin.co.uk [109.69.238.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 15F0F3BA8E for ; Fri, 24 Nov 2017 04:35:20 -0500 (EST) Received: from relay.smtp.pnsol.com (ec2-54-246-165-192.eu-west-1.compute.amazonaws.com [54.246.165.192]) by outbound01.roaringpenguin.co.uk (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vAO9ZHLO026766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NOT); Fri, 24 Nov 2017 09:35:18 GMT Received: from mail.la.pnsol.com ([172.20.5.206]) by relay.smtp.pnsol.com with esmtp (Exim 4.82) (envelope-from ) id 1eIAO5-000063-TP; Fri, 24 Nov 2017 09:35:09 +0000 Received: from git.pnsol.com ([172.20.5.238] helo=roam.smtp.pnsol.com) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1eIAO4-0000fH-Vn; Fri, 24 Nov 2017 09:35:08 +0000 Received: from [172.20.5.110] by roam.smtp.pnsol.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1eIAO4-0000Bv-Pm; Fri, 24 Nov 2017 09:35:08 +0000 Content-Type: multipart/signed; boundary="Apple-Mail=_6C6B4DA9-1388-45CB-94EB-4C8057F09064"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Neil Davies X-Mailbutler-Link-Tracking-Uuid: In-Reply-To: <20171124092021.DC01D40605C@ip-64-139-1-69.sjc.megapath.net> Date: Fri, 24 Nov 2017 09:34:59 +0000 Cc: bloat@lists.bufferbloat.net Message-Id: References: <20171124092021.DC01D40605C@ip-64-139-1-69.sjc.megapath.net> To: Hal Murray X-Mailer: Apple Mail (2.3273) X-Spam-Score: undef - relay 54.246.165.192 marked with skip_spam_scan X-CanIt-Geo: ip=54.246.165.192; country=IE; region=Leinster; city=Dublin; latitude=53.3389; longitude=-6.2595; http://maps.google.com/maps?q=53.3389,-6.2595&z=6 X-CanItPRO-Stream: pnsol-com:outbound (inherits from pnsol-com:default, PredictableNetworkSolutions:default, Wholesale:default, CTL:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-CanIt-Archive-Cluster: Rl4fxI1RVOq/TTUYGiKHQwqlXy8 X-CanIt-Archived-As: pnsol-com/20171124 / 07UBJzh6u X-Scanned-By: CanIt (www . roaringpenguin . com) on 109.69.238.88 Subject: Re: [Bloat] Steam In Home Streaming on ath9k wifi X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 09:35:21 -0000 --Apple-Mail=_6C6B4DA9-1388-45CB-94EB-4C8057F09064 Content-Type: multipart/alternative; boundary="Apple-Mail=_926B627A-7388-4249-8A8F-11920328C9C1" --Apple-Mail=_926B627A-7388-4249-8A8F-11920328C9C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Nov 2017, at 09:20, Hal Murray wrote: >=20 >=20 > 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. >=20 > 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=E2=80=99m 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=E2=80=99ve 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. >=20 > If you are blasting the network and adding long queuing delays, ntpd = can > easily get confused. >=20 > 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. >=20 >=20 >> Also NTP can make changes at one (or both) ends - they show up as = distinct >> direction changes in the drift. >=20 > 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=E2=80=99t 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. >=20 > ---------- >=20 > 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? = =E2=80=A6 >=20 Yep, we=E2=80=99re very happy - we don=E2=80=99t 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 =C2=A74.4 (esp =C2=A74.4.5) and =C2=A75.6 in https://cds.cern.ch/record/1504817/files/CERN-THESIS-2013-004.pdf = interesting. It illustrates these sort of issues. >=20 >=20 >=20 > -- > These are my opinions. I hate spam. >=20 >=20 >=20 --Apple-Mail=_926B627A-7388-4249-8A8F-11920328C9C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80= =99m 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=E2=80=99ve 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=E2=80=99t 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?  =E2=80=A6


Yep, = we=E2=80=99re very happy - we don=E2=80=99t 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 =C2=A74.4 = (esp =C2=A74.4.5) and =C2=A75.6 in 
interesting.  It illustrates these sort of = issues. 





--
These are my opinions.  I hate spam.




= --Apple-Mail=_926B627A-7388-4249-8A8F-11920328C9C1-- --Apple-Mail=_6C6B4DA9-1388-45CB-94EB-4C8057F09064 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaF+fEAAoJEPmpMHCy/udqHCMQALqR1lOTM3oVpsUEwVB1B5Im /Le9bE/oKc4N/A6vGvyOn+XFUlos44sD9yOYrpv25WRAKF8S/LXss9iKjOl2i8Ux gW2/d+JVJk95fzkVnNto8xPFiLmy1An98Gc1ADcwy9OtbcpvIgaoDNW1026sl7LF fBU/C/INLtWRshaPPBqJTJlsCgYH1pyK63oHN94nr9/QHEz8MVkGDzlOAUrESLJV H+DA8eFtOg2bnutEzAhFgjQo50w84ZMk+mdOfzJDQcJYKQJUVG4vNqNAitCkSpTx ie4OfxonDQAqpfc7artuYcb84Q36222JZ/cgAdExzJ2YijbVnArBozcoBk9mt5xp F9o9NoJaxCeNHGeVB65iqptV6DZxLRfcYMONZWUMI7UFn+wcNUWEvIE7YbSVvsWL vkz1qguWqMgvz1FuBRQ/DyNuD6Jz3vzX5MvRnKJqbeVYIscA8A3mrVhL9bc52HPz 1vn3i/a2ls0cb8VSAQOhyEAhpEkZmdEXZ8ooYtGVKKwCS6Akjq+RD2EuihRB6F7d leMo4EG2+/JBf3+DWb8lV5FOfRIBYIOe8D302yPVAkaJAin+fB2jTavtkyHC2twq AUJzHpAFQ3ivFoQlS5+wuyExI+cMusnbpeHSRcgQLAou2qPj9rEZCJeisjqD5yTo vAnCRZPLWZOgrbgtqYra =8s3H -----END PGP SIGNATURE----- --Apple-Mail=_6C6B4DA9-1388-45CB-94EB-4C8057F09064--