Subject: Re: ath seems still buggy
To: Greg Troxel <>
From: Sam Leffler <>
List: current-users
Date: 10/21/2005 18:22:30
Greg Troxel wrote:
>   Factors other than S/N ratio cause loss.
>   Multipath is important, especially outdoors---see
>   <>.  Packet duration
>   is important, too, especially in the face of pulsed/bursty interference
>   (microwave ovens) and (according to anecdote) hidden nodes.
> Sure, I realize that, but 54 Mb/s vs 1 Mb/s is huge in terms of Eb/N0.
> Thanks for the reference.
>   SampleRate, <>, tracks
>   the performance of various rates.
> I realized that when I started to read the code.
>   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.
> That's fair, but I'm seeing many packets in a row with no ack (failed
> transmission), which is way worse than a lot of retries.

As I said there are problems with the freebsd code from which you're 
working.  Compare things against the code in madwifi (aka linux) as 
that's John's native development environment.

>   > It would be nice to take advantage of multi-rate retry, which my cards
>   > seem to have.
>   I think SampleRate will do that.
> Unless you use rts/cts; see near line 251.  I'm not sure why the code
> is written so that if rts/cts then no multi-rate retry (time to read
> the paper...).
> Can you explain the long and short retry counters, with and without
> rts/cts?  With rts/cts, I typically observe many RTS attempts,
> followed by a single cts and a successful data/ack.  I haven't
> observed without rts/cts nearly as much lately.

Long retries are data frame retransmits, short are rts frames.  The 
excessive rts retransmits may be due to a bug in the duration 
calculation; I noticed this fix was not in the latest netbsd code.