Open lemoer opened 3 years ago
CC: @CodeFetch, @s-2
The next step would be to think about aggregating the statistics in a meaningful way.
Awesome!
Since these are just counters (reset upon (re-)association I would guess?) it seems we have to poll and diff these periodically to build a histogram etc. for the current time interval...
So it's probably not quite real-time (however it would also be cool if the user could see at least their current connection quality from the router stats (nextnode) page)...
But for a beginning, we might just accumulate the node_recv
stuff (looks simpler at least ;) ) for fixed intervals, e.g. 15 minutes, for all clients within that interval, so we could further accumulate these in larger steps (30 min / 1h / 2h / ... / 1d / ...) when needed.
I must admit I'm absolutely not familiar with plotting stuff in Grafana, but this Heatmap Graph looks quite cool :) https://grafana.com/docs/grafana/latest/getting-started/intro-histograms/#heatmaps
The colouring might be confusing though, when the user would expect red to mean "weak link quality" rather than "most packets had this link quality" :thinking:
Both TX and RX stats are both also available for mesh partners.
Here is an example for rc_stats:
root@NDS-Alte-Kaserne:~# cat /sys/kernel/debug/ieee80211/phy0/netdev\:mesh0/stations/7a\:89\:39\:44\:16\:b1/rc_stats
best ____________rate__________ ________statistics________ _____last____ ______sum-of________
mode guard # rate [name idx airtime max_tp] [avg(tp) avg(prob) sd(prob)] [retry|suc|att] [#success | #attempts]
CCK LP 1 1.0M 120 10548 0.0 0.0 79.2 0.0 0 0 0 4488 5353
CCK LP 1 2.0M 121 5476 0.0 0.0 0.0 0.0 0 0 0 0 0
CCK LP 1 5.5M 122 2411 2.4 0.0 0.0 0.0 0 0 0 0 0
CCK LP 1 11.0M 123 1535 4.8 0.0 0.0 0.0 0 0 0 0 0
CCK SP 1 2.0M 125 5380 0.0 0.0 0.0 0.0 0 0 0 0 0
CCK SP 1 5.5M 126 2315 2.4 0.0 0.0 0.0 0 0 0 0 0
CCK SP 1 11.0M 127 1439 4.8 0.0 0.0 0.0 0 0 0 0 0
HT20 LGI 1 MCS0 0 1477 4.8 4.8 100.0 0.0 3 0 0 2 2
HT20 LGI 1 MCS1 1 738 9.7 9.7 100.0 0.0 0 0 0 1 1
HT20 LGI 1 MCS2 2 492 14.6 14.6 100.0 0.0 5 0 0 5 5
HT20 LGI 1 MCS3 3 369 17.0 17.0 97.6 0.0 5 0 0 25 37
HT20 LGI 1 MCS4 4 246 24.4 24.4 97.9 0.0 5 0 0 82 120
HT20 LGI 1 MCS5 5 185 29.2 29.2 100.0 0.0 5 0 0 377 533
HT20 LGI 1 MCS6 6 164 31.7 31.7 99.7 0.0 5 0 0 353 496
HT20 LGI 1 MCS7 7 148 34.1 34.1 98.9 0.0 5 0 0 1104 1503
HT20 LGI 2 MCS8 10 738 9.7 9.7 100.0 0.0 0 0 0 1 1
HT20 LGI 2 MCS9 11 369 17.0 17.0 98.5 0.0 5 0 0 19 26
HT20 LGI 2 MCS10 12 246 24.4 24.4 95.7 0.0 5 0 0 164 225
HT20 LGI 2 MCS11 13 185 29.2 29.2 100.0 0.0 5 0 0 577 764
HT20 LGI 2 MCS12 14 123 36.6 36.6 85.4 0.0 6 0 0 4323 5308
HT20 LGI 2 MCS13 15 92 43.9 31.7 65.9 0.0 6 0 0 10665 13179
HT20 LGI 2 MCS14 16 82 46.3 36.6 70.6 0.0 6 0 0 14147 17882
HT20 LGI 2 MCS15 17 74 48.8 36.6 68.3 0.0 6 0 0 9942 13298
HT20 LGI 3 MCS16 20 492 14.6 14.6 100.0 0.0 0 0 0 1 1
HT20 LGI 3 MCS17 21 246 24.4 24.4 99.1 0.0 5 0 0 148 205
HT20 LGI 3 MCS18 22 164 31.7 31.7 99.8 0.0 5 0 0 687 883
HT20 LGI 3 MCS19 23 123 36.6 21.9 56.0 0.0 6 0 0 4329 5329
HT20 LGI 3 A MCS20 24 82 46.3 46.3 96.8 0.0 6 1 1 23384 28284
HT20 LGI 3 D MCS21 25 62 51.2 39.0 67.2 0.0 6 0 0 18645 24098
HT20 LGI 3 MCS22 26 55 53.7 24.4 43.3 0.0 6 0 0 14976 20647
HT20 LGI 3 MCS23 27 49 56.1 24.4 41.7 0.0 6 0 0 9304 14782
HT20 SGI 1 MCS0 30 1329 4.8 0.0 0.0 0.0 0 0 0 0 0
HT20 SGI 1 MCS1 31 665 9.7 9.7 100.0 0.0 0 0 0 1 1
HT20 SGI 1 MCS2 32 443 14.6 14.6 100.0 0.0 5 0 0 1 1
HT20 SGI 1 MCS3 33 332 19.5 19.5 100.0 0.0 5 0 0 41 56
HT20 SGI 1 MCS4 34 222 26.8 26.8 100.0 0.0 5 0 0 223 287
HT20 SGI 1 MCS5 35 166 31.7 31.7 100.0 0.0 5 0 0 1313 1767
HT20 SGI 1 MCS6 36 148 34.1 34.1 95.8 0.0 5 0 0 1569 2025
HT20 SGI 1 MCS7 37 133 36.6 36.6 88.4 0.0 6 0 0 2457 3105
HT20 SGI 2 MCS8 40 665 9.7 9.7 96.4 0.0 0 0 0 3 4
HT20 SGI 2 MCS9 41 332 19.5 19.5 100.0 0.0 5 0 0 97 120
HT20 SGI 2 MCS10 42 222 26.8 26.8 97.2 0.0 5 0 0 223 301
HT20 SGI 2 MCS11 43 166 31.7 31.7 97.9 0.0 5 0 0 1142 1482
HT20 SGI 2 MCS12 44 111 39.0 36.6 84.6 0.0 6 0 0 6835 8471
HT20 SGI 2 MCS13 45 83 46.3 34.1 68.3 0.0 6 0 0 14976 18451
HT20 SGI 2 B P MCS14 46 74 48.8 41.5 76.5 0.0 6 0 0 16095 20303
HT20 SGI 2 MCS15 47 67 51.2 29.2 52.9 0.0 6 0 0 13128 17761
HT20 SGI 3 MCS16 50 443 14.6 14.6 100.0 0.0 5 0 0 1 1
HT20 SGI 3 MCS17 51 222 26.8 26.8 99.2 0.0 5 0 0 267 374
HT20 SGI 3 MCS18 52 148 34.1 34.1 96.9 0.0 5 0 0 2680 3398
HT20 SGI 3 MCS19 53 111 39.0 34.1 78.5 0.0 6 0 0 7863 9733
HT20 SGI 3 C MCS20 54 74 48.8 39.0 71.7 0.0 6 0 0 26683 32582
HT20 SGI 3 MCS21 55 56 53.7 34.1 59.8 0.0 6 0 0 23674 30577
HT20 SGI 3 MCS22 56 49 56.1 36.6 59.2 0.0 6 0 0 16415 22942
HT20 SGI 3 MCS23 57 44 58.5 24.4 39.8 0.0 6 0 0 7557 12566
(here we can see, that the higher MCS values have multiple streams).
And here for node_recv:
root@NDS-Alte-Kaserne:~# cat /sys/kernel/debug/ieee80211/phy0/netdev\:mesh0/stations/7a\:89\:39\:44\:16\:b1/node_recv
HT20 HT40 SGI LGI
MCS 0 : 9 0 3 6
MCS 1 : 391 35 175 251
MCS 2 : 2537 377 1585 1329
MCS 3 : 4623 945 3087 2481
MCS 4 : 38304 5467 24625 19146
MCS 5 : 116512 13150 73946 55716
MCS 6 : 158094 18126 97982 78238
MCS 7 : 178237 20951 108592 90596
MCS 8 : 257 31 153 135
MCS 9 : 5159 1102 3697 2564
MCS 10 : 37635 5046 25581 17100
MCS 11 : 144683 14679 89303 70059
MCS 12 : 447138 38304 266353 219089
MCS 13 : 391359 48389 223706 216042
MCS 14 : 399590 47698 225058 222230
MCS 15 : 289290 35597 161316 163571
MCS 16 : 1471 182 836 817
MCS 17 : 36854 4124 24215 16763
MCS 18 : 224978 20133 133976 111135
MCS 19 : 545994 44823 320632 270185
MCS 20 : 815074 78400 465582 427892
MCS 21 : 307777 41356 161931 187202
MCS 22 : 213725 28706 112729 129702
MCS 23 : 108628 14542 53693 69477
CCK-1M/LP : 0
CCK-2M/LP : 0
CCK-5.5M/LP : 0
CCK-11M/LP : 1
CCK-2M/SP : 0
CCK-5.5M/SP : 0
CCK-11M/SP : 0
OFDM-6M : 0
OFDM-9M : 0
OFDM-12M : 45392736
OFDM-18M : 0
OFDM-24M : 0
OFDM-36M : 0
OFDM-48M : 0
OFDM-54M : 0
The counters actually reset, if a client is reassociated. Therefore if we want to aggregate all clients into one counter, we need to keep counters for "gone" clients, such that the overall counter keeps increasing monotonically even if clients are disassociated.
Is it needed to have monotonically increasing counters?
What I would be interested in were floating average, best client, worst client, median, upper and lower quartile. From this one can already get an idea about the distribution. Of course a histogram would be nice, but do we really want to send so much data? I think it is hard for the user to understand. Still from another perspective I would say in the future we might want to train an analytics model which automatically detects outliers. So I don't know...
ath9k
(Maybe this applies to other chipsets using minstrel in kernel as well).
RX Statistics:
I checked, that the sum of the "MCS" values correlates to the rx packets on client0.
TX Statistics:
I checked, that the sum of the "sum-of #success" values correlates to the tx packets on client0. The "sum-of #attempts" column has even higher values, which might be interesting as well. They show, how many packets were sent, but failed.
The rc_stats can also be obtained as csv:
ath10k
The above mentioned debugfs files do not work in ath10k. Ath10k does not use the mac80211 minstrel algorithm in the kernel. The wifi chips offload the MCS selection. Therefore ath10k has other mechanisms.
Theoretically there is a debugfs file called tx_stats:
ath10k_peer_stats_enabled()
suggests that only some devices support the tx_stats counters.