I was looking for a way to measure the MAC access time (possibly including the time waiting for a busy channel to become free again) when sending packets over the wireless medium, using OpenWrt and the ath9k driver (together with an Atheros 9xxx based WLAN cards).
I was not able, though, to find any way to obtain this kind of information. Do you know if there is some OpenWrt tool able to perform this task? Or should I patch the driver (and mac80211/iw/...) myself, provided that it can give me this information, interfacing with the Atheros chipset?
I'm very sorry for the huge delay in replying you: I've had some quite heavy days lately!
Thanks for your reply.
So, it should be completely up to the chip to provide this information, for instance, thanks to the driver, is this right?
Unless I misunderstand, for some reason, it seems you're still under the impression this behavior exists in software. This timing is done by an algorithm. This is the raw modulation on used on the band, I'm not sure what you're looking for in software (i.e. OpenWrt). This information could be easily found in a university 1st or 2nd level electronics or radio engineering book.
And to directly answer your question, you would measure (or "see") this timing using a spectrum analyzer. I surmise comparing the data to a WiFi card in Monitor Mode would give you the comprehensive data you seek as well. I'm not sure if the "timing" data you inquire about would be found in the data - perhaps you should further clarify. https://en.wikipedia.org/wiki/Spectrum_analyzer
Sorry, I realize I probably explained my doubt in the wrong manner.
I was actually in doubt whether some chips may provide, through the Linux kernel stack, some debug information related to this and to their internal CSMA/CA operations to the user (through some registers and the driver itself?), such as "average time in which the channel is sensed busy (due to other devices communicating at the same frequency) or spent waiting for the backoff counter to expire", "total number of detected collisions", and so on, just like "iw" is providing information like "signal rx power", "signal average rx power" (with "iw dev station dump").
But I actually realize, if I understood correctly, that this information is typically not provided directly by the chip (so there is no low level code to retrieve it), unlike other more standard statistics; is my undestanding correct?
I'm very sure this is just a math problem (algorithm) I'm referring to...and that is occurs between all devices on air (not just the same SSID)...you're inquiring if common consumer WiFi chips offer access to this low-level data via some hardware register...likely not. At this point, it's noise on the air.
Didn't know the total number of collisions was provided via ifconfig: thanks for the suggestion!
The "and so on" was refferred to the general question about CSMA/CA and DCF parameters being available to the user, but the main information I was looking for was actually the one I listed before: busy channel and number of collisions.
An interesting information could be, since multiple MAC queues are used in my case (AC_BK to AC_VO, each with a different contention window size, except for AC_BK and AC_BE), the random backoff time which each station has to generate, each time, inside the contention window interval, but I doubt, at this point, that this information may be easily available without some patching work...
# iw dev wlan0 survey dump
[...]
Survey data from wlan0
frequency: 2462 MHz [in use]
noise: -95 dBm
channel active time: 1188825760 ms
channel busy time: 98618119 ms
channel receive time: 16553624 ms
channel transmit time: 78253372 ms
which includes the accumulated channel active / busy / receive and transmit time
(not all devices do. but ath9k has most timers). But you might also be interested in features of "Fine Timing Measurement (FTM)" that is making its way into newer Wif chipsi Because thanks to the projected 0.1ns timing accuracy it should be possible with multiple devices to finally do some TDOA with better than 3m accuracy. So this can be really great for an "in-room" positioning system )
@chunkeey Thank you! I did not know about this command (I used iw dev wlan0 station dump but never iw dev wlan0 survey dump), which seems to provide, in any case, other interesting and useful information about channel related times!
The "FTM" features seems very interesting too... I'm definitely going to delve a bit more into these concepts!
)