CPU Usage when network used

qwaven · Mar 19, 2019, 9:41 PM

tried the dispatch
sysctl net.isr.dispatch
net.isr.dispatch: deferred

cpu seemed to about 50% utilization.

interrupt total rate
cpu0:timer 122117 254
cpu2:timer 121707 253
cpu3:timer 116674 243
cpu1:timer 115728 241
irq256: ahci0 11720 24
irq257: xhci0 2850 6
irq258: hdac0 2 0
irq260: t5nex0:evt 2 0
irq269: igb0:que 0 659069 1372
irq270: igb0:que 1 1457 3
irq271: igb0:que 2 516 1
irq272: igb0:que 3 515 1
irq273: igb0:link 3 0
irq274: pcib5 1 0
irq280: pcib6 1 0
irq286: pcib7 1 0
irq287: igb3:que 0 453042 943
irq288: igb3:que 1 573830 1194
irq289: igb3:que 2 755133 1572
irq290: igb3:que 3 438318 912
irq291: igb3:link 3 0
irq292: pcib8 1 0
Total 3372690 7020

qwaven · Mar 19, 2019, 9:51 PM

Also now tried disabling ntop cpu usage looks to be maybe 8-10% less.

stephenw10 · Mar 19, 2019, 10:05 PM

Is that total CPU was 50%? Did throughput increase?

Steve

qwaven · Mar 20, 2019, 2:40 PM

That would be what was shown on the dashboard for cpu performance. If utilization is stuck on 1 core I am not sure if there would be anything else we can do.

As for throughput, it was about the same but I am not worrying about that as the source for the transfer may impact this as well. Ideally it would be great to see it closer to my actual speed but I'm not sure about testing it reliably.

Cheers!

qwaven · Mar 22, 2019, 3:31 PM

Hi again,

I'm assuming we've exhausted trying to improve the cpu utilization with this but I just wanted to say thanks for the help/efforts with this. I am still open to try anything though.

Cheers!

stephenw10 · Mar 24, 2019, 12:00 PM

I suspect it might be. The single thread performance of that CPU is about equal to that of the Pentium M I used to run and that was good fpr ~650Mbps. At least according to this:
https://www.cpubenchmark.net/compare/Intel-Core2-Duo-E4500-vs-Intel-Pentium-N3700-vs-Intel-Pentium-M-1.73GHz/936vs2513vs1160
Obviously that's synthetic and there are many variable etc. No PPPoE overhead in that test either.
The E4500 can pass Gigabit, just. (at full size TCP packets...many variables etc!).

If that is to be believed then it probably is running burst mode and I'm not sure there's much we can do before RSS is re-written in FreeBSD to allow multiple cores.

You probably could see better performance off-loading the PPPoE to another device. That would probably mean a double NAT scenario unfortunately.

Steve

qwaven · Mar 25, 2019, 6:11 PM

Hi Steve,

It's unfortunate about this RSS issue. I have another board that I plan to try out, however its quite overkill especially if only 1 core is going to be used for pppoe. However it does have some better on board hardware that may help overall. It is however still just 2ghz/core.

https://www.supermicro.com/products/motherboard/atom/A2SDi-H-TP4F.cfm

Cheers!

stephenw10 · Mar 25, 2019, 9:53 PM

Yes. I have a PPPoE WAN but fortunately/unfortunately it's no where near fast enough to worry about this.

No benchmarks for the C3958 but if we assume it's the same as the C3858 but with 4 more cores then it should make about ~40% better single thread performance.

It does seem like a waste of cores unless you virtualise it.

Steve

qwaven · Mar 25, 2019, 11:29 PM

Hi Steve,

So I flipped it over. Performance so far looks drastically better. CPU in the gui was about 5-6% while transferring over pppoe. I believe still just the 1 core.

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11 root 155 ki31 0K 256K CPU1 1 7:39 97.26% [idle{idle: cpu1}]
11 root 155 ki31 0K 256K CPU10 10 7:41 97.12% [idle{idle: cpu10}]
11 root 155 ki31 0K 256K CPU13 13 7:33 96.96% [idle{idle: cpu13}]
11 root 155 ki31 0K 256K CPU7 7 7:45 96.85% [idle{idle: cpu7}]
11 root 155 ki31 0K 256K CPU11 11 7:38 96.51% [idle{idle: cpu11}]
11 root 155 ki31 0K 256K RUN 4 7:43 96.46% [idle{idle: cpu4}]
11 root 155 ki31 0K 256K CPU3 3 7:44 96.46% [idle{idle: cpu3}]
11 root 155 ki31 0K 256K CPU9 9 7:36 96.26% [idle{idle: cpu9}]
11 root 155 ki31 0K 256K CPU5 5 7:42 95.99% [idle{idle: cpu5}]
11 root 155 ki31 0K 256K RUN 8 7:19 95.56% [idle{idle: cpu8}]
11 root 155 ki31 0K 256K CPU6 6 7:42 95.12% [idle{idle: cpu6}]
11 root 155 ki31 0K 256K CPU2 2 7:42 94.98% [idle{idle: cpu2}]
11 root 155 ki31 0K 256K CPU12 12 7:40 93.93% [idle{idle: cpu12}]
11 root 155 ki31 0K 256K RUN 15 7:35 87.04% [idle{idle: cpu15}]
11 root 155 ki31 0K 256K CPU14 14 7:31 82.95% [idle{idle: cpu14}]
11 root 155 ki31 0K 256K RUN 0 7:24 79.60% [idle{idle: cpu0}]

