From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 520283BA8E for ; Thu, 23 Nov 2017 12:48:22 -0500 (EST) Received: by mail-lf0-x22e.google.com with SMTP id y2so21912071lfj.4 for ; Thu, 23 Nov 2017 09:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IudV+bSaWNCLlbZ/GMMypFOWDFL2uCf51mftisje04c=; b=cROwMHBNUxBpoqjzpUqlWM9a+d204ejcFdSsVrM2hfxSB9HZcN+wSYesHfwUpn7854 UeCc2bEn76fYcZRDnMiTTnQLXfjPkUnuBKmfKMelTT690hSrGBHRD7JvUdC/l5kJCtEo 6MTOHVvkK0fH3OThDMBKT45z7RkEn5nfAgMegZ31TIWQopF66S6/V+NR1OIhg2t0lIce 8dBoEDy8X5b8YQgY7AOePWvH4A8oPRKFJ64HM50Gi/nYHMFrSRj40yUmj8TxkFAzK6cQ FWGc0gZIcN0hZHN/zB/8fP8EbJeTkctn+RXWFQb/TR9njplpcs3tUGaIRgkb2YAJzD2K Jesw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IudV+bSaWNCLlbZ/GMMypFOWDFL2uCf51mftisje04c=; b=mFkXvYKj90th9apWi6KZ9Q1gnOVza9ZXerYOdQVg+2H1qwvV2j8GthdBhZNa/+jso6 baWvc9hjLUP2+aq0vnwJL7b9ecRKmvbYrRfzMZ/ZtPS3mLgZ4nvO6wXXdp9bED5S7Ekl v2p7n1f2xBIHNxNJEpnXx7tSr53onUaswoXjp96QHNzpxA1d931npBSjIA87AfiZ4kFF +Opco7XgxPjafEKY1IhQDYAtGww9QbuikMfslR3/eJ08RaB6abGCwWEgTxoWgm3gHOLK Nt/LnonN/BdPyiaL9j3psxufJXLO9FRbOrZ6xIBT0NYPPRVULtsWvIOK+TWzvHgrkvil jiAA== X-Gm-Message-State: AJaThX60DWZE4Ichv86mGfTvN2nOxxBiQdhV/dp1Z3W1WkR849ofOAKc LPwhlp7Yiu5UF7wsFcVqad0yw79byaVPzEBX4KBBBA== X-Google-Smtp-Source: AGs4zMayuEkh74IqC18r6TtafocyXJl6ayzVO96hBNOFdJCgeK0hBnE1cBJI25KD/aoKJ7U/5xTFV2XgmEpistRw+zs= X-Received: by 10.46.31.18 with SMTP id f18mr9321640ljf.27.1511459300861; Thu, 23 Nov 2017 09:48:20 -0800 (PST) MIME-Version: 1.0 References: <20171121190826.5B80540605C@ip-64-139-1-69.sjc.megapath.net> <1CE2F13E-A918-4EC3-AAEF-3F92DA51C6E3@pnsol.com> In-Reply-To: <1CE2F13E-A918-4EC3-AAEF-3F92DA51C6E3@pnsol.com> From: Caleb Cushing Date: Thu, 23 Nov 2017 17:48:09 +0000 Message-ID: To: Neil Davies Cc: Hal Murray , bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="f40304396880b86ce2055eaa0ae5" 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: Thu, 23 Nov 2017 17:48:22 -0000 --f40304396880b86ce2055eaa0ae5 Content-Type: text/plain; charset="UTF-8" I'll try to get some measurements from both clients... before the end of the holiday weekend, but it's hard for me to say I'll get the clock sync right. I have done some client side tuning and driver updates, and that seems to have improved things, but there is still some bumps that don't don't make sense. as a side note, noticing the request for cake testing or whatever, cake was inferior performance wise for this problem, on the wlan to fq-codel, I tried it but got worse results (also tried no optimizations on wlan, also worse peformance). Not sure why that would be but.... well there it is. On Wed, Nov 22, 2017 at 4:32 AM Neil Davies wrote: > Hal > > We use this approach to automatically manage measurements. > > 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. > > Also NTP can make changes at one (or both) ends - they show up as distinct > direction changes in the drift. > > This gives a limit (or a measurement error function you have to work > within). > > Neil > > > On 21 Nov 2017, at 19:08, Hal Murray wrote: > > > >> Right, no idea how Windows drivers behave. But odds are that the > bottleneck > >> is at the client, since that often has worse antennas than the AP. If > you're > >> in a position to take packet captures at both clients and AP you may be > able > >> to figure it out; may require tightly synchronised clocks to do > properly, > >> though. > > > > It should be reasonable to synchronize the clocks at both ends well > enough. > > > > If that doesn't work and/or is inconvient, you could post process one > trace > > to adjust the time stamps. The idea is to scan both traces in parallel > to > > find the minimum transit times in each direction, then adjust the time > stamps > > on one end to allocate half the total time to each direction. It would > > obviously be handy to have a few pings during a period of low traffic for > > calibration. > > > > ------- > > > > There are two dimensions to clocks. One is the current time. The other > is > > the frequency. If the frequency is off, the clock will drift. (ntpd's > drift > > correction is usually stored in someplace like /var/lib/ntp/ntp.drift) > > > > Unless you are interested in long runs, the clock will not drift far > enough > > to be a serious problem, so all you have to do is get the time right > before > > starting a run. > > > > You might want to kill ntpd on the wifi end so it doesn't get confused > and yank the clock around. > > > > > > -- > > These are my opinions. I hate spam. > > > > > > > > _______________________________________________ > > Bloat mailing list > > Bloat@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/bloat > > > > > > -- > > BEGIN-ANTISPAM-VOTING-LINKS > > ------------------------------------------------------ > > > > Teach CanIt if this mail (ID 03UAH8AV8) is spam: > > Spam: > https://portal.roaringpenguin.co.uk/canit/b.php?c=s&i=03UAH8AV8&m=09f8fdc3b5f4&rlm=pnsol-com&t=20171121 > > Not spam: > https://portal.roaringpenguin.co.uk/canit/b.php?c=n&i=03UAH8AV8&m=09f8fdc3b5f4&rlm=pnsol-com&t=20171121 > > Forget vote: > https://portal.roaringpenguin.co.uk/canit/b.php?c=f&i=03UAH8AV8&m=09f8fdc3b5f4&rlm=pnsol-com&t=20171121 > > ------------------------------------------------------ > > END-ANTISPAM-VOTING-LINKS > > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > -- Caleb Cushing http://xenoterracide.com --f40304396880b86ce2055eaa0ae5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll try to get some measurements from both clients...= before the end of the holiday weekend, but it's hard for me to say I&#= 39;ll get the clock sync right. I have done some client side tuning and dri= ver updates, and that seems to have improved things, but there is still som= e bumps that don't don't make sense.

