I'm trying to solve a problem I get on AP370 with download and upload bandwidth. When client is connected to WiFi, it gets 10-20 Mbps download speed and 70 Mbps upload. The same client gets 65-70 Mbps download speed when connected via cable. I can't find the reason why download speed is so low. I hope you can advise me what I can do to improve it. Here is what I checked so far and what set up I have:
AP170 with HiveOS 6.0r2f.
There is only 1 client connected - details attached
- 100Mbps Internet connection
- Access point is connected to FastEthernet switch port with full duplex
- client is close to AP
I tried so far:
- switch channels
- disable low data rates
- lower max transmit power
- disable/enable WMM on SSID
- change WMM QoS values on radio profile
- change user profile
- upgrade HiveOS from 6.0r2d to 6.0r2f
Unfortunately I can't get noticeable improvement of download speed. I appreciate your help in this case.
On the AP side of things, make sure that you update to 6.5r2:
It's difficult to say with the information available, but the behaviour you describe could just be the result of the way the TCP protocol works.
If you have a situation where there is packet loss between the client and the server, which is of course quite likely when going over the Internet, then there is a potential impact on the "goodput" (the USEABLE throughput) for TCP-based applications, as even a small amount of packet loss results in the need to retransmit up to the entire TCP window. These retransmissions effectively mean that you are "wasting" a lot of bandwidth resending, possibly multiple times, the same data. TCP's design tries to counter this by dynamically changing the size of the TCP window to minimise the amount of data that has to be retransmitted in the event of packet loss occurring. Unfortunately, the side-effect of this is that a smaller amount of data can be sent before the transmitter has to stop and wait for a TCP acknowledgement from the other end. If the latency between the client and server is quite high, waiting for ACKs ALSO reduces (potentially significantly) the throughput. In most circumstances, things balance up and you end up being able to achieve somewhere fairly close to the theoretical maximum throughput of your links, but if the levels of packet loss are high, or if the packet loss is the result of phenomena like "tail drop" which can occur in some network switches and routers that have a very simplistic approach to traffic queuing and policing, it's even possible for "goodput" to drop significantly, even down to zero.
This scenario can also lead to an asymmetry in upload/download performance, as very often packet loss is seen in one direction only.
So what you describe is consistent with this behaviour. If there is little or no packet loss between your wireless client and the LAN, you would not see a problem because the TCP window size can be kept large (if using iperf, you can see the results of applying different TCP window sizes using the -w parameter). From your LAN out to the Internet, even though there might be some packet loss, the latency might be sufficiently low for the delay due to having to acknowledge more frequently might not be noticable. But from the wireless LAN to the Internet, the extra packet loss and delay inherent to wireless LAN (caused by collisions, media contention, variable data rates and the half-duplex nature of wireless LAN etc.) can result in this kind of behaviour.
The best way to investigate is with a packet capture. This will not only show you whether you are seeing packet loss and retransmission occurring, but also allows you to inspect how the client is adjusting the TCP window size. Wireshark includes a number of tools in its to help you analyse this in its Statistics menu (filter the capture down to the individual TCP stream, and then the TCP StreamGraph submenu becomes available).
I obviously can't say for definite this is what is occurring here, but it would be one of the first things I would look at if I were in your shoes.
One thing I would say is that if you are connecting your AP170 at only 100Mbps, then you are introducing another potential source for packets to be dropped, as the wired-side capacity is much smaller than the wireless-side capacity. While the AP will queue traffic from the wireless side on its Ethernet port, there is only a finite amount of buffer available and the AP isn't optimised to buffer in this direction - you would be much better off if the AP were connected at gigabit and allow the buffering to occur downstream in the network. I appreciate this may not be an option with the equipment you have available.
Hope this is of some help!
That's what I started to do. I have changed the access point to AP330 to make sure it is healthy. I captured traffic on wifi client during bandwidth test. There are a lot of [TCP Dup ACK] packets during download part, for upload there are only few. Latency shown in the test is fine (0,027 sec). During this test I got 20Mbps download and 64 upload.
Here you can see what I captured. Is it possible to determine what is the culprit? Access point or router.
Source PC IP (wifi client): 10.67.32.161
Destination IP: 18.104.22.168
I updated to 6.5r2 both HiveManager and access points. Still the same issue.
Many [TCP Dup ACK] packets are proof that packets are lost. I have checked all ports on LAN side from access point to the router. There are no dropped packets except access point interface wifi1.1.