Hi @avpopov1977 

Thanks for posting in our business forum.

avpopov1977 wrote

  @Clive_A 

 

Hello! I see, ok I will try to describe bugs here. 

As an owner of both 8411 and 6120 devices I made a conclusion that older 6120 was much more faster but I think Tp-link engenering team will fix it in the futher firmwares.

(I just did not want to disclose this publicaly because I like Tp-link devices but 8411 made my highly disappointing...)

So, I want to concentrate at the 1-st problem with poor CPU efficiency at 8411.

I marked by arrow CPU Loading at he moment os my login to router

6120:

8411:

I have no multiple VPN connections, Traffic Loading is about 10-20% at both routers, but I found that 8411 loads CPU x2 higher than 6120 for the same operations.

Underlined values are freezing at 8.26% and I cant reset statistics by pressing Clear button.

Switching On/off DPI also does not helps...

 

8. Solved. I was too dumb to uncheck Wan box ))))) Thank you!

 

Best Reagrds!

Higher architecture does not mean it will have a low CPU usage. And a high boost in frequency does not mean a problem unless it constantly runs at an abnormal frequency.

I explained the CPU baseline is now higher than the old system or the previous firmware. It should be a normal sign for most computing devices.

And this might not be a problem with the CPU but the software the system has. If I did not recall it wrong, the system is based on the Openwrt, which may have a higher CPU usage when logging. It seems to be a universal symptom. Not a bad CPU efficiency.

avpopov1977 wrote

  @Clive_A 

 

I have no multiple VPN connections, Traffic Loading is about 10-20% at both routers, but I found that 8411 loads CPU x2 higher than 6120 for the same operations. 

The worst problems I got If one of WANs begat to go Offline-Online at 8411 (that is why I adviced you to made some percentage trashold in the Online Detection) - it caused all the traffic hangs for few minutes (especialy at PPPoE Wan), 6120 did graceful switching traffic to the operational WAN and nobody felt the problem! Also I found the difference in behavior of 6120 and 8411 at WAN switching/modifying and it could be the reason why 8411 doing it so slowly. 6120 is changing OID in SMTP every port switching. If to modify or to enable-disable WAN at 6120 - it will increases OID +1 number! 8411 WAN OIDs did not changing, only pptp/l2tp interface after modifuing could. May be problem is somewhere in there, I don't know....

 

Load balance, and online detection, have a threshold and are explained in the KB.

Percentage, how do you expect it to be?

How slow do you experience with the link backup?

avpopov1977 wrote

  @Clive_A 

 

DPI statistic bug is looks like this:

Underlined values are freezing at 8.26% and I cant reset statistics by pressing Clear button.

Switching On/off DPI also does not helps...

DPI indeed looked like it bugged out. Will this persist all the time you've been using it? I mean can you reproduce this steadily?

Hi @avpopov1977 

Thanks for posting in our business forum.

avpopov1977 wrote

  @Clive_A 

 

Thank you for the fast answer!

Of course I understand that efficiency problem caused by some WAN-switching algorithm.. not CPU.

 

My situation was: 1 of 3 WANs (100mbits + 100mbits + 300mbits all in Load Balancing) began to disconnect-connect too much times by Online Detection.

And the solution was only to disable problem WAN manually, because sometimes Online Detection switching this WAN online.

And I can share with you my idea to add some options for Online Detection to prevent such behavior in the future:

1. Ping packets size variable (1~65000 bytes)

2. % of lost of packets variable (0~100%) for Online/Offline detection

3. Ping interval (sec.) variable

4. Number of pings packets in the interval variable

It could be nice upgrade for Online Detection using this additional variables for me. It is my vision how to fix, probably firmware developers have a better idea or can use 1-2 of this variables for not to overload CPU by Online Detection algorithm...

 

How slow do experience with the link backup:

 

Hmmmm.... I've tried to disconnect-connect PPPoE WAN and it reconnected in 2 seconds, Perfect!

