AC1450 throughput

[rtrhelp]

I have a Netgear AC1450 router which has 3x3 2.4GHz antennas (450 Mbps) and 3x3 5GHz antennas (975 Mbps). My laptop has a builtin Intel AC8265 network adapter which has 2x2 5GHz antennas (867 Mbps).

However I am not getting a throughput of more than 160Mbps. I am testing the throughput by connecting a hard drive to the USB 3.0 port on the router and transferring a 1GB file (I tested that my 5400rpm hard drive is capable of transferring at 480 Mbps through the USB 3.0 adapter it is connected to).

I am currently using Netgear Firmware Version V1.0.0.8_1.0.4 on the router. I have a hunch that only one antenna is active at a time but I have no way to confirm. `netsh wlan show all` did not give me the information I am looking for. I am not sure whether the problem is with the router firmware (not the latest) or the network adapter driver (latest).

How can I debug this problem? 

Can someone provide a few pointers as to what could be wrong?

[schumaku · Accepted solution]

That's a different story. The http protocol overhead is not high indeed. However in general a http (and https enabled) tiny server with it's main job driving a Web user interface is ways off from being a fast provider for a file stream. Oh and then the big ones as well as the NAS vendors (well, some selected ones at least) providing lots of Web based services have silently migrated a lot of traffic away from the TCP stack to much more capable QUIC bringing lots of advantage. Needless to say - well possible the next http protocol will be no longer built on TCP.

As a side comment, also SAMBA has changed a lot, along with the changes Microsoft has introduced over the last two decades with SMB 2.1, SMB 3.0/3.1. Most embedded systems like these routers are stuck on technology from decade(s) back.

These tiny router systems have almost every disadvantage what the NAS industry has overcome in years of development: Poor SoC cores, low memory, very limited flash space for performance code - and last but not least plenty of legacy code (starting from crappy old kernels to the I/O system, no headroom for buffering, no caching capabilities).

Even the R9000 or XR700 (same platform) does not really fly on storae access. Even with SMB 3.0 protocol available. It's not a secret: A router is a router, and with a single USB connected you don't win anything in the storage competition - NAS with similar SoC are outperforming these router based storage servers by factors of ten and more - but this does require memory for buffering, ideally SSD caching, and many HDD distributing the I/O load.

Happy New Year!

[schumaku]

With 150 Mb/s you are well served. The router is built on a tiny dual-core 800 MHz ARM core. The overhead is coming from non-native file system (like NTFS or HFS+) handling, SAMBA (smbd) processing, ... the limits aren't on the various interfaces. 

Compare the SMB benchmarks, there is none available for the AC1450, but for the R7000 (similar SoC, but 1 * 1GHz clocked):

[rtrhelp]

Thanks for the reference. I was a bit surprised to find out that the overhead can be that drastic for a drive connected to the router's USB port. So I guess I will ditch the USB port on the router.

When I connected another drive using a system through the 1Gbps  ethernet port I was able to get a throughput of 435 Mbps. I was using a HTTP server for the file transfer test and again the same file of size 1GB. I still wonder where the overhead of 650-435 = 215 Mbps lies (given the 2x2 adapter, ideal throughput  should be 975*2/3 = 650 Mbps). It is hard to believe if that is coming from channel congestion. I made sure no other router was using the channel I selected. The distance between the router and the network adapter was less than a meter. Also I do not expect the HTTP protocol overhead to be that high. Any pointers to push the throughput higher or where the overhead is coming from?

[schumaku · Accepted solution]

That's a different story. The http protocol overhead is not high indeed. However in general a http (and https enabled) tiny server with it's main job driving a Web user interface is ways off from being a fast provider for a file stream. Oh and then the big ones as well as the NAS vendors (well, some selected ones at least) providing lots of Web based services have silently migrated a lot of traffic away from the TCP stack to much more capable QUIC bringing lots of advantage. Needless to say - well possible the next http protocol will be no longer built on TCP.

As a side comment, also SAMBA has changed a lot, along with the changes Microsoft has introduced over the last two decades with SMB 2.1, SMB 3.0/3.1. Most embedded systems like these routers are stuck on technology from decade(s) back.

These tiny router systems have almost every disadvantage what the NAS industry has overcome in years of development: Poor SoC cores, low memory, very limited flash space for performance code - and last but not least plenty of legacy code (starting from crappy old kernels to the I/O system, no headroom for buffering, no caching capabilities).

Even the R9000 or XR700 (same platform) does not really fly on storae access. Even with SMB 3.0 protocol available. It's not a secret: A router is a router, and with a single USB connected you don't win anything in the storage competition - NAS with similar SoC are outperforming these router based storage servers by factors of ten and more - but this does require memory for buffering, ideally SSD caching, and many HDD distributing the I/O load.

Happy New Year!

[rtrhelp]

Thanks for sharing this information. It is very revealing and useful.

Happy New Year to you as well.

If I manage to transfer files at a higher throughput, I will post it here for other's benefit.