CPU Core Usage with OpenVPN Client?

[Dezzo]

Hello,

I've got an RT-AC68U with Merlin firmware 378.55.
CPU/RAM is set to 1100/666.
Temps 2.4 GHz: 48°C / 5 GHz: 52°C / CPU: 72°C


I read a tip somewhere that said to configure the OpenVPN Client on Client 2 so that the VPN would be processed on CPU core #2 while the routing functions would be processed by CPU core #1.
I thought this was interesting so wanted to test it myself to see how it worked.

What I found was interesting but different from what the other user claimed.
I tried both Client 1 and Client 2 separately and generated download activity through the VPN while watching the CPU activity.

OpenVPN Client 1, VPN traffic causes Core #1 to hover around 70% while Core #2 remains idle around 2%.
OpenVPN Client 2, VPN traffic causes Core #1 to hover around 80% while Core #2 hovers around 50%.

I repeated this several times with the same results.
Is this normal behavior? It is interesting to me that the client choice would impact how the router uses the CPU. I would have expected the load to be balanced across both cores regardless, but it seems not to work this way.

Can anyone else test this and report your results too?
Does anyone have any insight into how this works?

 

[joegreat]

Hello,

I've got an RT-AC68U with Merlin firmware 378.55.
CPU/RAM is set to 1100/666.
Temps 2.4 GHz: 48°C / 5 GHz: 52°C / CPU: 72°C


I read a tip somewhere that said to configure the OpenVPN Client on Client 2 so that the VPN would be processed on CPU core #2 while the routing functions would be processed by CPU core #1.
I thought this was interesting so wanted to test it myself to see how it worked.

Hi,

I suggest not to mess around with "core pinning/processor affinity" (attaching CPU cores to specific processes) as the Linux CPU scheduler does a great job to schedule the processes on the available cores!
On the poor router this might only give worse results then without doing anything - only in very specific high performance computing it might be beneficial to think about it.

Below an example of the work (recorded with dstat) in case of Transmission running on my 68U router (see column 'idl' vs. 'wai').

With kind regards
Joe

-------cpu0-usage--------------cpu1-usage-----------total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq:usr sys idl wai hiq siq:usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
  0   2  74  20   0   4:  2   0   0  98   0   0:  1   1  37  59   0   2|1264k    0 |  41k  412k|   0     0 |1002  1336
  1   0  70  24   0   5:  2   2   0  96   0   0:  2   1  35  60   0   3|4960k    0 |  45k  432k|   0     0 |1031  1427
  2   1  70  25   0   2:  1   0   0  99   0   0:  2   1  35  62   0   1|2012k    0 |  46k  460k|   0     0 |1078  1374
  2   0  77  19   0   2:  1   0   0  99   0   0:  2   0  39  59   0   1|1712k    0 |  52k  455k|   0     0 |1088  1428
  1   2  71  23   0   3:  1   0   0  98   0   1:  1   1  36  61   0   2|1396k    0 |  61k  436k|   0     0 |1041  1359
  1   2   1  92   0   4:  2   2  93   2   0   1:  2   2  47  47   0   3|1536k    0 |  52k  452k|   0     0 | 964  1281
  1   2   0  96   0   1:  1   0  99   0   0   0:  1   1  50  48   0   1| 644k    0 |  49k  538k|   0     0 |1108  1466
  1   1   0  93   0   5:  1   0  99   0   0   0:  1   1  50  47   0   3|1512k    0 |  38k  448k|   0     0 | 981  1437
  4   0   0  94   0   2:  1   2  97   0   0   0:  3   1  49  47   0   1|2628k    0 |  46k  459k|   0     0 |1097  1528
  0   0   0  97   0   3:  2   2  96   0   0   0:  1   1  48  49   0   2|3748k    0 |  35k  389k|   0     0 | 830  1256
  2   1  44  50   0   3:  1   0  40  59   0   0:  2   1  42  55   0   2|1432k    0 |  53k  511k|   0     0 |1138  1444 ^C

 

[cosmoxl]

With openvpn traffic there are kernel processes that take up quite a few clock cycles and of course the openvpn process. The Kernel processes take place on core 0 (1).

I believe stock Asus firmware has openvpn client 1 using core 0 (1) and openvpn client 2 using core 1 (2). But Merlin firmware has openvpn client 1 is mapped to use core 1 (2). This usually works well since most people only use one openvpn client and this leaves core 0 (1) free to do kernel work and openvpn free on core 1 (2).

In your testing I would imagine the times only one core was used your overall openvpn throughput was lower than when both cores were used. This meant kernal and openvpn work were separated. Openvpn is not multithreaded (yet) so it will not be divided over the two cores.

 

