Gigabit speed on WAN - PPPOE

General discussion
#21

At MSS 150 the measurable good put over IPv4 is:
100 * ((150) / (150+20+20+8+4+38)) = 62.5% of the gross rate, while at MTU 1500 → MSS 1452 it is
100 * ((1452) / (1452 +20+20+8+4+38)) = 94.16% of the gross rate…
so the maximum throughput @MSS150 is:

2.5Gbps ethernet: 2.5*0.625 -> 1562 Mbps
1.0Gbps ethernet: 1.0*0.625 ->  625 Mbps

so:
omnia:

100 * 175.49 / 1562 = 11.23% 
100 * 208.73 / 1562 = 13.36%

i3-13100:

100 * 526.76 / 1562 = 33.72%
100 * 696.81 / 1562 = 44.61%

But this is a tough test since most routing duty is per-packet and not per byte, so MSS150 results in an almost 10-times higher load on the router…

And yes, PPPoE is not free, but I guess that would be true for any other kind of tunneling as well. This is where DOCSIS-ISPs actually do well, as most use DHCP to assign addresses and do not enforce another end-user visible tunneling, giving CPE more breathing room.

Side-note:
Now, there is a bit of irony here, s PPPoE was (partly) invented to allow ISPs to continue their time-based internet charging like in the analog modem days (often using PPP), even though most fixed internet access links are either “flat-rates” or charged by volume… however it is not that time-based charging, but the generic tunneling that made PPPoE survive IMHO. (In Germany the incumbent also is forced by the regulator to use PPPoE for its bitstream access contracts to its resellers, but I am sure that could be changed).

Interesting thought, would love to see results, however due to the 20byte higher per packet overhead that NAT saving will need to overcome that ~100*20/1500 = 1.3% lower throughput.

Thanks for the additional information on why PPPoE is still used.

1 Like
#22

PPPoE also allows for easier customer identification and session management and reduces the complexity of the last mile. With PPPoE, you have to manage one identifier, one session, and maintain one helper to identify customers (assuming you identify customer per port; if you go for username/password validation, it’s even easier, as the last mile devices can be quite dumb). Once the session is up, you can route a public IPv4 address to it (and you can have a block of 256 addresses and allocate these all to customers spread across the region, as long as their PPPoE sessions all end up on one BRAS), a whole block of IPv4 addresses to it, delegate IPv6 prefixes with clear next-hop definition (the tunnel endpoint)…

With IPoE, or DHCPv4/v6, you have to have smart last mile devices (identifying customers properly on both protocols by adding correct DHCP options to the requests), you have to segment your IP allocations better, sometimes you have to perform nasty ARP hacks like the cable operators do… but the benefits are clear: MTU 1500, no tunnelling (= packets can be processes by all CPU cores) and better suitability for speeds above one gigabit per second. Still there are ISPs (like Bell Canada) that keep using PPPoE even for 8 Gbps plans.

2 Likes
#23

Very cool, thanks! It would be interesting to see the numbers with wifi6 modules.

1 Like
#24

I sadly don’t have the Omnia Wi-Fi 6 module, neither do I have any good Wi-Fi 6 client besides my phone or tablet. :smiling_face_with_tear:

#25

btw, just checked the same fiber connection ( 1 Gb fiber ) with a different router, and in this case an old AC1900 synology.
Easy over the 900 down… same PPPOE protocol. MOX classic 620 down

So, apperantly something is not right with the Mox Classic, speedwise.

Edit : configuration is pretty basic. Adblock & openvpn is the only add on.
and the AC1900 has a Broadcom BCM58622 @ 1 GHz chipset, 256 MB RAM and 4 GB flash, so no fancy specs.

1 Like
#26

This is a dual core A9, while the MOX sports a multicore a53… the a9 really is a better core than a53 for general purpose processing… really Arm’s power-efficient line is great at being power-efficient, but the claim that a53 meets or even beats the previous performance line’s A9 performance really only holds for carefully selected benchmarks…

It is really that simple in-order-designs like A53 simply are not as robust as out-of-order designs like A9, no ifs no buts… and since Arm’s efficiency line switched to out-of-order as well, I think that case is settled…

However the issue here can also be an issue of PPPoE acceleration working on one SoC but not the other more than general differences between different ARM cpu lines :wink:

2 Likes
#27

Maybe it is a solution to fabricate a new mox part with a faster main CPU? i mean, it is a modulair thing, so that could solve this WAN speed hickup?

1 Like
#28

That would IMHO be a something like MOX2023 or MOX2, not sure that turris is already considering this… after all we are still waiting for the next omnia and the omnia is a tad older than the MOX…

#29

But, and that might be a stupid question from the nOOb side here…it is not possible just to upgrade the CPU board part without being incompatible with the connected restparts?

I mean, the advantage of a modulair desing could be the fact that one can upgrade specific parts. Not sure if that was the basic concept though

#30

Not sure, if there are replacement SoCs using the same type of bus as the current MOXen that would be an elegant up-date path.

1 Like
#31

btw, is anyone here running a SFTP server behind the MOX, like for example a Synology NAS?
Since i have some weird behavior with the MOX capping the output ( SYNO> WAN) to a max of 11 Mibs.
Tried 2 different syno’s with same result…

#32

This topic was automatically closed after 60 days. New replies are no longer allowed.