Re: AR5001X+ connections freeze on heavy transfers

On Fri, Nov 12, 2010 at 6:09 PM, Dennis Nezic <[email protected]>wrote:

> On Thu, 4 Nov 2010 20:24:37 -0400, Dennis Nezic wrote:
> > When I do heavy transfers (500+ mb), regardless of the protocol (NFS,
> > http, scp, etc), after a non-predictable time the transfers usually
> > freeze. Strangely, however, I can still happily ping the machine and
> > ssh into it -- only the main transfer seems affected. The only remedy
> > seems to be to unload/reload ath_pci. (I haven't seen this problem
> > between any of my non-madwifi machines.)
> >
> > Currently I'm using madwifi-ng-0.9.4.4133.20100621 and linux kernel
> > 2.6.36, although I've had this problem for a while.
> >
> > I'm using the default ath_rate_sample. Perhaps I should try the
> > others? Perhaps I should provide more (rate)stats too :P.
> >
> > It's probably related to http://madwifi-project.org/ticket/1790
>
> None of the ath_rate_* algorithms fix the problem. (Minstrel performs
> far better than the others, but eventually succumbs.)
>
> Here are two athstats, using ath_rate_sample, taken 50minutes apart,
> during a large continuous nfs file transfer:
>
> 422 tx management frames
> 169236 tx frames discarded due to queue depth
> 237 tx failed due to too many retries
> 121886 long on-chip tx retries
> 65 tx frames with no ack marked
> 1023541 tx frames with short preamble
> 21649 tx frames with an alternate rate
> 20515 rx failed due to bad CRC
> 108749 PHY errors
>    4505 OFDM timing
>    33 OFDM restart
>    104010 CCK timing
>    201 CCK restart
> 385 periodic calibrations
> rssi of last ack: 26
> rssi of last rcv: 29
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx   512925 rx    99313
> [2] tx   510788 rx      174
>
> [48minutes later...]
>
> 901 tx management frames
> 263728 tx frames discarded due to queue depth
> 1053 tx failed due to too many retries
> 221105 long on-chip tx retries
> 66 tx frames with no ack marked
> 1660431 tx frames with short preamble
> 43636 tx frames with an alternate rate
> 23781 rx failed due to bad CRC
> 174894 PHY errors
>    7282 OFDM timing
>    33 OFDM restart
>    167365 CCK timing
>    214 CCK restart
> 480 periodic calibrations
> rssi of last ack: 23
> rssi of last rcv: 25
> 1 switched default/rx antenna
> Antenna profile:
> [1] tx   833189 rx   163656
> [2] tx   827077 rx      271
>
>

Is there a reason you aren't using ath5k?  Especially with kernel 2.6.36, I
imagine ath5k is getting a lot more attention than madwifi.

In a deployed setup, I ended up using a madwifi rev somewhere in the 3300's
with a proprietary HAL and a handful of patches applied out of OpenWrt.  You
may want to try an approach like that.  Here is a link to OpenWrt's madwifi
package:

https://dev.openwrt.org/browser/trunk/package/madwifi

The patches are there, and the Makefile specifies what rev those are meant
to be applied against, but if you're running on PCs you'd definitely want to
cherry-pick out of that, because more than a few of those patches are with
embedded targets in mind.

Still, for a few months I ran madwifi trunk (something between the 4100 and
4200 revs) on my everyday-use laptop and didn't experience anything like
you're describing (doing lots of large file transfers).  Have you tried
running trunk instead of the 0.9.4 branch?


Brian Prodoehl

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev

_______________________________________________
Madwifi-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-users