What is best practise on setting data rates and basic rates for fine tuning links.

Most users set Rate set to default on both AP and station and let ROS look for the best rates.
On links with issues like long distances (low signal), interferences and/r high noise levels or otherwise issue this might need more fine tuning.

First we need to understand that AP depicts, but never can set higher rates than station would have set if not default.
Second, I have been told that everytime AP steps a link down or up in connected rate the radio's can't communicate for a split second and packages get lost which deteriorate link quality. So it is better to set links manually to best achievable stable connection rate.

Supported versus basic rates if we use the configured options:

Some use all available rates but just disable the highest ones if the link can't maintain the highest rates.
Some set all available supported rates to the highest possible but set basic only to the lowest
Some set only some supported rates, or only one that can be achieved and kept stable, while basic is still only set on lowest.
Some set only some supported rates, or only one, and set the basic to the same.

I recently set both my supported rates as well as the basic to one rate only, the highest all stations can keep without disconnects. I look at the CCQ level to achieve this. I'd like to see near 100%

But, I need better understanding on what exactly is the basic rate needed for?
I have several AP-radio's where I set the supported rate same as basic rate, for instance 24Mbps and I got a nice link statistics for such links. Near 100% CCQ all the time, even for stations that would switch back to lower levels that in default setup would drop back to lower rates.

Recently I have been adviced by MT to set the basic rate to the lowest available rate.
In doing so it means at least same rate has to be set in ´supported´ as well.
The result was that now most of my links show this lowest rate as the rate the link connects to, and only when considerable amount of traffic is running over these links the rate jumps to the higher set rate.
In the mean time the CCQ falls way back on idle links but even on moderate traffic links the CCQ level never reach the solid high near 100% levels any more. The CCQ became more variable around -95.
I had to tune down the supported rate back to the lowest level to get a rock solid 100% CCQ again!

Off course, running a bandwith test on that last option I get ample 60% of the speed out of this link. Un acceptable for a backhaul if that has to be set to 6Mb on a 10Mhz channel width freq. (802.11a).
Set the link back at a fixed 24Mb for supported and only 6Mb for basic I get my higher throughput back again but CCQ never stabilizes at the near 100% range any more.

Set the link back at a fixed 24Mb for both supported and basic rate than my higher througput is still there combined with near 100% CCQ.
But now I am in a situation that links sometimes drop, even although the signal levels are around -50 and noise levels are better than 30dB! (Because of this MT gave me the advice to drop basic back to lowert level)

I need a good advice on why, and when, higher then the lowest basic rates can be used, in combination with what highest supported rates are stabily achievable.