But then (18:18:59) I disconnect-connect simple and not loaded Dynamic IP Wan and you can see the time that 8411 spended to get this WAN back online...

And after few time this WAN gone offline-online once more... 

 

Traffic hangs for not so long time now! I think it is the result that I'm not useing Policy Routing at this time! Changed it to Static Routing.

3 WANs in Load Ballancing + Online Detection + 36 Static Routes to PPTP Client - that is how all the traffic hangs when I disconnect-connect one of the WANs...

 

Ijust compared with 6120 that have 30 Policy Routings now and PPTP Client at the WAN I disabled-enabled. The result:

 

 

 

6120 just restoring traffic much more faster!

 

DPI counter is now:

 

 BitTorrent 465.94G (40.74%)

 YouTube 398.38G (34.83%)

 Google Meet 93.13G (8.14%)

 Apple Services 93.13G (8.14%)

 WhatsApp 93.13G (8.14%)

 

Best Regards!

If it fails to reply to several DNS queries, then it will be considered as WAN disconnection. I explained this in the KB: Common Questions About the Load Balancing, Link Backup(Failover) & Online Detection

I have quoted so many times and I literally wish you could take a look before making a question on the link backup and failover system.

You did the test, did you test the three WANs on the 6120 with the same config from 8411?

And the test methodology from the old system and the new system is slightly different. New Omada system added extra domains for the testing.

Will you be able to Wireshark and check if the DNS query number is the same as the 8411?

Just some questions on your test methodology but I think they are not accurate and enough to illustrate the performance is worse than 6120. I would like to see more concrete evidence.

Hi @avpopov1977 

Thanks for posting in our business forum.

avpopov1977 wrote

P.S.

 

once more switched 30+ my routes from Static to Policy Routing.

Few hours later some users got an issue of a "low speed internet".

Low speed was caused by 0.0.0.0/0 route to VPN Client Gateway (that is not so fast).

I switched Policy Routing Enable-Disable-Enable and issues was fixed!!!

But few hours later new issues exact from the same users (by LAN IP).... ((

 

So, enabling-disabling of Policy Routing made it fix for few hours in my case...

very mysterious bug...........

Exactly the same Static Routing and Policy Routing, you mean? Which perfectly works on 6120 and not go well with 8411?

Post the table with partially mosaic them.

Hi @avpopov1977 

Thanks for posting in our business forum.

avpopov1977 wrote

  @Clive_A 

 

Hello. 6120 have the same problem with Policy Routing. I wrought higher that this problem migrated from 6120 to 8411.

6120 have no problem with traffic hangs when WAN switching offline-online I wrought.

May be 30+ policy routings is too much for this routers?

(Exact the same routings in the Static works fine at 6120 and 8411)

Also please attend attention that 30+ Problem Static and Policy Routings i've setupped to PPTP Client.

I have 3 Policy Routings that routed to DynamicIP and 3 to PPPoE WAN - They works fine! <- so probably Bug hiding in VPN Client interface....

Regarding the DPI stats being incorrect, please reply to the email ticket with the backup. Please specify the hardware and firmware, username, and password.

We have not reproduced this issue or similar report during the beta phase.

About your other questions, if this so-called "issue" migrates from 6120 to 8411, that should be an expected feature.

To get each followed separately, I still insist you create a new thread about each problem described.

I don't intend to follow up on several issues you've reported at the same time.

Like my first reply to you, some are not problems/bugs. It is expected behavior or design. Try not to draw a conclusion now without concrete evidence.

Hi @avpopov1977 

Thank you so much for taking the time to post the issue on TP-Link community!

To better assist you, I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID240924108, please check your email box and ensure the support email is well received. Thanks!

Once the issue is addressed or resolved, welcome to update this topic thread with your solution to help others who may encounter the same issue as you did.

Many thanks for your great cooperation and patience!