Re: AR5001X+ connections freeze on heavy transfers

On Fri, 12 Nov 2010 18:38:02 -0500, Brian Prodoehl wrote:
> 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?

Hmmm ... I wasn't using ath5k before because it didn't support
"managed" (AP) mode ... but it seems to now! I only tried the 0.9.4
(and probably earlier) madwifi-ng branches.

It's interesting that you've never experienced this problem. Perhaps
it's specific to my AR5001X+ pci card.


------------------------------------------------------------------------------
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