What's new

Is upload bandwidth always lower than download one?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

negora

Occasional Visitor
Hello:

This is my first message here, so salutes to you all ;) .

I've a question with regard to the bandwidth of a wireless connection. I've a computer with an ASUS PCE-AC68 card (3x3:3). It's connected to an ASUS RT-AC68U router (3x3:3) using a wireless connection. I've another computer that is connected to the same router, but with an UTP cable.

I've used the "iperf3" application to measure the bandwidth between both computers. Both have Debian 9.3 installed. First, I've measured the download rate in the computer that is connected wirelessly. So I've run "iperf" in server mode in that machine, and I've run the same application, but in client mode, from the other computer. It has resulted ~240 Mbps.

After that, I've measured the upload rate from that same computer. It has resulted to be near the half of the download rate: ~110 Mbps.

I've repeated the tests several times. I've also made similar tests using a laptop with an Intel card (2x2:2) and an ASUS EA-AC87 access point(4x4:4) and the results have been, relatively, identical: always the upload rate was, approximately, the half of the download one.

Connecting both computers with UTP cables to the router I got the same rates for download and upload, so I discard that it has anything to do with the CPU power.

Why does it happen? Has it anything to do with the acknowledgement packages used in TCP? Or with the acknowledgement frames in the 802.11 standards? If that were the case, Don't the packages follow the same route in both cases (downloading and uploading) but in different direction?

Thank you.
 
No it is not normal in a switched LAN environment. Your various test results and test cases are not clear in your post. You stated there was no speed difference when using WiFi or wired...so then why did you ask if it was related to the 802.11 frames? If both clients are wired, 802.11 is not even in play. Also to note....do your initial testing via UDP to remove the additional overhead of TCP.

If you have speed differences on upload vs download when both ends of the connection are wired on the same switch:
- bad cabling
- CPU limits
- hardware limits
- software limits

Start with swapping out cables to see if there is any change in speeds.
 
Something is up - using iperf3 (MacOS 10.13.4 with Homebrew on MacBook Air) connecting to Ubuntu 16.04LTS (running on an Intel Braswell NUC). AP in play is an Airport Extreme AC, and confirmed that we're 2*2:2 with MCS9 (Tx Rate 867Mbps).

I get 541 down, 524 up... and pretty solid across the run...

Numbers below:

Code:
$ iperf3 -c 192.168.1.20 -Z
Connecting to host 192.168.1.20, port 5201
[  5] local 192.168.1.136 port 56528 connected to 192.168.1.20 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  65.9 MBytes   552 Mbits/sec                 
[  5]   1.00-2.00   sec  71.2 MBytes   598 Mbits/sec                 
[  5]   2.00-3.00   sec  70.9 MBytes   593 Mbits/sec                 
[  5]   3.00-4.00   sec  69.8 MBytes   587 Mbits/sec                 
[  5]   4.00-5.00   sec  50.1 MBytes   420 Mbits/sec                 
[  5]   5.00-6.00   sec  58.6 MBytes   492 Mbits/sec                 
[  5]   6.00-7.00   sec  59.2 MBytes   497 Mbits/sec                 
[  5]   7.00-8.00   sec  58.8 MBytes   494 Mbits/sec                 
[  5]   8.00-9.00   sec  59.4 MBytes   498 Mbits/sec                 
[  5]   9.00-10.00  sec  60.6 MBytes   508 Mbits/sec                 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec   625 MBytes   524 Mbits/sec                  sender
[  5]   0.00-10.00  sec   624 MBytes   523 Mbits/sec                  receiver

$ iperf3 -c 192.168.1.20 -Z -R
Connecting to host 192.168.1.20, port 5201
Reverse mode, remote host 192.168.1.20 is sending
[  5] local 192.168.1.136 port 56530 connected to 192.168.1.20 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  52.5 MBytes   440 Mbits/sec                 
[  5]   1.00-2.00   sec  57.3 MBytes   481 Mbits/sec                 
[  5]   2.00-3.00   sec  62.5 MBytes   524 Mbits/sec                 
[  5]   3.00-4.00   sec  67.3 MBytes   565 Mbits/sec                 
[  5]   4.00-5.00   sec  65.9 MBytes   553 Mbits/sec                 
[  5]   5.00-6.00   sec  68.1 MBytes   572 Mbits/sec                 
[  5]   6.00-7.00   sec  67.5 MBytes   566 Mbits/sec                 
[  5]   7.00-8.00   sec  67.0 MBytes   562 Mbits/sec                 
[  5]   8.00-9.00   sec  68.0 MBytes   570 Mbits/sec                 
[  5]   9.00-10.00  sec  67.3 MBytes   565 Mbits/sec                 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   645 MBytes   541 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   644 MBytes   541 Mbits/sec                  receiver
 