[Calisro]

You get good openvpn performance improvements from keeping the openvpn process on a different core than your critical router functions. In the latest build, Merlin already does this. He puts the client1 vpn on the second core. We've seen very large openvpn improvements by doing this.

If you want to manage it yourself, you can. There is no issue with doing so. The stock scheduler will NOT manage this correctly for you.

This is a script I use for TINC VPN to move it to the core I want it on for example:

rt-ac68u: /jffs/scripts # cat /jffs/scripts/tincstart.sh
#!/bin/sh
NET=$1

TINCD=/jffs/bin/tincd
#OPTS="--logfile=/jffs/tinc$NET.log -d 3"
OPTS="-d 3"

ps | grep $TINCD | grep -v $0 | grep $1 >/dev/null
if [[ $? -gt 0 ]]; then
  $TINCD -n $NET $OPTS
  case $NET in
    hometap) CPU=2;; #moved both to core 2
    hometun) CPU=2;;
    *) CPU=2;;
  esac
  sleep 2
  taskset -p $CPU $(cat /var/run/tinc.${NET}.pid|awk '{print $1}')
  CRUNAME=tincd$NET
  cru l | grep $CRUNAME >/dev/null || cru a $CRUNAME "*/15 * * * * $0 $*"
fi
exit 0

 

[Dezzo]

Well then it was smart of Merlin to reverse the cores in his implementation of the firmware. I hope that is something that is noticed and implemented by ASUS in their version too.
Based on this I have moved the VPN back to the Client 1 position.

I just thought it was interesting that the chosen settings would dictate which core is used as that is not documented anywhere. Is anyone aware of other examples where this happens in the firmware?


Merlin:
Id also like to mention that at one point I went back into the VPN settings to find that both Client 1 and Client 2 were connected simultaneously, despite the fact I had earlier turned one of them off. This happened a few times and surprised me. The only thing I can think is that the "Start with WAN" was enabled, so that likely triggered the client to start up again on the next reboot or something?

If that is the case, it would be nice if it could be fixed so that flicking the Off switch would also disable the above setting, or at least warn the user about it so that they wouldnt find the client had started up unexpectedly later.

 

[Calisro]

"Start with WAN" was enabled would trigger on a reboot but my personal opinion is just because you are stopping it now doesn't mean you don't want it to fire on the next boot. I think they are mutually exclusive.

 

[RMerlin]

Start With WAN is indeed totally separate from the On/Off switch. That's why both switches exist and not just one single On/Off switch. First one is on demand, other one is automatic. They both serve different goals.

 

[RMerlin]

Well then it was smart of Merlin to reverse the cores in his implementation of the firmware. I hope that is something that is noticed and implemented by ASUS in their version too.
Based on this I have moved the VPN back to the Client 1 position.

I just thought it was interesting that the chosen settings would dictate which core is used as that is not documented anywhere. Is anyone aware of other examples where this happens in the firmware?

When Asus merged my OpenVPN code the feature was already there. I never really checked whether they kept that specific feature or not, but in any case it was there in the original code.

Asus does a few core affinity tweaks. I believe Samba is another one that gets to run on the second core.

 

[peraburek]

You get good openvpn performance improvements from keeping the openvpn process on a different core than your critical router functions. In the latest build, Merlin already does this. He puts the client1 vpn on the second core. We've seen very large openvpn improvements by doing this.

If you want to manage it yourself, you can. There is no issue with doing so. The stock scheduler will NOT manage this correctly for you.

This is a script I use for TINC VPN to move it to the core I want it on for example:

rt-ac68u: /jffs/scripts # cat /jffs/scripts/tincstart.sh
#!/bin/sh
NET=$1

TINCD=/jffs/bin/tincd
#OPTS="--logfile=/jffs/tinc$NET.log -d 3"
OPTS="-d 3"

ps | grep $TINCD | grep -v $0 | grep $1 >/dev/null
if [[ $? -gt 0 ]]; then
  $TINCD -n $NET $OPTS
  case $NET in
    hometap) CPU=2;; #moved both to core 2
    hometun) CPU=2;;
    *) CPU=2;;
  esac
  sleep 2
  taskset -p $CPU $(cat /var/run/tinc.${NET}.pid|awk '{print $1}')
  CRUNAME=tincd$NET
  cru l | grep $CRUNAME >/dev/null || cru a $CRUNAME "*/15 * * * * $0 $*"
fi
exit 0

I have tried to use your script to assign OpenVPN Client 1 to second CPU core on AC68U, but it doesn't work

can you please advise, what needs to be changed??