Subject: Re: ath seems still buggy
To: Greg Troxel <gdt@ir.bbn.com>
From: David Young <dyoung@pobox.com>
List: current-users
Date: 10/21/2005 17:06:09
On Fri, Oct 21, 2005 at 05:34:19PM -0400, Greg Troxel wrote:
> I have run some rate control experiments in a semi-quiet environment
> (two ath cards and no other 802.11 within at least 100m and probably
> 300m or more).
> 
> With onoe, it's clearly buggy.  the rate drops from 11 to 5 (5.5
> really) due to errors (when I induce them), but then doesn't drop
> further; it keeps setting -1 and then claiming 11->5.5.  Output really
> seems to be at 5.5.  With low retries, it doesn't go back to 11.
> 
> The logic to drop rate seems perhaps off, unless it assumes (and it's
> correct) that failed packets report retries at the same time.  In my
> opinion, if the # of failed packets is significant compared to those
> that make it, backing off is in order (unless one finds that factors
> other than rate cause loss, and track the performance of various
> rates, and respond quickly to changes caused by motion).

Factors other than S/N ratio cause loss.
Multipath is important, especially outdoors---see
<http://pdos.lcs.mit.edu/~rtm/papers/p442-aguayo.pdf>.  Packet duration
is important, too, especially in the face of pulsed/bursty interference
(microwave ovens) and (according to anecdote) hidden nodes.

SampleRate, <http://www.pdos.lcs.mit.edu/papers/jbicket-ms.pdf>, tracks
the performance of various rates.

> All that said, the basic scheme seems reasonable if not optimal.
> 
> With sample, I see a return to high rate when warranted.  But, it
> seems to endure a huge number of failed transmissions without backing
> off in rate.

This is part of the design, as I understand it.  Even at high rates
of packet loss, a high bitrate may still have higher throughput than
a low rate.  SampleRate tracks the Expected Transmission Time (ETT)
for each packet length at each bitrate, and seeks to minimize ETT by
its choice of bitrate.

BTW, there are a couple of parameters controlled by sysctls that will
make SampleRate dedicate more time to sampling other rates.

> It would be nice to take advantage of multi-rate retry, which my cards
> seem to have.

I think SampleRate will do that.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933