On 23 November 2012 05:28, Michael Vale <mas...@internode.on.net> wrote:
> When I get back from my holiday I will test this on numerous multi-km ptp
> and ptmp links mate.
Hold off for a bit, I'm seeing some (recovered) timing drift when I'm
doing iperf tests. It takes a while for it to trigger, but at least
now it does recover.
It's stable with no traffic, which is good. Beforehand, the TSF
adjustment would cause the unit to fall markedly out of timing, and
then it'd take a while to coverge back. Once it converged back, it
would write a new timing configuration out which would adjust the TSF
by a large amount and .. it'd fall out of timing again.
I've added a whole bunch of extra debugging to if_ath_tdma.c to try
and understand what's going on during this.
It would be nice if someone took a stab at understanding why the slot
timing estimate is falling so far "off" during busy traffic here.
Remember, the slot offset is based on the timestamp of the beacon
being transmitted at the master side and received locally, and it's
entirely plausible the reason I'm seeing overruns here is because the
NIC is overflowing its burst config and guard interval, causing the
master beacon to be delayed in TX. That would manifest itself as the
slot timing drifting in and out, as the master beacon ends up being
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"