What's new

Netgear P9000 or ASUS RT-AC86U

  • 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!

Geraner

Regular Contributor
Hi,

Anyone knows about the CPU performance difference between the folowing two routers?

How so they perform when it comes to VPN Client speed?
Any references?

If I remember right, the OpenVPN process can't take advantage of more than 1 CPU core. So the Netgear having a QuadCore processor should not be an advantage here. Compared the Asus has a 1.8 GHz instead of 1,7 GHz CPU. But both are two different CPU vendors / types.

Advantage with the Netgear would be that it is DD-WRT compatible.

Anyone who has some CPU comparison values? Moste interested when it comes to OpenVPN client speed.

/Geraner
 
The Cortex A15 in the R9000 is a “High Power” Core and does like 3.5 Dmips/MHz and the Cortex A53 in the 86U is a next gen “Low Power” that can do around 2.3 Dmips/MHz. The A57 is the true successor to the A15 generation wise and the A53 is a successor to the A7 in a way.

Having said that the hardware crypto acceleration in the AC86U is much better than the one in the R9000 so for VPN purposes the AC86U would be better on the flip side the R9000 could probably perform better even without hardware acceleration due to the more raw CPU power (ie in DD-WRT & OpenWRT/LEDE)

The R7800 is probably a better product for the average user than the R9000 as it uses the same WiFi chipset but has better WiFi performance and dual core with similar individual core performance. So for pure WiFi performance go for the R7800 or if VPN is important go for the AC86U.
 
Thanks for the answer.
I bought the RT-AC86U today. (Anyway, the version I bought is called RT-AC2900, but it is the same router.)

The VPN Speeds are awesome.
When performing a regular speedtest without VPN, I'm receiving about 255 Mbits/s / 102 Mbit/s, which is fine because I have a 250/100 connection from my ISP.

Depending on which VPN provider I'm testing with, I get now about 170 - 247 Mbit/s download speed.



Compared to my previous router the Linksys WRT1900ACSv2 with DD-WRT firmware on, I never got more than 140 Mbit/s max, when testing different VPN services.

Intersting also the tests RMerlin wrote in a post regarding his speed tests.

So far, the right decision to by this router, what I can see. :)
 
In theory though shouldn't the quad core be able to out perform the dual core?

Yes, if the routers were CPU limited with their workload. Generally, though, unless you're using a VPN or something equally CPU intensive, a faster CPU or more cores won't help basic routing or download/upload speed. I suppose if you're trying to go very fast without hardware or protocol assist, that could also get CPU intensive. But I don't see 250Mbps as being in the CPU intensive range.
 
The Cortex A15 in the R9000 is a “High Power” Core and does like 3.5 Dmips/MHz and the Cortex A53 in the 86U is a next gen “Low Power” that can do around 2.3 Dmips/MHz. The A57 is the true successor to the A15 generation wise and the A53 is a successor to the A7 in a way.

Having said that the hardware crypto acceleration in the AC86U is much better than the one in the R9000 so for VPN purposes the AC86U would be better on the flip side the R9000 could probably perform better even without hardware acceleration due to the more raw CPU power (ie in DD-WRT & OpenWRT/LEDE)

Just short remark:

BCM4906 is Cortex-A53 thus it is ARMv8 so it has AES instruction set, i.e. integral part of the CPU.

AL-514 is Cortex-A15 thus it does not have AES instruction set. But it has hardware cryptographic engine accessible through PCI. I use /dev/crypto driver for R9000 in my “HW” version of firmware and engine accessible through PCI interface. Not CPU is working here.

Different ways of hardware acceleration.

P.S. So you are right:
if VPN is important go for the AC86U.

Voxel.
 
I.e. if router is significantly loaded by many other duties such as media server (minidlna/Plex), file server (samba, ftp), or whatever else, then 4-cores R9000 is preferable. If primary goal is OpenVPN speed then AC86U.


