On 03/14/2015 03:47 AM, Bob Copeland wrote:
On Wed, Mar 11, 2015 at 03:06:18PM -0700, Ben Greear wrote:
I don't see a good way to tie that idx to an actual rate (which involves
flags, nss, mcs values, etc).
Maybe I should also just send the info I care about, which is a 'bps' rate,
channel-width indication, SGI, etc as separate netlink attributes....
My wmediumd fork (https://github.com/bcopeland/wmediumd) could benefit from
this as well -- right now it assumes you use OFDM rates only.
It probably makes sense to send the driver rate array as a separate
netlink message though instead of in-band with CMD_FRAME, since it doesn't
change per frame and amount of data sent over netlink in the datapath already
imposes a performance limit.
It can change with every packet based on rate-control logic, right?
Possibly the power is mostly constant, but I thought I saw email about someone
working on rate-ctrl logic that adjusted power on a per-packet basis, so
thought it best to put in there now.
And, it seems unlikely to me that an extra 16 bytes or so would make a
great deal of difference. Using hash tables instead of linear walks
and other things would likely improve performance more?
Is your simulator available somewhere?
No, sorry..it is a closed source thing that I am working on with another
company...even I do not have any real rights to the code. After a period
of time I may be able to start work on a similar simulator project, but for now all
I can contribute publicly is the kernel parts that must necessarily be open-source.
For what it's worth, the patch I posted seems to work with the user-space
app I've been working on.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
