Date: Fri, 25 Nov 2011 17:53:40 +0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: Gustau Perez Querol <gperez@entel.upc.edu> Cc: freebsd-wireless@freebsd.org Subject: Re: Big delays between an AR5416 AP and its clients Message-ID: <CAJ-Vmo=1k=oKP-vDUH=BLdyeVzGnQvNmJ6TwGcdQjwpgJWt52w@mail.gmail.com> In-Reply-To: <3d4d2d249836fafc6acd885693c02198@webmail.entel.upc.edu> References: <3d4d2d249836fafc6acd885693c02198@webmail.entel.upc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, As I've said privately: * compile w/ ATH_DEBUG, ATH_DIAGAPI, AH_DEBUG * and compile src/tools/tools/ath/athstats/ I also suggest: * compile w/ IEEE80211_DEBUG * and compile src/tools/tools/wlan/wlanstats/ (why those aren't built as part of the base is beyond me, but I digress..) Let's see if we can find some correlations between counters incrementing and upset traffic w/ your iphone. The commit (r227364) is the introduction of the TX aggregation and software TX queue handling. It's very possible that we're seeing some very bad behaviour with aggressive power saving as I _do_ know my ath driver changes have broken the power saving stuff somewhat. The short of it: because there are now frames sitting in the driver, rather than the net80211 TX interface queue, the beacon TIM (traffic map) generation won't take into account anything that the driver sees. However unless you've enabled 11n, the software retransmission shouldn't occur - it only occurs when 11n aggregation has been negotiated. So I think it's very likely something to do with the software TX queue itself and how frames are queued/drained. So yes, let's get some more details from your environment and once I've finished relocation (and have the right iphone hardware :-) I'll see about fixing it up. Thanks very much for testing this stuff! Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=1k=oKP-vDUH=BLdyeVzGnQvNmJ6TwGcdQjwpgJWt52w>