still coping with zero packet loss over wireless

still coping with zero packet loss over wireless

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

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?

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 917 bytes --]

Re: still coping with zero packet loss over wireless

[John W. Linville]

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?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: still coping with zero packet loss over wireless

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

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



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 2607 bytes --]