as a side note, noticin= g the request for cake testing or whatever, cake was inferior performance w= ise for this problem, on the wlan to fq-codel, I tried it but got worse res= ults (also tried no optimizations on wlan, also worse peformance). Not sure= why that would be but.... well there it is.

On Wed, Nov 22, 2017 at 4:32 AM Neil Davies <neil.davies@pnsol.com> wrote:
Hal

We use this approach to automatically manage measurements.

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 d= rift
is monotonic.

Also NTP can make changes at one (or both) ends - they show up as distinct<= br> direction changes in the drift.

This gives a limit (or a measurement error function you have to work within= ).

Neil

> On 21 Nov 2017, at 19:08, Hal Murray <hmurray@megapathdsl.net> wrote:
>
>> Right, no idea how Windows drivers behave. But odds are that the b= ottleneck
>> is at the client, since that often has worse antennas than the AP.= If you're
>> in a position to take packet captures at both clients and AP you m= ay be able
>> to figure it out; may require tightly synchronised clocks to do pr= operly,
>> though.
>
> It should be reasonable to synchronize the clocks at both ends well en= ough.
>
> If that doesn't work and/or is inconvient, you could post process = one trace
> to adjust the time stamps.=C2=A0 The idea is to scan both traces in pa= rallel to
> find the minimum transit times in each direction, then adjust the time= stamps
> on one end to allocate half the total time to each direction.=C2=A0 It= would
> obviously be handy to have a few pings during a period of low traffic = for
> calibration.
>
> -------
>
> There are two dimensions to clocks.=C2=A0 One is the current time.=C2= =A0 The other is
> the frequency.=C2=A0 If the frequency is off, the clock will drift.=C2= =A0 (ntpd's drift
> correction is usually stored in someplace like /var/lib/ntp/ntp.drift)=
>
> Unless you are interested in long runs, the clock will not drift far e= nough
> to be a serious problem, so all you have to do is get the time right b= efore
> starting a run.
>
> You might want to kill ntpd on the wifi end so it doesn't get conf= used and yank the clock around.
>
>
> --
> These are my opinions.=C2=A0 I hate spam.
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat= @lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat >
>
> --
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
>
> Teach CanIt if this mail (ID 03UAH8AV8) is spam:
> Spam:=C2=A0 =C2=A0 =C2=A0 =C2=A0 https:/= /portal.roaringpenguin.co.uk/canit/b.php?c=3Ds&i=3D03UAH8AV8&m=3D09= f8fdc3b5f4&rlm=3Dpnsol-com&t=3D20171121
> Not spam:=C2=A0 =C2=A0 https://portal.roa= ringpenguin.co.uk/canit/b.php?c=3Dn&i=3D03UAH8AV8&m=3D09f8fdc3b5f4&= amp;rlm=3Dpnsol-com&t=3D20171121
> Forget vote: https://portal.roaringpengui= n.co.uk/canit/b.php?c=3Df&i=3D03UAH8AV8&m=3D09f8fdc3b5f4&rlm=3D= pnsol-com&t=3D20171121
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
>

_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--
--f40304396880b86ce2055eaa0ae5--