In reply to a post by ian72:

But if CPU 0 is busy on a single thread and a new request comes in (like another download or a ping) then shouldn't CPU 1 pick up that request as it is idle?

Not on PPPOE is my understanding its a major limitation, because of encapsulation it has to be processed by a single thread to be able to go down the pipe. Thats why a lot of people complain about PPPoE and why its a bottleneck, ISP/altnet who use DHCP don't have the issue.

Interesting, seems a bit pointless having 2 cores in the router then but I guess the router would support more than just PPPoE so the other core would be utilised if it was a different configuration.

In reply to a post by dect:

Not on PPPOE is my understanding its a major limitation, because of encapsulation it has to be processed by a single thread to be able to go down the pipe. Thats why a lot of people complain about PPPoE and why its a bottleneck, ISP/altnet who use DHCP don't have the issue.

I knew that was the case on the open source implementations of PPPoE for things such as OPNsense or pfSense. Is that the case for closed source implementations as well?

I don't have a PPPoE based ISP, but it should be easy to test with a Mac/Windows/Linux computer.

In reply to a post by jchamier:

I knew that was the case on the open source implementations of PPPoE for things such as OPNsense or pfSense. Is that the case for closed source implementations as well?

Its my understanding based on Opnsense/Pfsense which both run on FreeBSD, I didn't think it was a limitation caused by their code but more about encapsulation and the OP isn't running either Opnsense or Pfsense and they appear to be having the same issue.

On Opnsense and Pfsense both 'receive-side scaling' (net.inet.rss) and the 'kernel network dispatch service' (net.isr) can be enabled/configured to improve router performance by multi threading but it still doesn't help with the PPPoE encapsulation issue.

Edited by deleted (Thu 25-May-23 11:49:17)

In reply to a post by Cheule:

After thinking about the earlier suggestion that the router may be too busy to send ping requests, I logged into the router and monitored the dual cores while running speed tests. Each time, CPU 0 went to 100% and stayed there, CPU 1 basically did nothing.

After hitting the net it appears many are having the same problem but no clear results on how to fix it or get both cores to share the work.

Even high end routers sometimes drop pings or de-prioritises them - it's a feature as pings are generally not 'important'

In reply to a post by dect:

Its my understanding based on Opnsense/Pfsense which both run on FreeBSD, I didn't think it was a limitation caused by their code but more about encapsulation and the OP isn't running either Opnsense or Pfsense and they appear to be having the same issue.

Thanks

On Opnsense and Pfsense both 'receive-side scaling' (net.inet.rss) and the 'kernel network dispatch service' (net.isr) can be enabled/configured to improve router performance by multi threading but it still doesn't help with the PPPoE encapsulation issue.

I wonder which wholesale network will be the first to remove PPPoE then.

We have CityFibre to the East and West of us, and we are in their planning phase so I'm using good 'old BT just for now.

Hopefully they don't use PPPoE? Anyone know?

Sorry if this is stupid but everyone seems to be talking about your graph showing packet loss (which I believe is red dots). Am I blind because I literally don't see any?

This is what I see: https://i.imgur.com/4qEk5tF.png

The reason is that the link in the opening post back in May 23 is to a live BQM which is constantly updating, rather than a snapshot at the time as you can see by looking at the date. So the line conditions have changed and the BQM is now looking good with no packet loss.

@Cheule,

What was the solution to this? I am having similar issues, with 5% or less packet loss constantly.

I went from 48mb FTTC to 500 FTTP, TBH be honest I never tested the FTTC connection.

thanks