## Re: [Madwifi-devel] Perfect frame transmission time calculation in SampleRate (../ath_rate/sample.c)

 Re: [Madwifi-devel] Perfect frame transmission time calculation in SampleRate (../ath_rate/sample.c) From: Eduard GV - 2011-07-18 19:19:33 ```Sorry, I'm afraid I can only help with 3.B (and I may be wrong): for each retransmission, cw is doubled (until CW_MAX is reached), following its exponential nature. Then the resulting value is halved (I guess) to account for the average expected value of the backoff interval (if the backoff is randomly chosen from a uniform distribution over the interval [0, cw]) . Hope this helps 2011/7/16 Naeem Khademi : > 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 > > > > > > > > ------------------------------------------------------------------------------ > 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. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Madwifi-devel mailing list > Madwifi-devel@... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > > ```

### Thread view

 [Madwifi-devel] Perfect frame transmission time calculation in SampleRate (../ath_rate/sample.c) From: Naeem Khademi - 2011-07-16 19:32:26 Attachments: Message as HTML ```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 ```
 Re: [Madwifi-devel] Perfect frame transmission time calculation in SampleRate (../ath_rate/sample.c) From: Eduard GV - 2011-07-18 19:19:33 ```Sorry, I'm afraid I can only help with 3.B (and I may be wrong): for each retransmission, cw is doubled (until CW_MAX is reached), following its exponential nature. Then the resulting value is halved (I guess) to account for the average expected value of the backoff interval (if the backoff is randomly chosen from a uniform distribution over the interval [0, cw]) . Hope this helps 2011/7/16 Naeem Khademi : > 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 > > > > > > > > ------------------------------------------------------------------------------ > 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. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Madwifi-devel mailing list > Madwifi-devel@... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > > ```

## Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks