Subject: Re: ath seems still buggy
To: Greg Troxel <email@example.com>
From: Sam Leffler <firstname.lastname@example.org>
Date: 10/21/2005 18:22:30
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.