[Bloat] Steam In Home Streaming on ath9k wifi

Neil Davies neil.davies at pnsol.com
Wed Nov 22 05:31:36 EST 2017


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 <hmurray at megapathdsl.net> 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 at 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
> 

-------------- 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/20171122/d45cbe34/attachment-0002.sig>


More information about the Bloat mailing list