On 23 November 2012 05:39, Adrian Chadd <adr...@freebsd.org> wrote:
> 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 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.

.. or I could sit at an IHOP and hack on it a bit more.

Here's a snapshot of the received beacons on the slave, and the TSF in
said beacons:

986439736 (delta 49150)
986488888 (delta 49152)
986538040 (delta 49152)
986615556 (delta 77516)
986635102 (delta 19546)
986684248 (delta 49146)
986733414 (delta 49166)
986783802 (delta 50388)
986832958 (delta 49156)
986882104 (delta 49146)
986931256 (delta 49152)
986980408 (delta 49152)
987029560 (delta 49152)
987078714 (delta 49154)
987135640 (delta 56926)
987177018 (delta 41378)
987226170 (delta 49152)
987275320 (delta 49150)

.. notice those big deltas different from ~ 49152uS? That coincides
with the large traffic variance and swings in the slave timing
calculations. Those timestamps are in the master beacons, not the RX
timestamp. Ie, the master is delaying beaconing for a while.

My 30 second guess is "traffic is overflowing the burst window somehow
and not being killed." The newer chips support acutally killing frames
outside of a TXOP burst window, but I don't think the relevant
AR_PCU_MISC_MODE bit is set. In any case, the guard time is supposed
to "guard" for that.

I'll do a little more digging.

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to