Date: Sat, 24 Nov 2012 01:38:15 GMT From: Adrian Chadd <adrian@FreeBSD.org> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/173886: [ath] [net80211] TDMA TX on 802.11n varies wildly Message-ID: <201211240138.qAO1cFK9030929@red.freebsd.org> Resent-Message-ID: <201211240140.qAO1e05D013247@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 173886 >Category: kern >Synopsis: [ath] [net80211] TDMA TX on 802.11n varies wildly >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 24 01:40:00 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: -HEAD >Organization: >Environment: >Description: When using an 802.11n NIC (eg AR5416) as a TDMA slave (with an AR5413 as the TDMA master) the timing deltas look fine when there's no traffic, but after some iperf TCP testing (client = slave, server = master) the traffic throughput starts varying wildly. The TDMA debugging output also shows large swings in the TDMA timing correction. >How-To-Repeat: Setup TDMA master on an AR5413 (channel 36:a) Setup TDMA slave on AR5416 Associate, ping - ok watch the TDMA timing on the slave - athstats -i athX -o tdma 1 start an iperf from slave -> master wait a while >Fix: Well, what's going on is clear. If some debugging is added to if_ath_tdma.c to print out the le64toh(ni->ni_tstamp.tsf) - which is the TSF being stamped by the master as it TXes its beacons - the variance shows up there. Eg: 986243130 (delta 49154) 986292282 (delta 49152) 986341434 (delta 49152) 986390586 (delta 49152) 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) 987324472 (delta 49152) 987373624 (delta 49152) So it's quite likely that the slave is overflowing its slot configuration and transmitting when the master is supposed to be beaconing. Why that is isn't quite clear yet. Some things to initially check: * the WME config on the slave is wrong and it's actively bursting for much longer than it should be; * the queue isn't being correctly beacon gated - and it isn't being 'stopped' after the txop burst is over; * check to see if ACKs are actually occuring when they shouldn't be, and ensure that the frames aren't being retried in hardware; * .. and check RTS/CTS-to-self isn't being done too. I should also check that the slave slot time is actually _correct_ and it isn't just running into the beacon time on the master. All kinds of things could be going on. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201211240138.qAO1cFK9030929>