Widely fluctuating Tx Rates
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
I run several of these, hardwired cat6 and with a controller. Fantastic kit
Curious about Tx Rates as reported on Macbook Pro's and also iMacs connected wirelessesly.
Firstly the MBP's report wildely fluctuating speeds. 527Mbps all the way up to 1027Mbps. They keep jumping all over the place. At around 15-20 feet.
iMac within 5 feet of 1 EAP245 wouldn't connect higher than about 870Mbps.
I thought this was odd, in both cases.
Putting an Airport Extreme in the same position, the iMac locked on at 1,300Mbps and stayed there. The MBP again at 15 - 20 feet connected at a higher speed and stayed there.
Is there a reason or a setting that is preventing these apple devices from not connecting faster?
To confirm, the test between devices was always performed on the same 5ghz channel, same locations (in both cases).
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
bp1000 wrote
Firstly the MBP's report wildely fluctuating speeds. 527Mbps all the way up to 1027Mbps. They keep jumping all over the place. At around 15-20 feet.
iMac within 5 feet of 1 EAP245 wouldn't connect higher than about 870Mbps.
I thought this was odd, in both cases.
Putting an Airport Extreme in the same position, the iMac locked on at 1,300Mbps and stayed there. The MBP again at 15 - 20 feet connected at a higher speed and stayed there.
If there is a large fluctuation in the wireless rate, I think it is related to the wireless environment. Try to change the channel width and Tx Power, it may be useful for you.
Besides, we recommend you to test the speed by using speedtest. Refer to: https://www.speedtest.net/
- Copy Link
- Report Inappropriate Content
@bp1000 That looks like the iMac only used 2 antennas (2x433)
Have you measured actual speeds with something like iperf?
- Copy Link
- Report Inappropriate Content
Thank you for your input
It was indeed power / channel related.
I'm using 80mhz channels and i found that one of the AP's was introducing interferance.
What i have is 3 floors in a building, AP on each floor, fairly central but in a zigzagg formation.
Floor 1: Channel 36
Floor 2: Channel 52
Floor 3: Channel 36 (again, as i find channel 100 doesnt play nice with some devices, not sure why, think its U.S. limits on chipsets even though i'm in Europe)
Floor 3 for interferring, i've turned down the power and i think its working out.
Results with iperf are
Ethernet to wifi client: 630Mbps
Wifi client to Ethernet: 770Mbps peak!
Previously it was struggling to exceed 250-280Mbps, and i suppose i was wrongly focussing on the Tx Rate.
I'm impressed.
2 final questions
With 80mhz i need to use non-overlapping and 52 (DFS) is the next non-overlap. But i find new clients unknown to the network take an age to connect to 52-DFS. They will connect on 2.4-n and take nearly 5 mins to switch. But once they do, i believe they stay sticky to 52-DFS on future re-connects and connect immediately, is this correct?
I'm still playing with power outputs from the APs. Roaming is not magic and is client based and a load balancing RSSI threshold disconnect is not good practice for this enviroment. So i have 2 options, high power on 5ghz or low power. However, the results are
High power
Fastest speeds by quite some margin
But stubborn to swap AP's when users roam
Low power
Lower speeds
Still not keen to swap AP's but they do swap faster
Occasionally swap to n first and then eventually back to a different 5ghz AP
Potential for VOIP disconnects as AP's swicth
Any best practices to smooth roaming between AP'?? I'm keen to stick with high power for max speed as they are non-overlapping but does anyone have some guidance here?
- Copy Link
- Report Inappropriate Content
bp1000 wrote
Any best practices to smooth roaming between AP'?? I'm keen to stick with high power for max speed as they are non-overlapping but does anyone have some guidance here?
You can use seamless roaming according to 802.11k/v if your clients support this (EAP245 V3 supports seamless roaming according to the datasheet).
Another way to force AP hand-over for non 802.11k/v-capable clients is to set the RSSI threshold of the EAP (see »Load Balancing« settings). This is not seamless roaming, but at least you can force a disconnect in the client if the signal level reaches a certain threshold which otherwise is determined solely by the client.
A side node: While iperf is a great tool to determine the maximum throughput over WiFi (speed of electromagnetic waves remains always the same), most applications will not make full use of this throughput in everyday use.
Of course a better throughput helps to minimize radio airtime and greatly improves the overall experience, but I would not be nitpicking about this. So, in my opinion lowering Tx power still remains an option if the EAPs are mounted to near to each other.
- Copy Link
- Report Inappropriate Content
Thank you. I have fast roaming enabled, but not many devices on the network use this feature. I tried to control it with power levels with mixed success and the RSSI threshold disconnect isn't ideal really. Firstly it would interrupt VOIP users and video confrenecing if they happen to be moving or in fringe areas, and when it cuts off, it has a habbit of connecting to n, taking a few minutes to switch to ac even though band steering is enabled. I do appreciate roaming has been a long time discussion with no magic results. A controller can monitor link quality and try to deal with it, but ultimately with the wifi standards we have, its mostly down to the client and you cant have the perfect setup.
I did some tests with iperf3 too - i'm very impressed with this equipment actually.
wifi to ethernet
Connecting to host 192.168.1.113, port 5201
[ 5] local 192.168.1.107 port 55706 connected to 192.168.1.113 port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1009 MBytes 846 Mbits/sec sender
[ 5] 0.00-10.01 sec 1008 MBytes 845 Mbits/sec receiver
ethernet to wifi
Accepted connection from 192.168.1.113, port 55596
[ 5] local 192.168.1.107 port 5201 connected to 192.168.1.113 port 55597
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 767 MBytes 643 Mbits/sec receiver
wifi to wifi - same AP
Connecting to host 192.168.1.113, port 5201
[ 5] local 192.168.1.122 port 55846 connected to 192.168.1.113 port 5201
[ ID] Interval Transfer Bitrate
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 496 MBytes 416 Mbits/sec sender
[ 5] 0.00-10.01 sec 495 MBytes 415 Mbits/sec receiver
wifi to wifi - different AP
Connecting to host 192.168.1.113, port 5201
[ 5] local 192.168.1.122 port 55941 connected to 192.168.1.113 port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 619 MBytes 520 Mbits/sec sender
[ 5] 0.00-10.00 sec 619 MBytes 519 Mbits/sec receiver
- Copy Link
- Report Inappropriate Content
bp1000 wrote
Firstly it would interrupt VOIP users and video confrenecing if they happen to be moving or in fringe areas, and when it cuts off, it has a habbit of connecting to n, taking a few minutes to switch to ac even though band steering is enabled.
You mean 2.4 GHz with n-mode? Or 5 GHz n-mode?
To avoid 5 GHz → 2.4 GHz → 5 GHz transitions I would reserve a separate SSID in the 5 GHz band exclusively for VoIP/video conferences.
An alternative would be to separate both frequencey bands by using different SSIDs. Then you would have no band-steering anymore, but if your preference is to be able to move between APs while having a video conference you have to make a compromise and let users choose the right band for their device for themself.
OTOH, reducing channel bandwidth to 40 or 20 MHz could probably improve transitions (depends on your environment and other parameters), but at the price of throughput. You just can't have it all over a shared medium such as WiFi.
A controller can monitor link quality and try to deal with it, but ultimately with the wifi standards we have, its mostly down to the client and you cant have the perfect setup.
That's the point: it's left to the client. Seamless roaming tries to make it easier for the client to find the best AP nearby without having to perform another WiFi survey and by supplying the client with a list of suitable APs, but it is still left to the client to connect to the other AP. Even if the client is forced to change the AP, it's completely up to the client to do so. Because WiFi signals are pulsed, connecting to another AP takes some time.
Compare this with a DECT phone, where a voice call's quaility can be degraded or even the call be interrupted if you walk around while connected to the same base station. Easy solution: don't walk around while talking on the phone. :-)
- Copy Link
- Report Inappropriate Content
Thanks, very informative. I agree about trying to find the middle ground. It is probably best that i try to set something up with the least amount of user input or config. Users are always the weak point.
I did run a small trial with 40Mhz but i think ultimately i think i'm trying to overwork the solution.
My AP's are probably a touch too close together but i think the best config for them is to 100% ensure there are no overlapping channels or interferance. Typically it goes 36 - 52 - 36 - 52.
I just need to make sure the power output of a channel 36 AP does not reach the next channel 36 AP (there would be a 52 inbetween them). I've found that people who initiate a connection within the range of any AP always seem to connect to their closest AP. When they move, the power is such that they can maintain a signal for a while, even when moving into range of the next AP. Only if they sleep their device does it connect to the strongest point.
I'm happy with that because all methods to force a reconnect is interruptive to work and the AP's and power is setup in such a way that its fairly rare to find yourself with less than 110Mbps and walking out of range to force a reconnect is quite a long way to go.
Still, fascinating kit this stuff is.
p.s. yes i mean't 2.4ghz-n
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 2483
Replies: 7
Voters 0
No one has voted for it yet.