Last, but not least: In case of an AP with many clients.
If some client stations can connect at 48 or 52Mbps but others only at much lower rates. What is best to do here? Set rates at default so AP everytime can find best rate for connection to certain station?
Or set rates to accomodate worst station with a stable connection. If this is only 12Mbps than it is 12Mbps for all units! (In this case the maximum data througput for a strong signal client depends on that one from the bad signal client. Not something I'd like...)

Please add your thoughts here so all users can benefit and learn about the working of wifi!
MT manual is not always very clear in what is best practise....

this is a very good topic, can i add if any recommendations or suggestions are flagged as MK to MK or MK to other brand?

this is a very good topic, can i add if any recommendations or suggestions are flagged as MK to MK or MK to other brand?

Basic rate and supported rate settings are an 802.11 feature. So it is industry wide.
Meaning that best practise is general for 802.11 working devices.

Most info about it that I find in google talks more about the b/g and ´n´ networks. I don't think it works different for ´a´ networks but here is were my main interest lies.

I also have some AP networks mixed with UBNT nanostations where their manual talks about data rates and "multicast" rate. I presume "multicast" means actually the same as "basic" rates although ubnt manual reads;"Multicast Rate: This option allows Multicast packets to be sent in higher rates (up to the 54 Mbps) than commonly used (1 Mbps at IEEE 802.11b mode, 6 Mbps at IEEE 802.11g/a mode). This is Ubiquiti's AirOS proprietary feature thus it may be incompatible with the devices from other vendors."
I don't think this is actually right if "multicast" is the same as "basic" because it's an 802.11 implementation. And it also works with MT AP anyway. (In default setting)


So yes, please as much info/experience/advice as you can. The more info the better for understanding and making a good choice in the available options.

hmmm, dissapointing.. nobody has a say about this?

Multicast = general router 'housekeeping' / networking tasks such as exchanging routing information. etc.

Ubiquiti - from what I read regarding their implementation, has allowed a departure from the standard and allows the 'user' (you) to select at what speed the Ubiquiti will attempt to exchange mulitcast information.

Basic rate - the rate at which all devices in a network expect to be able to communicate regardless of the circumstances (noise etc.) Typically this is the lowest rate at which the network can communicate. 802.11b = 1mbps, 802.11g = 6mbps, 802.11a=6mbps, etc.

In the 'standard' multicast communication scenario, the device uses the basic rate to exchange network information will all devices simultaneously in the case of an AP multicast broadcast for example, for devices attached to the AP they will respond with the basic rate unless otherwise specified (Ubiquiti - the departure from the standard).

So - as you can see multicast has really nothing to do with basic rates - it is a 'user' of the setting is all.

Basic rates are what devices use to establish initial connection speeds. It is also the speed at which devices expect to be able to communicate with if other rates should fail - a step down if you will (selected supported rates) regardless of the circumstances (noise, etc). Which is why you typically set the basic rate to the lowest that the protocol(s) will allow - kind of a failsafe. This basic rate is also the rate at which a device will 'drop' down to when idle...I think it is a matter of the device driver doing this to conserve power, reduce noise, and 'save' the device from working harder than necessary to achieve it basic function.

Selected rates - are the rates you set based on conditions at your locations. Typically you would set this at 'one step' lower than what your slowest client device can connect at. This would then theoretically be the fastest, most stable rate, for all devices to connect at, and would prevent 'rate shifting' thus making fewer rebroadcasts of packets etc because they all would get through on the first attempt at the selected rate.

As to devices dropping off even though the 'lower' supportable rate for that device (above 24mbps was selected in the example provided) was the rate selected in both basic and supported. The device dropped off because it could no longer communicate at the rate selected (whether basic or supported since they were both set to 24mbps). So, although most of the time, 24mbps seemed to work, it did not always work. So there are other factors (noise possibly) that made the rate unusable and thus the devices disconnected. Personally, I select the lowest rate as the 'basic' rate. I also select the next to highest rate that can I sustain with the worst client device. I also select the rate just below that one. So in the example above I would have 6mbps as a basic rate, 24mbps and 18mbps (just as a fallback - just in case...)

Some of the other things mentioned here like, my ccq rate drops even though I have 30db of noise margin, and other such comments. That noise level is only what the wireless device 'understands' as noise. If you put a card in 802.11b(only), and another in 802.11g(only), the signals generated by the 'g' are not all necessarily picked up by the 'b' device (or vice versa for that matter) and reported as noise. So the noise figure you see is not necessarily the 'true' noise figure in any given spectrum. This is also true where selections have been made to 'narrow' the channel. One thing a lot of folks don't seem to remember is that even though a device is set at say a 10mhz channel span, the receiver STILL listens at the full channel span (20/40/60mhz), but only transmits at the desired channel span. So your claim that you have a 30db noise margin it not necessarily accurate - everyone understand?

All the above is covered in multiple threads - if you do a search of the forum you'll see several posts regarding multicast rates, basic vs selected rates, and the reasoning behind the selections in more depth than what I provided here. Do your home work first - that's most likely why you haven't seen any answers to your post.

Hope this helps.

Hi Thom, glad to see you back here...

All the above is covered in multiple threads - if you do a search of the forum you'll see several posts regarding multicast rates, basic vs selected rates, and the reasoning behind the selections in more depth than what I provided here. Do your home work first - that's most likely why you haven't seen any answers to your post.

True, but one of the problems nowadays with this forum is to filter the info you need and to decide which is use-able and which is definitely not.
I count 145.000 (!) posts in 23.000 topics in the 3 main chapters only! There is no sort of rating on the quality of posts made. (The "karma" rating is a nice attempt, hence your earned one ) To be honest it is quit confusing at times and replies sometimes raise more questions then it answers.

I believe basic wireless settings became a bit snowed under with all the new tasks and options available in MT-ROS. 'n´ protocol, improved nstreme, nv2, new cards (MT & 3rd party) many new ros versions with as many new bugs and new devices etc.,

But I believe it all starts with the basics. No matter how fancy all that new stuff looks, if the radio basics are not set to the best your link will never perform the way it can... hence I bring it up, maybe again, but to the benefit of many I hope.

Multicast = general router 'housekeeping' / networking tasks such as exchanging routing information. etc.

Ubiquiti - from what I read regarding their implementation, has allowed a departure from the standard and allows the 'user' (you) to select at what speed the Ubiquiti will attempt to exchange mulitcast information.

Basic rate - the rate at which all devices in a network expect to be able to communicate regardless of the circumstances (noise etc.) Typically this is the lowest rate at which the network can communicate. 802.11b = 1mbps, 802.11g = 6mbps, 802.11a=6mbps, etc.

In the 'standard' multicast communication scenario, the device uses the basic rate to exchange network information will all devices simultaneously in the case of an AP multicast broadcast for example, for devices attached to the AP they will respond with the basic rate unless otherwise specified (Ubiquiti - the departure from the standard).

So - as you can see multicast has really nothing to do with basic rates - it is a 'user' of the setting is all.

Ok, UBNT has the option to set multicast rate, which can be an off-standard option. Multicast communication in other AP's are done against the basic rate, which is in case of MT, also adjustable. UBNT doesn't even have an option to set a basic rate.
My humble conclusion would be both are one and the same, but obviously not. I am confused now.

With basic rates AP says what rates every device in network must support, it simply does not accept clients that do not support all basic rates.
supported rates - rates at which particular device can transmit/receive. Actual rate set used between two devices contains all rates that are in common in supported rates for both devices (and this set includes basic rates, of course). So basic rates can be considered a "filter" of who is allowed to connect. In this way e.g. "only-g" mode will set 6mbps as basic rate and this will not allow any 11b client to connect because he can not support 6mbps rate.

Rate used for multicast must be chosen from basic rates, because only basic rates are known to be supported by _all_ clients. Historically multicast rate is chosen as lowest basic rate for most robust transmission because there is no retry mechanism for multicast. 802.11 does not specify which particular rate to use for multicast, except it is clear that it must be one of basic rates. So lowest basic rate specifies the rate at which multicasts are transmitted.

Basic rates are not used for anything else, except two things mentioned above. Rate selection works only on set of rates that are in common between two devices and makes no distinction if the rate is basic or not - there is no such thing as "falling back to basic rate" - it wil only "fall back" as lowest common supported rate (which usually is one of basic rates).

Well, actually lowest basic rate is also used for management frames - this includes beacon frames (which are basically broadcast frames) sent by AP and management frames used during association. The reason why too high lowest basic rate may cause trouble maintaining connection could be the fact that successful delivery of broadcast beacon frames is essential for maintaining connection.

Some of the other things mentioned here like, my ccq rate drops even though I have 30db of noise margin, and other such comments.

Ok, after setting rates to 6, 12 and 18 (to cover all clients need and to have stable links) my CCQ's are all over the place. On idle links they drop completely but come up on busy links. But seldom I see any 100%'s any more. Let's say all ´busy´ links on almost all my AP's now linger between 65 - 95 %'s.

What other tools does operator now have to see if his link is performing well?
In normal 802.11a/b/g/n(?) Tx/Rx frames and Tx/Rx Hw-frames can be used to see how many packages get lost.
But with nv2 enabled on link this info doesn't exist any longer.
Here the only info we now have left is the connection rate stability and the CCQ. Both are now rather dynamic.

That noise level is only what the wireless device 'understands' as noise. If you put a card in 802.11b(only), and another in 802.11g(only), the signals generated by the 'g' are not all necessarily picked up by the 'b' device (or vice versa for that matter) and reported as noise. So the noise figure you see is not necessarily the 'true' noise figure in any given spectrum. This is also true where selections have been made to 'narrow' the channel. One thing a lot of folks don't seem to remember is that even though a device is set at say a 10mhz channel span, the receiver STILL listens at the full channel span (20/40/60mhz), but only transmits at the desired channel span. So your claim that you have a 30db noise margin it not necessarily accurate - everyone understand?

I understand the noise level readings. We can only use it as a rough guide. Unless you have an expensive spectrum analyser we have no idea what more goes around in our chosen frequency.
But listening at 20, 40 and 60Mhz??? Is this not arranged by the software? Would the choice for a transmit frequency and bandwidth not also set the receiver filters for the same bandwidth?
I presume the software also arrange to let only a channels centre frequency with bandwidth pass that belongs to the transmitting channel? Or is the receiver also getting to consume a neighbour's 5700Mhz frequency if its own transmitter is actually set to 5500Mhz? If the software is capable of doing such it should also capable of narrowing or widening the receiving filter? But maybe I expect too much now out of the cards we use..

60Mhz? Is this possible?

I understand the noise level readings. We can only use it as a rough guide. Unless you have an expensive spectrum analyser we have no idea what more goes around in our chosen frequency.
But listening at 20, 40 and 60Mhz??? Is this not arranged by the software? Would the choice for a transmit frequency and bandwidth not also set the receiver filters for the same bandwidth?

This the same question i have asked, but a spectrum analyzer is not of much use, unless it can be connected to a test point on the radio card from which using antenna "X" using radio card "Y" gives frequency responce of "V" in Tx mode and "W" in Rx mode,

Hi guys, can you solve my doubt about data rates?
I got 2 radios far about 400 meters.

Data rates on AP Metal RoS 6.30.4, 5GHz-A, channel width 20MHz:
Basic rates = 6Mbps
Supported rates = 6, 9, 12, 18

Client, RB433 RoS 6.19:
Basic rates = 6
Supported rates A/G = 6, 9, 12, 18

Sometimes on my AP I see in registration table: Rate 48 Mbps.

What's wrong?
Thanks.