Enabled DPI Monitor and negative impact in performance

Hi guys, we enable DPI only for monitoring, not for Traffic Priorization, because we don´t have and don´t go to have a License for DPI, only activating the Deep Packet Inspection function in QoS and the throughput is slower, clients claiming and latency is unnestable.

We tested in various environment with v4.7rc56, 60 and the lastest rc64 in PTP550 (Master only, Master and Slave, only in Slave), in AP 3000, 3000L, 3000MP and always we need to disabled them because low performance and clients claiming…

Here can see the first part of the graphic is with DPI Enabled and no more than 80MB… when disabled this function, the traffic go to the double and more…
Is the CPU or Memory affected?

2 Likes

Hi @Alessio_Garavano,

it is a straight punch! Could you provide more screenshots with radio and network configurations, monitor pages of performance and throughput. To see throughput difference when enabled and disabled. And DPI monitor page. RC64 only.

At the same time I will check latest throughput tests.

The issue is there. Thank you @Alessio_Garavano for your feedback! We are already working for resolution.

3 Likes

Can you please explain me why such functions are being implemented in AP/SM layer of network topology and valuable man-hours wasted for development?

1 Like

Technical progress. Modern changeless need modern solutions. In short instead of increasing throughput you can optimize user’s traffic flow so not to make your user complain. Or as it called improve UX.
It is an easy to use tool to prioritize certain kinds of traffic by application type. Before you could not give highest priority to Zoom only, average to Steam and lowest to google.drive that easy.

I see it all industries when everything now days becomes very optimized by smart technologies. Every process, every pipeline. Devil is in details!

1 Like

I understand the benefits of traffic prioritization, but why put such functionality in devices that would rather work in pure Layer2 level and leave the task of prioritizing to routers? You could easily mark packets in higher layer of network topology and then implement downlink priority mechanisms in MAC layer of your wireless protocol, just like MT did with their NV2 back in the day.

To my experience the device that does everything, sometimes doesn’t do anything good at all. I know plenty hardware made by serious well known vendors that starts to break when you try to use fancy functions that aren’t related to device’s direct purpose.

Keep it simple and do not overcomplicate. Adding this DPI stuff might be interesting and tempting to engineers, but trust me, it’ll do more damage than improvement…

1 Like

@squirrely you are also right, But… You put some router/firewall to mark downlink traffic. How will it distinguish 100+ applications? And it will work for downlink only. So at the same time you need to put something to mark uplink traffic. To be able to prioritize user’s WoT and Zoom upstreams. What will it be? Will you use some extra CPE? You will need a truck roll and you will get another fail point.

So it sounds like a big piece of work. Instead of it you can just buy a license for your already deployed access points. Something like $120 per AP and you don’t have to get out of your chair.

In parallel thread Fedor gives free test licenses to all interested :wink:

3 Likes