Voxel.
 
Thanks for all the feedback.
I just want to give you a short feedback regarding the VPN speed in this router.
I upgraded my internet speed via the ISP to 1 GB/s (up and down). After this I made a few more tests during the day.
Looks like the VPN client speed is not getting faster than about 240-250 Mbit/s in bouth directions.



Was testing with a couple of different VPN providers (AirVPN/NordVPN/IPVanish/PIA), connected to their VPN servers here in Sweden.

I'm really pleased with this router so far. :)
 
Looks like the VPN client speed is not getting faster than about 240-250 Mbit/s in bouth directions.
What firmware do you use? Try to use Merlin version. He did a lot of improvements especially for OpenVPN.

Voxel.
 
What firmware do you use? Try to use Merlin version. He did a lot of improvements especially for OpenVPN.

Voxel.
I'm using Merlin firmware. Have in the mean time written a larger test report. You can read about it in my blog.
/Geraner
 
What firmware do you use? Try to use Merlin version. He did a lot of improvements especially for OpenVPN.

Voxel.

Performance-wise Asus shouldn't be that far behind me any longer, we've worked together on improving stock firmware's OpenVPN performance.
 
Performance-wise Asus shouldn't be that far behind me any longer, we've worked together on improving stock firmware's OpenVPN performance.
It is pity that I cannot say the same "together" regarding me and NG...

BTW, do not you play with cryptodev again?

Voxel.
 
It is pity that I cannot say the same "together" regarding me and NG...

The biggest performance boost they were missing was CPU affinity - I use the second core for the first VPN instance, so it doesn't share the same core as routing. They've applied it to the stock firmware a few months ago (I forgot with which version).

They are going to investigate moving to OpenVPN 2.4, but I'm not sure they'll gain much performance by this update however.


BTW, do not you play with cryptodev again?

No. Strongswan is able to directly access the crypto engine through the standard kernel crypto API, and OpenVPN was getting a major performance drop if going through the cryptodev overhead (probably due to the constant context switches between userspace and kernelspace I assume), so ultimately I dropped testing with cryptodev.

Strongswan test results with bcmspu (crypto engine) and without it (including CPU load results):

Code:
Downstream (bcmspu):
P:\Tools>iperf -c 192.168.1.51 -M 1400 -N -t 30
------------------------------------------------------------
Client connecting to 192.168.1.51, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[296] local 10.10.10.1 port 8334 connected with 192.168.1.51 port 5001
[ ID] Interval       Transfer     Bandwidth
[296]  0.0-30.0 sec  1.08 GBytes    309 Mbits/sec

CPU:  0.6% usr 64.6% sys  0.0% nic  8.2% idle  0.0% io  0.0% irq 26.4% sirq
Load average: 3.48 2.55 1.39 3/150 8377
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
  215     2 admin    RW       0  0.0   1 47.6 [pdc_rx]
  206     2 admin    RW       0  0.0   0 41.6 [bcmsw_rx]
  813     1 admin    S     8336  1.8   1  0.6 watchdog
  943     1 admin    S     4924  1.1   0  0.3 networkmap --bootwait


Upstream (bcmspu):
C:\Users\Eric\Documents>iperf -c 10.10.10.1 -M 1400 -N -t 30
------------------------------------------------------------
Client connecting to 10.10.10.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[296] local 192.168.1.51 port 2644 connected with 10.10.10.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[296]  0.0-30.0 sec    886 MBytes    248 Mbits/sec

CPU:  0.3% usr 67.1% sys  0.0% nic 12.2% idle  0.0% io  0.0% irq 20.3% sirq
Load average: 3.46 3.11 2.11 2/150 8645
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
  206     2 admin    RW       0  0.0   1 45.6 [bcmsw_rx]
  215     2 admin    RW       0  0.0   0 40.5 [pdc_rx]
  805     1 admin    S     8672  1.9   0  0.2 httpd -i br0


