From nobody@FreeBSD.org  Sat Nov 24 01:38:16 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 2C534CF4
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 24 Nov 2012 01:38:16 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id EDEF08FC13
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 24 Nov 2012 01:38:15 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.5/8.14.5) with ESMTP id qAO1cFu6030930
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 24 Nov 2012 01:38:15 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.5/8.14.5/Submit) id qAO1cFK9030929;
	Sat, 24 Nov 2012 01:38:15 GMT
	(envelope-from nobody)
Message-Id: <201211240138.qAO1cFK9030929@red.freebsd.org>
Date: Sat, 24 Nov 2012 01:38:15 GMT
From: Adrian Chadd <adrian@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [ath] [net80211] TDMA TX on 802.11n varies wildly
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         173886
>Category:       kern
>Synopsis:       [ath] [net80211] TDMA TX on 802.11n varies wildly
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-wireless
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Nov 24 01:40:00 UTC 2012
>Closed-Date:    Wed Nov 28 05:06:49 UTC 2012
>Last-Modified:  Wed Nov 28 05:06:49 UTC 2012
>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:
Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat Nov 24 05:04:18 UTC 2012 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=173886 
State-Changed-From-To: open->closed 
State-Changed-By: adrian 
State-Changed-When: Wed Nov 28 05:06:03 UTC 2012 
State-Changed-Why:  
This was fixed in r243590, which correctly wrapped and programmed 
the nexttbtt calculation. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=173886 
>Unformatted:
