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 constantly delayed. Adrian _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"