minstrel.txt

最新之atheros芯片driver source code, 基于linux操作系统,內含atheros芯片HAL全部代码

results.

The calculation (performed for each rate, at each timer interrupt) of the
probability of success is:

         Psucces_this_time_interval * (100 - ath_ewma_level) + (Pold * ath_ewma_level)
Pnew =  ------------------------------------------------------------------------------
                  100

                            number_packets_sent_successfully_this_rate_time_interval
Psuccess_this_time_interval=--------------------------------------------------------
                             number_packets_sent_this_rate_time_interval


If no packets have been sent for a particular rate in a time interval, no
calculation is carried out. The Psuccess value for this rate is not changed.

If the new time interval is the first time interval (the module has just been
inserted), then Pnew is calculated from above with Pold set to 0.

The appropriate update interval was selected on the basis of choosing a
compromise between

 * collecting enough success/failure information to be meaningful
 * minimising the amount of cpu time spent do the updates
 * providing a means to recover quickly enough from a bad rate selection.

The first two points are self explanatory. When there is a sudden change in
the radio environment, an update interval of 100 ms will mean that the rates
marked as optimal are very quickly marked as poor. Consequently, the sudden
change in radio environment will mean that minstrel will very quickly switch
to a better rate.

A sudden change in the transmission probabilities will happen when the
node has not transmitted any data for a while, and during that time
the environment has changed. On starting to transmit, the probability
of success at each rate will be quite different. The driver must adapt
as quickly as possible, so as to not upset the higher TCP network
layers.

Module Parameters
==============================================================================
The module has three parameters:

name              default value    purpose
ath_ewma_level      75%            rate of response to new data. A value of 100 is VERY responsive.
ath_lookaround_rate 10%            percent of packets sent at non optimal speed.
ath_segment_size   6000            maximum duration of a retry segment (microseconds)





Test Network
==============================================================================

We used three computers in our test network. The first two, equipped with
atheros cards running in adhoc mode. We used a program that sends a fixed
number of TCP packets between computers, and reports on the data rate. The
application reports on the data rate - at an application layer level, which is
considerably lower than the level used in transmitting the packets.

The third computer had an atheros card also, but was running network monitor
mode with ethereal. The monitor computer was used to see what data rates were
used on the air. This computer was a form of "logging of the connection"
without introducing any additional load on the first two computers.

It was from monitoring the results on the third computer that we started to
get some confidence in the correctness of the code. We observed TCP backoffs
(described above) on this box. There was much celebration when the throughput
increased simply because the retry chain was finished in under 26 ms.

Our view was that throughput between the two computers should be as close as
possible (or better than) what can be achieved by setting both ends to fixed
rates. Thus, if setting the both ends to fixed rates significantly increases
the throughput, a reasonable conclusion is that a fault exists in the adaptive
rate rate.

We recorded throughputs (with minstrel) that are within 10% of what is
achieved with the experimentally determined optimum fixed rate.


Notes on Timing
==============================================================================

As noted above, minstrel calculates the throughput for each rate. This
calculation (using a packet of size 1200 bytes) determines the transmission
time on the radio medium. In these calculations, we assume a contention window
min and max value of 4 and 10 microseconds respectively.

Further, calculation of the transmission time is required so that we can
guarantee a packet is transmitted (or dropped) in a minimum time period.  The
transmission time is used in determining how many times a packet is
transmitted in each segment of the retry chain.

Indeed, the card will supply the cwmin/cwmax values directly
 iwpriv if_name get_cwmin <0|1|2|3> <0|1>

We have not made direct calls to determine cwmin/cwmax - this is an area for
future work. Indeed, the cwmin/cwmax determination code could check to see if
the user has altered these values with the appropriate iwpriv.

The contention window size does vary with traffic class. For example, video
and voice have a contention window min of 3 and 2 microseconds
respectively. Currently, minstrel does not check traffic class.

Calculating the throughputs based on traffic class and bit rate and variable
packet size will significantly complicate the code and require many more
sample packets. More sample packets will lower the throughput achieved. Thus,
our view is that for this release, we should take a simple (but reasonable)
approach that works stably and gives good throughputs.


Values of cwin/cwmax of 4 and 10 microseconds are from 
IEEE Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) specifications, Amendment : Medium Access Control (MAC) Enhancements for
Quality of Service (QoS) P802.11e/D12.0, November 2004.


Internal variable reporting
==============================================================================

The minstrel algorithm reports to the proc file system its internal
statistics, which can be viewed as text. A sample output is below:

cat /proc/net/madwifi/ath0/rate_info


rate data for node:: 00:02:6f:43:8c:7a
rate     throughput  ewma prob   this prob  this succ/attempt   success    attempts
     1         0.0        0.0        0.0          0(  0)          0           0
     2         1.6       92.4      100.0          0(  0)         11          11
     5.5       3.9       89.9      100.0          0(  0)         11          11
    11         6.5       86.6      100.0          0(  0)         10          11
     6         4.8       92.4      100.0          0(  0)         11          11
     9         6.9       92.4      100.0          0(  0)         11          11
    12         9.0       92.4      100.0          0(  0)         11          11
    18        12.1       89.9      100.0          0(  0)         11          11
    24        15.5       92.4      100.0          0(  0)         11          11
    36        20.6       92.4      100.0          0(  0)         11          11
 t  48        23.6       89.9      100.0          0(  0)         12          12
T P 54        27.1       96.2       96.2          0(  0)        996        1029


Total packet count::    ideal 2344      lookaround 261

There is a separate table for each node in the neighbor table, which will
appear similar to above.

The possible datarates for this node are listed in the column at the left. The
calculated throughput and "ewma prob" are listed next, from which the rates
used in retry chain are selected. The rates with the maximum throughput,
second maximum throughput and maximum probability are indicated by the letters
T, t, and P respectively.

The statistics gathered in the last 100 ms time period are displayed in the
"this prob" and "this succ/attempt" columns.

Finally, the number of packets transmitted at each rate, since module loading
are listed in the last two columns. When interpreting the last four columns,
note that we use the words "succ" or "success" to mean packets successfully
sent from this node to the remote node. The driver determines success by
analysing reports from the hal. The word "attempt" or "attempts" means the
count of packets that we transmitted. Thus, the number in the success column
will always be lower than the number in the attempts column.

When the two nodes are brought closer together, the statistics starts
changing, and you see more successful attempts at the higher rates. The ewma
prob at the higher rates increases and then most packets are conveyed at the
higher rates.

When the rate is not on auto, but fixed, this table is still available, and
will report the throughput etc for the current bit rate. Changing the rate
from auto to fixed to auto will completely reset this table, and the operation
of the minstrel module.