Hi there,

Two questions in one really.

Firstly, how does the Broadcom auto-rate setting work? I've been told it works on a client by client basis, remembering the speed which it last communicated with a client. However, I suspect it possibly works by having a fixed rate, and going up or down on that rate depending on which client it spoke with last.

Also, if it's on a client by client basis, how do I find out the rate for each client?

I want to make an auto QoS script which limits the rate to each client based on their connected rate, which means that clients can only use up to 50% of their total available bandwidth, to prevent one client saturating the entire link. I'm having problems with 1mbps clients pulling down the whole network, so 36mbps clients don't get a fair share.

I'd like to make it so fast clients get a higher priority and more throughput than low clients, but at the moment it seems like the slow clients are pulling down the entire network.

Any ideas?

Can confirm from practice in a network with star topology (single AP and several clients), all broadcom based,  that the modulation bitrate is determined per client. While communicating statistics are gathered about required retransmissions and signal strength and a rate gets negotiated that provides for reliable demodulation, individual for each client.

To prevent the situation you describe I've made sure that signal strengths are always reasonable (use of directional antennas by clients that struggle) and I activated the request to send / clear to send (RTS/CTS) procedure. Default the RTS limit package size is set so high that requests do not get made. After a client has been WPA authenticated and authorised (which doesn't work I found with a low RTS setting) a script running on all clients switches the RTS value to 10. At least now also the slow link will ask for permission before occupying the channel and others will have a chance. This is also useful to prevent the 'hidden node' issue. Some clients may not hear others and cause interference that can be reduced by always having short request packages precede data transmissions.

The script checks every 5 minutes or so whether there is still connectivity. If not it brings the RTS value back up high so wpa can get negotiated.

This sounds quite promising.

I don't use WPA or anything like that. The system I run is a kind of pay as you go system, where people pay their monthly fee (£3), and get access to the Internet through a firewall further up the line. I use the RTS value as about 150 if I remember right. I tried lower RTS/CTS values, but took the theory that the RTS and CTS part of the protocol was less efficient on small packets, since going through all the RTS and CTS part of it for just a TCP ACK packet seemed pointless.

Has anyone any idea of the memory location in which the Broadcom driver stores the list of MAC addresses which are connected, and therefore I could then determine the rate for each client possibly since that may be in a similar memory location? I know Broadcom aren't very open about their specifications, but people seem to have found different parts.

I can't get the memory dump commands in the WL command to work, which is a shame otherwise things would be really easy!

Looking at http://bcm-v4.sipsolutions.net/802.11/TX it would appear that management of the rates is done in the driver and the transmitter simply gets told per package what rate to use for data and for RTS/CTS packages.
Have not studied this in depth at all though, so may be wrong.
You might want to study the b43 driver source code at http://linuxwireless.org/en/users/Drivers/b43 and see how this rate management is done by an access point and make the values accessible from user space to do the QoS that you had thought out.

I've found this bit already, but I can't seem to see a lot about where in the memory things would be stored.

It looks like there's no specified memory address in those drivers, so I guess it gets decided when they're compiled. So it would probably be different for them to the Broadcom ones anyway

I guess I'll have to keep looking. The problem is I'm not even sure how to do a complete memory dump. If I could do one of those, then I could search within it for the MAC address of my client, and then see what data there is around that, perhaps even try fixed rates, etc, to see what changes.