Last edited:
No it is not normal in a switched LAN environment. Your various test results and test cases are not clear in your post. You stated there was no speed difference when using WiFi or wired...so then why did you ask if it was related to the 802.11 frames?

I guess that you're referring to this statement: "Connecting both computers with UTP cables to the router I got the same rates for download and upload, so I discard that it has anything to do with the CPU power." I'm sorry, but I was very ambiguous there (or I expressed myself wrong). Really I meant that, when using a cable, the download rate was the same (equal to) to the upload rate.

In other words, these computers behave well when connected with an UTP cable to the router. The download rate equals the upload rate. But, when using WiFi, the upload rate is lower than the download rate by a wide margin. No matter if I connect the computer A to the RT-AC68U or the EA-AC87.

sfx2000 said:

Thank you for showing me the options that you use with IPerf3. I've used them for my new tests. I didn't know about the -R (--reverse) option. I was using the server mode in one computer first, and then in the other computer.

NEW TESTS

I've re-run the tests using the --reverse option when needed. I've used another computer too (the games computer). First, with this setup:

Desktop computer: with ASUS PCE-AC68U
Games computer: with cable
Router: ASUS RT-AC68U

Rate from desktop to games (wireless): 88.00 Mbps.
Rate from games to desktop (cable): 264.00 Mbps.


Another setup:

Laptop computer: with Intel Dual Band Wireless-AC 8265
Games computer: with cable
Router: ASUS RT-AC68U

Rate from laptop to games (wireless): 286.00 Mbps.
Rate from games to laptop (cable): 344.00 Mbps.


Last setup:

Desktop computer: with ASUS PCE-AC68U
Laptop computer: with Intel Dual Band Wireless-AC 8265
Router: wireless with ASUS RT-AC68U

Rate from laptop to desktop (wireless): 103.00 Mbps.
Rate from desktop to laptop (wireless): 30.70 Mbps.


The difference between the download and upload rates is huge in the case of the PCE-AC68U. In the case of the 8265 it's not so big, but it's still significant.

I've made sure that the router has the QoS disabled, just in case. I've also enabled and disabled the WMM feature. But the results have been similar in both situations.

This time I've taken the EA-AC87 out of the equation but, in past tests, the results were similar.
 
half duplex on the transmission from the client ?

Sorry, but I expressed myself wrong. I meant that, when using cables, the download rate equalled the upload rate. So there are not problems with that. Thanks.
 
With the major difference being on the PCE-AC68U, I would say you either have a driver or hardware issue with that piece of equipment. Your speeds with the Intel WiFi look normal.
 
MichaelCG said:
With the major difference being on the PCE-AC68U, I would say you either have a driver or hardware issue with that piece of equipment. Your speeds with the Intel WiFi look normal.

Well, the rates asymmetry with the Intel card increases a lot according to the distance from the router. Right now, I'm doing another test between the laptop (Intel) and the games computer (cable). This time the laptop is in the same location where the desktop computer is located (and away from the router). What are the results? Download: 205 Mbps. Upload: 79.5 Mbps. It's the same behaviour seen with the desktop computer, as you can see. So it doesn't seem to be a drivers issue.

The games computer has Windows installed, instead of Debian. But it can't be the cause, because the same behaviour appears when making the tests only with the Debian computers. In addition, the tests made only with cables look OK (perfectly symmetric). So I also discard problems of the CPU power.

Here is another test with surprising results. I've connected the EA-AC87 to the router with an UTP cable. This AP is in the same room that the desktop computer and the laptop. I've disassociated them from the router wireless network and linked them to this AP's. When I test the rates between the desktop computer and the games computer, these are the results: Download: 280 Mbps. Upload: 145 Mbps. Just half of the speed. What about the laptop and the games computer? Download: 392 Mbps. Upload: 280 Mbps. Here the loss is smaller. But it surprises me, because the AP is just in front of both computers, 2 meters away. The differences between the download and upload rates (in the same computer) shouldn't be so high, Right?