Downstream (software only)
P:\Tools>iperf -c 192.168.1.51 -M 1400 -N -t 30
------------------------------------------------------------
Client connecting to 192.168.1.51, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[292] local 10.10.10.1 port 1406 connected with 192.168.1.51 port 5001
[ ID] Interval       Transfer     Bandwidth
[292]  0.0-30.0 sec    475 MBytes    133 Mbits/sec

CPU:  0.1% usr 32.8% sys  0.0% nic 58.0% idle  0.0% io  0.0% irq  8.9% sirq
Load average: 3.16 2.99 2.44 3/150 8986
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
  206     2 admin    RW       0  0.0   0 40.7 [bcmsw_rx]
  805     1 admin    S     8672  1.9   1  0.2 httpd -i br0
  943     1 admin    R     4924  1.1   1  0.2 networkmap --bootwait



Upstream (software only)
C:\Users\Eric\Documents>iperf -c 10.10.10.1 -M 1400 -N -t 30
------------------------------------------------------------
Client connecting to 10.10.10.1, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[292] local 192.168.1.51 port 2851 connected with 10.10.10.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[292]  0.0-30.0 sec    381 MBytes    106 Mbits/sec

CPU:  0.2% usr 43.4% sys  0.0% nic 49.0% idle  0.0% io  0.0% irq  7.3% sirq
Load average: 3.12 2.97 2.38 3/152 8928
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
  206     2 admin    RW       0  0.0   0 49.7 [bcmsw_rx]
  805     1 admin    S     8672  1.9   1  0.2 httpd -i br0
  943     1 admin    R     4924  1.1   1  0.2 networkmap --bootwait



Downstream (AF_ALG + AARCH64 modules)
E:\Share>iperf -c 192.168.1.51 -M 1400 -N -t 30
------------------------------------------------------------
Client connecting to 192.168.1.51, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[292] local 10.10.10.1 port 1715 connected with 192.168.1.51 port 5001
[ ID] Interval       Transfer     Bandwidth
[292]  0.0-30.0 sec    835 MBytes    233 Mbits/sec
 
Not making full use of all available cores has always been perplexing especially when these companies make a point out of how many cores their CPU’s have.
 
Not making full use of all available cores has always been perplexing especially when these companies make a point out of how many cores their CPU’s have.

Using multiple cores is not something that happens automatically. The software must be designed to run specifically on multiple cores, by separating tasks into separate processes. OpenVPN doesn't do that, therefore it can only use one single core.

Using core affinity means forcing a specific process to run on a specific core. Since routing is already forced on the first core, forcing OpenVPN on the second core ensures that both can run concurrently. Asus are already doing similar fine tunings to various parts of the firmware, but they weren't doing it to OpenVPN. I suspect Netgear doesn't do it either.

Adding multi-core support to any piece of software requires a major redesign in most cases. The OpenVPN devs were considering doing this for the next major (3.x) release, but this has been on their long-term plans for years already, with no idea if/when that would happen.

So in the mean time, marketing departments will advertise number of cores as a selling factor. That doesn't mean it will align with the technical reality. Just like an AC2900 router will give you, at best, 800 Mbps of throughput for a given client. Or an Intel CPU with turbo set to 4 GHz will only reach 4 GHz when you have a single core under heavy use, and that clock will drop a bit when 3 or 4 cores are used, to remain within the thermal budget allowed by the cooling system.
 
You mean marketing lies? Say it ain’t so......

They don't lie, because that would be illegal. But they do twist facts, or hide little details that would provide a more accurate picture.
 
Sorry but that’s lying. Not telling the whole truth is lying.

And they advertise as if they are using multicores. I wonder if that could be a class action lawsuit for fraud?

The people coding their FW obviously are smart enough to know they aren’t, I know ASUS is, using all the cores.
 

Latest threads

Sign Up For SNBForums Daily Digest

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