On Tue, May 24, 2011 at 8:50 AM, John W. Linville
<linville@tuxdriver.com> wrote:
On Tue, May 24, 2011 at 02:46:59PM +0000, Dave Taht wrote:
> yesterday I finally got a chance to move a few dozen meters out of the lab
> and test the latest build of uberwrt "capetown" and debloat-testing.
>
> I'd hoped with the debloating techniques in place in capetown - reduced
> buffers (4), reduced sw retries (2), hw retries (2, or so I thought) I'd
> actually see some packet loss.
>
> and what I saw instead, was pings that would take as long as 1.6 seconds to
> complete, and zero packet loss until I moved completely out of range of the
> router.
>
> I never thought it would be so hard to lose a packet in my life!
>
> Is there some system tunable, somewhere, in the linux wireless stack that
> I've missed, in getting packets to actually fail in 10s of ms?
Not one of which I am aware. That sort of thing is going to depend
quite a bit on the hardware itself, and it's driver. Maybe some
ath9k folk can comment?
I finally got out from under enough to have a chance to look at this problem with debugfs
root@io:/sys/kernel/debug# cat ./ieee80211/phy0/netdev:wlan2/stations/ce:3d:c7:b0:ae:78/tx_retry_count
291
My assumption is that this is not the value for retries, but the total number of times a given station has had to retry.
Is there anything useful that I can poke around in down here?
(I'd actually gone into this to see if I could pull more info out on the ag71xx issue on the other thread)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.