Seriously, I can't believe that I've the same issue with ALL my devices :S . Is my apartment built over an old graveyard? Ha ha ha.

degrub said:
any buffering issues on the wifi side since they are going through different adapters ?

No idea. I'm still trying to find out the reason :S .
 
I've been reading some comments on the Internet, and it seems that the bandwidth asymmetry is not so uncommon, even in 2x2 and 3x3 wireless cards. It seems that some technologies used to improve the throughput are applied only on the downstream flow.

I've continued doing tests. I've put the laptop close to the router, and I've got almost symmetric rates. While I moved the laptop away from the router, the asymmetry has started to grow. It has also happened when using the EA-AC87 as access point. But anyway, the laptop rates seem to be decent for a 2x2:2 device (just as you, MichaelCG, said).

But the PCE-AC68 is a another story... I've connected the EA-AC87 access point to the router with an UTP cable. Then, I've put the AP in front of the PCE-AC68 (1 meter away). The throughput against the games computer has been this: Download: 374 Mbps. Upload: 158 Mbps. Doing the same experiment with the laptop: Download: 402 Mbps. Upload: 392 Mbps. Something is wrong with the PCE-AC68, definitively. It's not normal that a 2x2 device beats a 3x3 device for such a wide margin, Right?

I've tested the PCE-AC68 with Debian 9.3 + KDE, Ubuntu Mate 17.10 (to make sure that KDE were not affecting the power saving) and also the latest Manjaro KDE 17.1.5. Same results with all them :/ .
 
the challenge the PCE-AC68 - it can be noise limited depending on the machine it's installed in - this is intrinsic with all PCI-e cards that can be installed in a desktop PC. If I recall correctly - at least some of the PCE-AC68 kits include a remote antenna base - and if present, it should be used, as it gets the antennae into a better place as opposed to three dipoles right up against a sheetmetal back of a PC.
 
Laptop computer: with Intel Dual Band Wireless-AC 8265
Games computer: with cable
Router: ASUS RT-AC68U

Rate from laptop to games (wireless): 286.00 Mbps.
Rate from games to laptop (cable): 344.00 Mbps.

Yeah, I can see a bit of asymmetry with the 8265... new box, Intel NUC7i5 running Ubuntu 17.10...

Code:
sfx@nuc7:~$ iperf3 -c 192.168.1.20 -Z
Connecting to host 192.168.1.20, port 5201
[  4] local 192.168.1.141 port 41756 connected to 192.168.1.20 port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   405 MBytes   339 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   401 MBytes   336 Mbits/sec                  receiver

sfx@nuc7:~$ iperf3 -c 192.168.1.20 -Z -R
Connecting to host 192.168.1.20, port 5201
Reverse mode, remote host 192.168.1.20 is sending
[  4] local 192.168.1.141 port 41760 connected to 192.168.1.20 port 5201
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   708 MBytes   594 Mbits/sec  489             sender
[  4]   0.00-10.00  sec   707 MBytes   593 Mbits/sec                  receiver

Fun with UDP...
Code:
sfx@nuc7:~$ iperf3 -c 192.168.1.20 -u -i l -b 1000M -Z
Connecting to host 192.168.1.20, port 5201
[  4] local 192.168.1.141 port 55212 connected to 192.168.1.20 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-10.00  sec   523 MBytes   439 Mbits/sec  66952 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   523 MBytes   439 Mbits/sec  0.088 ms  2/66952 (0.003%) 
[  4] Sent 66952 datagrams

sfx@nuc7:~$ iperf3 -c 192.168.1.20 -u -i l -b 1000M -Z -R
Connecting to host 192.168.1.20, port 5201
Reverse mode, remote host 192.168.1.20 is sending
[  4] local 192.168.1.141 port 58499 connected to 192.168.1.20 port 5201
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   134 MBytes   112 Mbits/sec  16.973 ms  53575/70731 (76%) 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.12 GBytes   958 Mbits/sec  16.973 ms  53575/70731 (76%) 
[  4] Sent 70731 datagrams
 
Last edited:
Yeah, I can see a bit of asymmetry with the 8265... new box, Intel NUC7i5 running Ubuntu 17.10...

Same UDP test over the wire...

Code:
sfx@nuc7:~$ iperf3 -c 192.168.1.20 -u -i l -b 1000M -Z
Connecting to host 192.168.1.20, port 5201
[  4] local 192.168.1.139 port 35493 connected to 192.168.1.20 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec  143601  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec  0.045 ms  315/143601 (0.22%)  
[  4] Sent 143601 datagrams