irq298: ix0:q0 2716423 6058
irq299: ix0:q1 244578 545
irq300: ix0:q2 461159 1029
irq301: ix0:q3 243416 543
irq302: ix0:q4 378891 845
irq303: ix0:q5 124788 278
irq304: ix0:q6 478729 1068
irq305: ix0:q7 125913 281
irq306: ix0:link 1 0
irq307: ix1:q0 326596 728
irq308: ix1:q1 254938 569
irq309: ix1:q2 614196 1370
irq310: ix1:q3 250402 558
irq311: ix1:q4 388996 868
irq312: ix1:q5 128709 287
irq313: ix1:q6 492403 1098
irq314: ix1:q7 130143 290
irq315: ix1:link 1 0

ix0 is pppoe and ix1 is internal lans.

I was thinking about virtualizing. However I've seen so many talks about people suggesting this is not a great choice for a firewall. However I'm open to exploring this more. Do you have any thoughts? Proxmox was my first choice.

Cheers!

stephenw10 · Mar 26, 2019, 12:09 AM

Nice, what sort of throughput were you seeing at that point?

I can't really advise on hypervisors, I'm not using anything right now.

A lot of people here are using Proxmox though. ESXi is also popular.

Steve

qwaven · Mar 26, 2019, 4:33 PM

Same throughput but I believe this is more because of the source. I have not had a chance to test internally the network to see if anything there is improved. Will update once I have.

qwaven · Mar 26, 2019, 11:17 PM

so testing with iperf3, I still don't seem to be getting anywhere close to 10G bandwidth.

It looks about spot on with 1G.

[ 41] 0.00-10.00 sec 56.4 MBytes 47.4 Mbits/sec 3258 sender
[ 41] 0.00-10.00 sec 56.4 MBytes 47.3 Mbits/sec receiver
[ 43] 0.00-10.00 sec 58.1 MBytes 48.8 Mbits/sec 3683 sender
[ 43] 0.00-10.00 sec 58.0 MBytes 48.6 Mbits/sec receiver
[SUM] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec 69930 sender
[SUM] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver

Any ideas?

This is literally SFP+ 10G interface on pfsense to switch to fileserver. The file server has two 10G bonded links. Nothing else running.

Cheers!

stephenw10 · Mar 27, 2019, 1:15 AM

How many processes are you running there?

You have 8 queues so I don't expect to any advantage over 8.

Is that result testing over 1G? What do you actually see over 10G?
I would anticipate something ~4Gbps maybe. Though if you're running iperf on the firewall it may reduce that.

Steve

qwaven · Mar 27, 2019, 2:08 PM

My test with iperf was sending 20 connections (what I saw someones example on the internets doing) and it looks pretty much to saturate if it were 1G.

This is not 1G. This is using my internal network. Pfsense reports it as 10G, the switch is all 10G, and the file server has 2x10G.

Curious why would iperf on the firewall reduce this?

fyi cpu did not appear stressed in any way.

Cheers!

stephenw10 · Mar 27, 2019, 3:19 PM

That seems far too much like a 1G link limit to be coincidence.

Check that each part is actually linked at 10G.

Steve

qwaven · Mar 27, 2019, 11:14 PM

so on my pfsense I can see all my internal interface vlans are listed with:

media: Ethernet autoselect (10Gbase-T <full-duplex>)

on my NAS I see the bonded interfaces:

Settings for eth4:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseKX/Full
10000baseKR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Advertised link modes: 1000baseKX/Full
10000baseKR/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Speed: 10000Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000014 (20)
link ifdown
Link detected: yes

Settings for eth5:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseKX/Full
10000baseKR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Advertised link modes: 1000baseKX/Full
10000baseKR/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Speed: 10000Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000014 (20)
link ifdown
Link detected: yes

On the switch:

0/3 PC Mbr Enable Auto D 10G Full Up Enable Enable Disable (nas)
0/4 PC Mbr Enable Auto D 10G Full Up Enable Enable Disable (nas)
...
0/16 Enable Auto 10G Full Up Enable Enable Disable (pfsense)

Grimson · Mar 27, 2019, 11:20 PM

Do you use traffic shaping/limiters?

qwaven · Mar 27, 2019, 11:32 PM

Unless there is something configured from a default install I have not set anything myself. Going into the traffic shaper area it does not appear to have anything set.

For reference I have dismantled my NAS bonded interfaces and just using 1 interface now. Results are about the same showing about 1G speed.

Thanks!

qwaven · Mar 28, 2019, 1:20 AM

Update: I have now separated the NAS from the rest of the VLAN's I had to try and ensure nothing going on there. Now its on its own 10G interface. Results about the same.

Another interesting fact. If I reverse the iperf direction. NAS to PFsense I can see the bandwidth spike up to more around the 2G range.

Doing -P20 (20 transfers at once)
[SUM] 0.00-10.00 sec 2.71 GBytes 2.33 Gbits/sec receiver

Without, it will drop down to a little over 1G.

Any ideas?

stephenw10 · Mar 28, 2019, 7:44 PM

Is that using the -R switch? Can you try running the actual client on the NAS and server on pfSense? That will open firewall states differently.

You could also try disabling pf as a test. If there is a CPU restriction still that should show far higher throughput.

Steve