931
Zenarmor (Sensei) / Re: Sensei on OPNsense - Application based filtering
« on: September 05, 2018, 07:28:31 pm »
Hi @sol,
Many thanks for reporting this and for the answer. This is very much helpful to understand what's going on.
Looks like a quite loaded system. I would not recommend running with a 60-70% cpu utilization if you're doing some kind of packet processing. Because packet processing requires dedicated resources and if the cpu is highly utilized and also shared with other applications, it's highly possible that you'll start losing packets. This is so, because at some point OS will fail to schedule the packet processing application to a CPU (because the CPU is already busy) and packets will be dropped in this timeframe. As a consequence, this will create congestion, and finally you'll get lower throughput. This was what happened, lowering your throughput from 150 - 85 Mbps.
To remedy this kind of heavy load scenarios, there is one thing you can do, and one thing we can:
For you, as you wrote before, it'd be better if you can run the configuration with a more resourceful HW.
For Sensei, we'll pin it to a dedicated CPU core. This will help if you have a multi-core system.
For not being able to stop Sensei, I'd guess it's related to the above scenario. Though it should stop anyway whatever the load is.
We'll try to reproduce this with your conditions in our lab. I'll let you know about our results.
For the sake of clarity: were you trying to stop it by clicking on the "Stop" action button or by disabling "Start on Boot" option. Latter one controls whether Sensei should be run during boot time. If you disable it, it does not stop the engine, you'll need again to click on Stop. Most probably you clicked on "Stop", but just wanted to be 100% sure.
Many thanks for reporting this and for the answer. This is very much helpful to understand what's going on.
Looks like a quite loaded system. I would not recommend running with a 60-70% cpu utilization if you're doing some kind of packet processing. Because packet processing requires dedicated resources and if the cpu is highly utilized and also shared with other applications, it's highly possible that you'll start losing packets. This is so, because at some point OS will fail to schedule the packet processing application to a CPU (because the CPU is already busy) and packets will be dropped in this timeframe. As a consequence, this will create congestion, and finally you'll get lower throughput. This was what happened, lowering your throughput from 150 - 85 Mbps.
To remedy this kind of heavy load scenarios, there is one thing you can do, and one thing we can:
For you, as you wrote before, it'd be better if you can run the configuration with a more resourceful HW.
For Sensei, we'll pin it to a dedicated CPU core. This will help if you have a multi-core system.
For not being able to stop Sensei, I'd guess it's related to the above scenario. Though it should stop anyway whatever the load is.
We'll try to reproduce this with your conditions in our lab. I'll let you know about our results.
For the sake of clarity: were you trying to stop it by clicking on the "Stop" action button or by disabling "Start on Boot" option. Latter one controls whether Sensei should be run during boot time. If you disable it, it does not stop the engine, you'll need again to click on Stop. Most probably you clicked on "Stop", but just wanted to be 100% sure.