Greg Troxel wrote:
>   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.
> 
> Sure, I realize that, but 54 Mb/s vs 1 Mb/s is huge in terms of Eb/N0.
> Thanks for the reference.
> 
>   SampleRate, <http://www.pdos.lcs.mit.edu/papers/jbicket-ms.pdf>, 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.

	Sam