Re: [Madwifi-users] AR5001X+ connections freeze on heavy transfers
Status: Beta
Brought to you by:
otaku
From: Brian P. <bpr...@no...> - 2010-11-12 23:38:13
|
On Fri, Nov 12, 2010 at 6:09 PM, Dennis Nezic <de...@de...>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 |