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.
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@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@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
--