Re: [Madwifi-devel] A few questions about TX descriptors and the Sample rate control algorithm
Status: Beta
Brought to you by:
otaku
From: Scott R. <sco...@gm...> - 2009-07-20 23:32:52
|
On 17/07/2009, at 11:41 PM, Ignacy Gawedzki wrote: > Hi everyone, > > I know that the Sample rate control algorithm has been superceeded by > Minstrel, but I still have a few questions about details of the code > and I > thought maybe some of you here could answer them. > > After having implemented a pretty straightforward transmission time > *measurement* mechanism, first in madwifi-free and then in ath5k, > I'm in need of > *calculating* the the transmission times, much in the way the Sample > algorithm > does (i.e. without taking into account the time spent waiting for > the medium > to become idle). > > Before my first question about the TX descriptors, let me summarize > what I've > understood so far and please correct me if I'm wrong. The TX > descriptor, as > retrieved after transmission by the firmware, contains the short > retry count > (i.e. number of failed CTS receptions), the long retry count (i.e. > number of > failed ACK receptions), as well as the multi-rate retry chain. > Based on that, > the overall time spent transmitting the frame, minus the time spent > waiting > while the medium was busy, is calculable. Since RTS and CTS frames > are always > transmitted at the basic rate, it only matters to know the overall > short retry > count. Here comes the question: is the short retry count provided > in the TX > descriptor the *overall* count or only the count for the last rate > in the > retry chain? This is easily able to be confirmed by looking at a passive capture of the traffic on a separate box and seeing how many frames actually made it onto the air. > > Now a few questions about Sample. The long retry count indicates > how many > overall failed attempts were made to transmit the DATA frame > itself. The > first thing that strikes me in ath_rate/sample/sample.c is in the way > update_stats() calls calc_usecs_unicast_packet(). The latter is > called for > every rate in the retry chain with the overall short retry count and > the > number of attempts at this rate as the long retry count and all the > return > values are summed together. This means that the time taken by the > short > retries may be counted several times, if only at least one > alternative rate > was attempted. The second strange thing is in > calc_usecs_unicast_packet() > itself, in the way ctsduration is calculated. It seems that the > time taken by > the DATA frame is added to ctsduration (by calling > ath_hal_computetxtime()) as > many times as there were short retries + 1 (i.e. short *attempts*). > Then the > same time for DATA is added as many times as there were long > attempts. The > addition to ctsduration seems erroneous. Lastly, it seems that this > calculation of ctsduration is only performed if the frame was > transmitted > using OFDM (i.e. 802.11g) and that other modulation schemes of > 802.11b are > excluded. Why is this so? > All I can say here is that calc_usecs_unicast_packet() is hideously broken and wrong. It has been for some time and I believe minstrel even uses a copy/pasted version of it. I have considered re-writing it from scratch but haven't found the time nor inclination. I think it's safe to assume that if you find something that looks dodgy in the Sample implementation, it probably is. It is a horrible piece of code - do not trust it. -- Scott Raynel WAND Network Research Group Department of Computer Science University of Waikato New Zealand |