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 <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
> 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
>
-- 
Caleb Cushing

http://xenoterracide.com