Perfect frame transmission time calculation in SampleRate (../ath_rate/sample.c)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Perfect frame transmission time calculation in SampleRate (../ath_rate/sample.c)

Naeem Khademi

maybe someone here knows the answer:

I have an ambiguity about the way "perfect frame transmission time" is calculated in SampleRate rate adaptation code (ath_rate/sample.c). The precise calculation of perfect tx_time is very crucial for SampleRate's operation however it seems something is missing here. 

1) Let's assume a scenario of 1500-bytes frame transmission with 802.11g rate=54Mbps. /proc/net/madwifi/ath0/ratestats_1600 always shows the "perfect" tx_time as 644 us while in practice it should be something around 322 us based on analysis in: http://www.cs.clemson.edu/~westall/851/802.11/802_CSMA_CA.pdf. It's almost double! even putting b/g parameters won't make it equal to 644 us.

2) I tried to look in the code to see if this is doubled for all rates (e.g. similar to what you guys have done for the turbo-mode rates using 2x for instance) but couldn't find anything. In fact for the rates of 1~11 Mbps it's almost close to the tx_time calculations in original J. Bicket's proposal (http://dspace.mit.edu/handle/1721.1/34116) but still not exactly the same! 

3) looking at sample.c everything seems to be correctly taken into consideration except: 

A)  It seems the big portion of 644 us comes out of ath_hal_computetxtime(sc->sc_ah, rt, length, rix, AH_TRUE); which is (maybe?) exported by HAL? because the rest of the values are put correctly (SIFS, DIFS and slot-time). Any idea? 

B) It's very strange the way contention window (cw) is taken into consideration. First it assumes that 

unsigned int cw = WIFI_CW_MIN;

Shouldn't it be a random value for first tx attempt? and not always the CW_MIN? Secondly, the below code in sample.c adds the back-off period to the tt, but cw+1 is doubled first and then halved?! and why the "doubled value of cw" is compared to CW_MAX? 

for (x = 0; x <= short_retries + long_retries; x++) {
cw = MIN(WIFI_CW_MAX, (cw + 1) * 2);
tt += (t_slot * cw / 2);
return tt;

To clarify assume that CW_MIN=4,CW_MAX=10, and we have had 1 tx and 1 retry and let's just for now assume that cw=CW_MIN=4 slots. In that case, it should be cw_first_tx=5 slots, cw_retry=min(10,10)=10 slots but the above code calculates it as cw_first_tx=5 slots, cw_retry=5. I think the code should be: 

for (x = 0; x <= short_retries + long_retries; x++) {
cw = MIN(WIFI_CW_MAX, cw );
tt += (t_slot * (cw+1) );
return tt;

Please correct me if I'm wrong. 

4) It's not clear if ratestats_1600 table calculates the frame sizes from 250~1600 bytes with the same measure? I wonder sending thousands of 255-bytes frames at 6 Mbps won't change the tx_time in benefit of them compare to few 1500-bytes frames at 54 Mbps? is framelen taken into account when exporting the rate table? to calculate how would tx_time become if those 250-bytes frames were 1600-bytes frames and then exporting them to rate table?     





AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
Madwifi-users mailing list
[hidden email]