I have had now and then occasional problems with mikrotik wireless when setting them up for indoor use. I usually do setup the data-rate of the AP max to 24Mbps because a laptop or cell phone is never going to use any more than 12Mbps I believe. In this cases I do encounter problems from time to time, but never bothered that much because I turned data-rate to default after that.
Today I had again this problem. While my Galaxy S3 phone connects with no problem when I select data-rates, a laptop with a broadcom 802.11g card couldn’t. I had to switch back to default data-rates in order to connect it. It seems that AP and client are not capable to synch between each other.
Is there any way to solve this (a part from switching back to default data-rates)? I prefer to use selective data-rates for performance optimization. I don’t want the AP to connect at 54Mbps, or higher for n protocol, while it is never going to be used.
The wireless data-rate is not a good way to control speed in your network. If you want to limit the speed of one or more of the wireless devices then you would be much better off using queues.
Communication at lower data rates means slower communication but it doesn’t use fewer resources, in fact it uses much much more in the way of resources.
I think the example of a freeway is a great way to see the difference of what is going on.
Limiting data rates is like closing down a lane on a freeway. The traffic is slowed down on the device but the entire freeway is slowed down as well. With queuing its more like putting a stop light on the entrance ramp… The freeway is flowing fast but your limiting the influx of traffic to the freeway.
When you communicate at lower data rates what your actually doing is sending less data per transmission but you are not using less time to send that data. Furthermore if your device has a fixed amount of data to communicate then it will be chattering with less dense data over wireless for a longer duration of time (hence much much more rather then just much more).
The wireless signal still takes the same time to fly through the air (like having a larger flashlight won’t change the speed of light just the amount of light during the same duration of time). It’s like the difference of printing a book out on paper with 10 point font or 78 point font. The pages still come out of the printer at the same rate but it will take a whole lot longer for the printer to print the 78 point font because you have fewer words per page. However if your eyes are not very good then you’ll need larger then 10 point font which is why wireless is designed to modulate down… having a week signal requires less dense data in order to make since of the data after the signal has had a fair amount of loss. The use of lower data rates is to have more reliable communication over links with less discernible difference between the signal and noise… lower data rates are not for speed control.
The bottom line is that your wireless device is using more wireless resources by communicating at lower rates. If you want to minimize the resources utilized by the device then use the highest modulation (most data per second transport) that the devices can support. If want to slow the data usage down on a device so that it leaves more resources for other devices then use queues to limit the throughput of that device.
For standard indoor wireless I would highly recommend using the default data rates which automatically negotiate the maximum data rate. If you are doing some type of long distance low data communication or some other specialized use then you may need to have the link engineered for best performance which may involve lowering data rates.
If your wanting better quality of service then I would recommend prioritizing traffic based on traffic rather then device.
I have three MikroTik access points in my home & business and a wireless backhaul between them… I don’t use custom data rates on any of them. I also don’t differentiate between devices or how they connect to my network. I have excellent results including running VoIP across my network. I am identifying my traffic and prioritizing important traffic on the network.
I see what you are saying, but what I meant by performance was referring to the fact that low data-rates has better link stability. The AP does not need to synchronize to 54Mbps, then drop to 48 and then to 36 and then to 54 and so on. You can even see the better performance by looking at CCQ. This is common behavior on crowded wireless environment. On the other hand we are talking about casual customer connecting for emails, webpages and maybe some youtube videos. So they will never peak 6Mbps of data I think, which can translate roughly in 12Mbps data rate over air. To continue your example about freeway, this is about how much lanes are you going to build for a given traffic, this is not about limiting traffic. If you think that two lanes are going to be more than sufficient for given traffic, I doubt you will build a freeway with four lanes.
Any way, I was more looking for an answer to the synchronization issue when on the AP is selected a given data rate. Is it an issue of the AP or of the client machine?
Rate flapping can be in issue but I haven’t found it to be a problem with recent releases of RouterOS. For fixed outdoor installations we run NV2 and have found the rates to be very stable and we do not limit the rate selections at all. For standard in-home we use 802.11n and also don’t limit modulations.
Another thing you may want to consider is that until you get into MCS 8-15 you cannot take advantage of the information as received across multiple paths. One solution to this is to leave the higher modulations but to unselect some middle modulations so that a link that won’t run fully modulated won’t step down the whole chain but will make a larger hop down to a modulation that will work.
The CCQ will improve when your percentage of successfully transmitted packets increases so it would naturally increase as you reduced rate flapping. The bigger question is if you are increasing or decreasing the throughput of the access point as a whole.