iperf Done.

sfx@nuc7:~$ iperf3 -c 192.168.1.20 -u -i l -b 1000M -Z -R
Connecting to host 192.168.1.20, port 5201
Reverse mode, remote host 192.168.1.20 is sending
[  4] local 192.168.1.139 port 36747 connected to 192.168.1.20 port 5201
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.11 GBytes   952 Mbits/sec  0.093 ms  0/145303 (0%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.11 GBytes   952 Mbits/sec  0.082 ms  0/145310 (0%)  
[  4] Sent 145310 datagrams

iperf Done.
 
the challenge the PCE-AC68 - it can be noise limited depending on the machine it's installed in - this is intrinsic with all PCI-e cards that can be installed in a desktop PC. If I recall correctly - at least some of the PCE-AC68 kits include a remote antenna base - and if present, it should be used, as it gets the antennae into a better place as opposed to three dipoles right up against a sheetmetal back of a PC.

Thanks for sharing your tests. They're giving me some interesting clues about IPerf3 ;) .

The PCE-AC68 is connected to a triple external antenna that came bundled with the card. There's a cord of ~1 meter between the card and the antenna. So such antenna is away from the computer case.

Right now, for testing purposes, there is also ~1 meter between the antenna and the AP (the EA-AC87). I've tried placing the AP a little further (2-3 meters) but the results are almost the same.

In my case, using UDP for the tests, I obtain 943 Mbps. on download and 319 Mbps. on upload. Does it mean that the link between the card and the AP is OK (there are almost no interferences)? I guess so, or otherwise, the download bandwidth would be lower, Right? The ratio of lost datagrams on download is ~30%.

On the other hand, the tests with TCP continue as mediocre as always. 310 Mbps. on download and 180 Mbps. on upload. Very poor results for a 3x3:3 card :S . But taking the UDP results into account, I guess that it's something specific of TCP, Right?

There are at least 2 other tests that I want to do. One is taking the RT-AC68U router to this room and put it close enough to the PCE-AC68U. And then test the bandwidth. Simply to make sure that it's not an issue between the EA-AC87 and the PCE-AC68. The other test is testing the desktop computer with Windows running on it. To discard that it's an issue specific of the Linux driver.

By the way, while I was testing, I've realized about 2 issues. The first one is that he EA-AC87 doesn't let me change the channel width. It's set to "Auto" and I can't change it. In my RT-AC68 I can set it to 20, 40 or 80 MHz. But here it's locked :S . The device also lacks of firmware updates (only 2 in all these years; incredible).

The other issue is about the PCE-AC68. It can't see other channels over 48. I've read that it may be because of the European regulations :S . The thread PCE-AC66 wifi card not picking up 5ghz 149-161 channels explains how to change the region in Windows. In Linux, I've done something equivalent (or that's what I believe), using the command "iw reg set US". But it has no effect either. Anyway, better not to divert from the original topic of the thread.
 
I think these tests by @maxbraketorque offer an interesting dimension ...

Thank you for that information. That corroborates the hypothesis that the download and upload bandwidths are asymmetric. Specially within long distances. In the case of the RT-AC68U, indeed, it seems that it does much worse than newer routers :S .

Test of the PCE-AC68 and the RT-AC68U being near each other.

This morning I've decided to move the desktop computer to the room where the router is located. It weights a lot, but it was easier to disconnect it than the router (there is less clutter of cables).

I've placed the computer 1 meter away, approximately, from the router. The results have cleared all by doubts: 336 Mbps. on download, 124 Mbps. on upload. It's frustrating :/ .

I've made this test just to dismiss that it was an issue specific of the PCE-AC68 with the EA-AC87.

Conclusion.

