Hi,
On Thu, 4 Mar 2010, Björn Smedman wrote:
On Thu, Mar 4, 2010 at 3:12 PM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote:
Minstrel definitely performs better in real life.
Agree, minstrel works very well in real life.
yeah - we tested it hard and long outdoors. and indoors. and with driver
faults, and it still worked as well as could be expected.
That said, I looked at the current minstrel code and have a few
puzzlements:
- As I understand it, minstrel is not supposed to delay packets more
than 24 ms to avoid TCP resends. However, if I understand the code,
this is done by limiting each MRR segment to 6 ms, which doesn't seem
right to me. The retries in the second MRR slot will have to wait
a backoff before being used, right?
I took a look at the minstrel code back in madwifi and the comments
there suggest this 24 ms thing is not very theoretically based. It
sounds like a very reasonable explanation though so I'm not saying it
is wrong. But I think there might be another very good reason to limit
the number of attempts at a given rate: after a certain number of
retries we have to conclude that our hypothesis about the packet
error/success rate is probably incorrect, and there is no point in
more retries at that rate.
Agreed. 24 ms was a value that was guessed at, and works well. However, If
there is no limit on the time taken for the entire chain, then performance
drops.
we observed the packets on the air for a tcp transfer (scp). There was
sometimes a 100ms gap after the successful transmission of one packet
before the next one was sent. Turns out that TCP's backoff/congestion
control mechanism was "upset" because of the long transmit time, and had
delayed the sending of the next. By limiting the time taken for an entire
retry chain to be used, we increased TCP throughput.
- Often, two slots in the MRR array use the same rate (e.g. slots 1 and 3).
Maybe we should pick a 'next lower' rate for the lower slot in such a case?
If we are really in a place where the originally attempted rate isn't
workable, this might slightly boost throughput.
Agree. With the same reasoning as above this can be generalized to: if
an MRR slot has failed and we have fallen through to the next one then
that slot should be set up to be optimal under a new hypothesis
(taking the failed MRR segment into account).
yes, This is an enhancement we have discussed.
It would more quickly fill the statistics tables that Minstrel uses, which
is a good thing.
Currently, the retry chain is something like
1.rate with the the highest throughput
2.rate with the the second highest throughput
3.rate with the highest probability
4.base rate of 1mbit.
You could change it to:
1.rate with the the highest throughput
2.rate with the the second highest throughput
3.rate with the highest probability,
such that this rate does not equal 1. or 2.
4.base rate of 1mbit.
Do not use the 'next lower' rate. This is effectively a variant on the
step up/step down philosophy, which does not apply to rate algorithms.
The philosophy that the success probability of a rate is proportional to
the bit rate is wrong. 100.00% wrong. Since things like PID have this
philosophy at their core, PID will always fail.
Derek.
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
"The only thing IE should be used for is to download Fire Fox"
"My favorite language is call STAR. It's extremely concise. It has
exactly one verb '*', which does exactly what I want at the moment."
--Larry Wall
