Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

index_to_rate[] (for @bcopeland fork) #7

Open
VanLaser opened this issue Feb 15, 2017 · 1 comment
Open

index_to_rate[] (for @bcopeland fork) #7

VanLaser opened this issue Feb 15, 2017 · 1 comment

Comments

@VanLaser
Copy link

VanLaser commented Feb 15, 2017

@bcopeland

Hello,

Sorry to put the issue here, but I can't open one at https://github.com/bcopeland/wmediumd fork. Using kernel 4.9.8-1 (Arch Linux) built with mac802_hwsim, I encounter the following issues. I'm not very familiar with wmediumd, so I don't know exactly what the problem is, but, here are the "symptoms":

Grepping 'dmesg', the wlan interfaces, created by loading mac80211_hwsim, use rates configured by minstrel_ht. Here's a rc_stats sample from /sys/kernel/debug/ieee80211/phy7/netdev:wlan0/stations/02:00:00:00:01:00 (where phy7 is of course the id associated with wlan0):

best   __________rate_________    ________statistics________    ________last_______    ______sum-of________
rate  [name idx airtime max_tp]  [avg(tp) avg(prob) sd(prob)]  [prob.|retry|suc|att]  [#success | #attempts]
        1     0    9738    0.9       0.9      99.9      0.0     100.0   1     1 1           654   1282     
        2     1    4922    1.6       1.6      86.8      1.8     100.0   1     0 0            47   97       
        5.5   2    1858    4.7       4.5      86.9      1.8     100.0   2     0 0           126   203      
       11     3     982    9.1       8.3      82.4      1.8     100.0   4     0 0          4299   4412     
        6     4    1648    5.3       5.1      86.8      1.8     100.0   3     0 0           203   268      
        9     5    1112    8.0       7.3      82.3      1.8     100.0   4     0 0            61   190      
       12     6     844   10.5      10.5      92.4      1.7     100.0   5     0 0            54   183      
   D   18     7     576   15.5      14.9      86.6      1.6     100.0   5     0 0            35   187      
  C    24     8     440   20.4      18.6      82.2      1.7     100.0   6     0 0          1292   1464     
A   P  36     9     308   29.1      29.1      99.9      0.0     100.0   6     0 0          5392   7739     
 B     48    10     240   37.3      19.9      48.0      0.8      33.3   6     0 0           915   1648     
       54    11     216    0.0       0.0       0.0      0.0       0.0   6     0 0             0   222   

As you can see, the rates and indexes used are those from the first 2 columns.

Now, when inspecting the function queue_frame() from wmediumd.c (bcopeland fork), it seems to me that the array index_to_rate[], that gets consulted each time an index must be translated to a rate, is out of place - by logging the index value, I get for example values such as 9 etc. which are higher than the dimension of the array. So, my question is, is the following modification the 'right' one to make?

static int index_to_rate[] = {
	10, 20, 55, 110, 60, 90, 120, 180, 240, 360, 480, 540
};

Since I'm not familiar with wmediumd, I have no clue about what causes this new set of rates to kick in, instead of the 'old' one. When does this happen - all the time? or does it depend on minstrel_ht (vs minstrel)? Even in this case, I'm not entirely sure the index is not 'offset' by 1 - if I log the rate index for an acknowledged frame (rate_idx in queue_frame(), after the loop), it seems to be higher (by 1) than the one selected as ideal (A P) in rc_stats (e.g. I get index 10 as the most used, but rc_stats shows that index 9 was the ideal one).

Thanks

@bcopeland
Copy link

bcopeland commented Feb 15, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants