Naeem Khademi
2011-07-16 19:32:16 UTC
Hi
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?
Cheers,
Naeem
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?
Cheers,
Naeem