cancel
Showing results for 
Search instead for 
Did you mean: 

Effect of rate-limiting on channel efficiency

joea_5029799
New Contributor II
Rate limiting each client increases the amount of time needed to complete data transfer (assuming the air-interface is not the bottleneck). Unless a scheduling method such as air-time fairness is used (where clients with good link quality are given a slight advantage), the result will be increased contention for the channel and more rapidly diminishing performance as the number of concurrent users increases. A "hog" will want to consume a lot of data whether rate-limited or not. How then does Ruckus recommend reducing the amount of time that hog is contending for channel access?

Note: This topic was created from a reply on the Rate Limiting topic.
6 REPLIES 6

billkish
New Contributor II
The buffering I mentioned is within the rate limiting and ATF scheduler implementation. Over the air we use the standard 802.11n A-MPDU aggregation mechanism so there is no interoperability issue.

I don't have any results showing the efficiency gain from bursty rate limiting in isolation but here is an analytical example.

Our ATF scheduler targets about 4ms of transmission time per station per transmission. Link access times of 500-1000 microseconds (or larger) are not uncommon in busy 2.4 GHz environments so lets assume 750 microseconds. This results in a MAC-layer 'efficiency' of 4 ms / (4 ms + 0.75 ms) = 84%.

Now assume that 4ms transmission contained 8 subframes. If we didn't buffer them up to send at once but instead metered them out individually then those same 8 frames would each have an 0.75 ms access time. Since the original 8 frame aggregate took 4ms each individual frame would take about 0.5 ms to send (this is a simplification ignoring ack time and other fixed overheads which are relatively small). So in this case the MAC-layer efficiency is 0.5 ms / (0.5 ms + 0.75 ms) = 40%.

So under these conditions we would expect a capacity speedup of (84/40) = 2.1x from a bursty rate-limiter compared to a naive rate limiter that tried to smooth the traffic!

joea_5029799
New Contributor II
Hi Bill. Your analytical explanation is very clear. Again, I thank you for taking time to respond personally to this inquiry.