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.

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