Something happens with the PCE-AC68. The results are poor with both the RT-AC68U and the EA-AC87 (although the overall throughput of the RT doesn't help either). Now there is only one test left to do: test it with Windows instead of Linux. If that works fine, it's a driver issue. If that works bad too, either it's a defective unit, or this model is very limited.

But the latter seems not to be probable, because I've read 4-5 reviews, in which people seems to get a download bandwidth of ~500 Mbps. and upload bandwidth of ~300 Mbps (within short distances). Very far from my poor figures :/ .
 
Last edited:
I guess my reading comprehension skills are lacking. When I first read your thread I thought the issue was that your upload speeds were half your download speeds. The @maxbraketorque tests suggested asymmetrical speeds for a large file transfer and symmetrical speeds for multi-file transfers. I thought that was note worthy.

Edit: Sorry, I said that backwards. As one would expect the large file was faster and ... it was the large file that was symmetric.

Your latest post makes it clear that you are also frustrated with overall speeds and even though your overweight desktop was faster it's still not as fast as you had hoped for? If it's any consolation maxbraketorque's speeds are akin to yours.

So I checked the thiggins' review on the AC68U. His test suite (ASUS PCE-66U AC1750 PCIe adapter, channel width of 80 MHz, etc.) showed peak speeds of 400 Mbps (compared to your desktop @ 336) but he did not achieve 500 Mbps. (His results were symmetrical however.)

Uh, good luck ...
 
Last edited:
I don't think that it's your skills fault, but my mix of several issues in a single thread :p . The fact of not being a native English speaker hasn't helped either. Apologizes for this mess.

Here it's a summary:

My first problem was asymmetry. I wanted to know if it was something common to wireless connections or an issue with my devices. The tests made by @sfx2000 and others confirmed to me that it was something common. In addition to that, I also read, in some articles, that wireless connections tend to be asymmetric because some technologies to improve the range and throughput are applied only on downloads, not on uploads. So I consider that doubt solved ;) .

The other problem was the bandwidth of my PCE-AC68. In addition to being very asymmetric, the figures were low even within short distances. My opinion was based on the results obtained by other people in several reviews and forums. For example, when I put the PCE-AC68 one meter away from the EA-AC87, I expected ~480 Mb/sec. on download, and ~300 Mb/sec. on upload. But I got 336 Mb/sec. on download and 124 Mb/sec. on upload. The download was not so bad, but the upload was very poor. This morning, I've confirmed this suspicion (read the latest test below).

With regard to the @maxbraketorque results, I put my attention on the transfers of a single file because that tests are the most similar to the synthetic tests that I made with IPerf3. This application works with data in memory (except if you indicate the opposite), whereas @maxbraketorque used files on disk. This means that his tests were affected by more variables, specially the disk throughput, the file system, the fragmentation of that files, etc. Although he used an SSD, RAM is still much faster. That variables influenced the results even more when he transferred multiple files.

Don't get me wrong. His tests are perfect. They're more realistic than mine indeed. But that details prevent me from comparing his results directly against mine. It's just that.

With respect to the symmetry in his tests (for multiple files), I still can see asymmetry. Don't you? For example, in the 2.4 GHz band, short distance, the upload bandwidth was 65% of the download's (7,103 / 10,766 * 100). In the 5.2 GHz band, it was 48% (9,704 / 20,087 * 100). In the 2.4 GHz band, long distance, it was also 48% of the download's.


Test of the PCE-AC68 (with Windows drivers) and the EA-AC87

The test made this morning has been of great help. I've decided to download an ISO of Windows 10 from the Microsoft website and burn a live system in an USB hard disk (using WinToUSB). Then, I've boot the desktop computer with it, I've installed the drivers from the ASUS website, I've run IPerf3 and... Bingo! I've got 440 Mb/sec on download, and 392 Mb/sec on upload! These results are closer to what I've seen in others' benchmarks.

This means that the problem is in the Linux drivers for the PCE-AC68, definitively :) .
 
With respect to the symmetry in his tests (for multiple files), I still can see asymmetry. Don't you? For example, in the 2.4 GHz band, short distance, the upload bandwidth was 65% of the download's (7,103 / 10,766 * 100). In the 5.2 GHz band, it was 48% (9,704 / 20,087 * 100). In the 2.4 GHz band, long distance, it was also 48% of the download's.
Since most of your conversation centered around 5GHz with an AC68U I was intrigued with his corresponding test showing even greater upload speeds than download close range, large file. Sorry, I said that backwards in my earlier post!
The test made this morning has been of great help. I've decided to download an ISO of Windows 10 from the Microsoft website and burn a live system in an USB hard disk (using WinToUSB). Then, I've boot the desktop computer with it, I've installed the drivers from the ASUS website, I've run IPerf3 and... Bingo! I've got 440 Mb/sec on download, and 392 Mb/sec on upload! These results are closer to what I've seen in others' benchmarks. This means that the problem is in the Linux drivers for the PCE-AC68, definitively
Awesome! You are truly tenacious ...
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top