On 3/10/22 9:27 AM, Jonas Jelonek wrote:
On 3/10/22 16:43 UTC, Ben Greear wrote:
Certain 802.11a/g/n Atheros chips provide a 0,5dB tx-power step granularity, while Mediatek 802.11ac chips have 1dB or even 3dB step width. So I would argue that a 1dB step width is a good compromise as the common value for new tpc algorithms.
If you use 0.5db units for that struct, then it will support anything with that granularity or higher.
But, fine with me if you want to just have it be 1db units.
using 0.5db is more appropriate for the already existing chips that
support this granularity, and is more future-proof.
1db units may be easier to handle for the API and/or TPC algorithms
but again limits existing hardware capabilities.
The ath9k chips I have used so far support a minimum tx-power of -5dBm (=0,32mW), Mediatek has a min of 0dBm (=1mW)… so I would argue to use 0dBm (=1mW) as common minimum tx-power value, as the any possible spatial reuse gain happens from 0dBm up to max tx-power.
If a chip supports setting to txpower to -5, then why not let the API support that? Have The value -128
be 'do not set', and anything else will mean 'try to set the chip to this power or the nearest thing to it
that the chip supports'.
I agree with that, having -128 as value for 'not set' or 'invalid'
would leave the negative dBm for chips that support this.
Whether the TPC then actually makes use of this should not be the
reason to use 0 as default.
To your previous question:
retry_count = 1 is intended to be a single tx, so naming the struct
member 'try_count' would be more appropriate?
Yes, I think so.
In my own hackings, I have also used a try_count of '0' to mean try once
but request NOACK on the frame. I am not sure if that even applies in
your case though...
Thanks,
Ben
Besides this, I will add proper documentation for this in the
following patch version to clarify the units and meanings.
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
