Netgate 2100 PPPoE Throughput
-
After lots of searching forums I was never able to find a conclusive first-hand experience regarding XGS-PON service via PPPoE on the 2100.
I've been using a 300/30 DOCSIS cable connection for years with no problems on this appliance. Recently, fibre service was installed in my neighbourhood. Unfortunately, the incumbent telco continues to use PPPoE, offering up to 3gbps symmetrical on their own equipment with hardware acceleration. I ordered 500/500mbps instead.
Running a speed test with my minimal firewall rules, I'm seeing about 430mbps down and 450mbps up, which is pretty good for this price point, I think, on supported hardware. I confirmed the telco-supplied router will do the full 500/500. I haven't tried any tuning, since I think I'm getting close to the packet processing available on the 2100 even over DHCP.
I hope that helps, in case you are shopping for a new appliance.
-
Try setting 'net.isr.dispatch' to
deferred.
See: https://docs.netgate.com/pfsense/en/latest/hardware/tune.html#pppoe-with-multi-queue-nicsThe mvneta NICs in the 2100 are not multi-queue but that can make a significant difference.
-
@stephenw10 Thanks, I didn't realize those settings would apply to the 2100.
After setting it to "deferred", I'm getting around 300mbps down and over 500mbps up. Those could be daytime congestion figures, however. I'll keep an eye on it.
-
Hmm, interesting. Let us know if that varies.
-
Ok -
I'm seeing consistently in the 350 down / 410 up range. I had to re-activate a codel limiter (set to 500/500) because watchdog services would drop once my upload went up to around 500 (and seemed to overwhelm the SoC of 2100).
If there's anything else you want me to try, please advise. This is not bad and it sounds like there are PPPoE enhancements coming down the road.
-
Hmm, and with that you are back to 430/450Mbps?
-
@Lugie said in Netgate 2100 PPPoE Throughput:
re-activate a codel limiter (set to 500/500)
Drifting on past...did you by chance use FQ_CODEL? I tried that once and it did notably cut my bandwidth on a 2100, as opposed to other shaping. As I recall it wasn't maxed out of CPU so I thought it odd, but I did not dig into it much, just reverted.
More recently, on a 2100 with Suricata running it seemed to max out around 430 Mbps (at 100% CPU), whereas without Suricata 550 is not a problem.
-
@SteveITS Yes - FQ_CODEL with Tail Drop. That's what I was using for VDSL 25/6 and didn't think was necessary anymore (now set to 500/500). But turning it off seemed to stress the 2100 on heavy uploads.
I've now turned off the limiter and I'm getting much better results with no Watchdog warnings. Weird. Perhaps I need to fiddle with the queue length? Or something else?
Latest Speedtest.net result (no limiter floating rule) is: 529d/486u. I don't have any intensive packages active (no Suricata or PF Blocker). Speedtest caused the CPU to spike to 88% (with the web interface open).
-
@Lugie So turning FQ_CODEL off was an improvement? That's what I was seeing. But PRIQ for instance doesn't seem to have the same issue. I was just prioritizing voice/UDP. Like I said I didn't really investigate as I was just experimenting. I just kinda assumed something weird between FQ_CODEL and 2100/ARM and went back to PRIQ. Vaguely I think it was around 100 Mbps less with FQ_CODEL.
My eero's periodic speed tests are around 540-556 Mbps download.
The dashboard will use CPU if it's updating widgets.
-
@SteveITS Yes, turning it off got me better download numbers, especially (100mb+). I didn't think that the NICs on this device supported anything other than limiters? I remember reading that somewhere when I was shopping for it. I was using some other traffic-based optimization when I had an intel-based pfSense installation.
My use of limiters was mainly for reducing buffer-bloat and preventing any particular device on the LAN from saturating the connection (this was on 25/6 VDSL). Perhaps I don't need any traffic management any more. My buffer-bloat testing gives me an "A"-rating now, just as-is. That wouldn't have been possible without the limiter on VDSL/cable in the past.
I'll have to investigate CODEL parameters a bit when used with a higher speed connection like this.
-
In the end, I couldn't get consistently good latency without setting the limiter to 400 down and 350 up with a queue length of 2500. Obviously this cuts into my throughput significantly. I'm going to leave it off until I see evidence that buffer bloat is a real problem on my network. From what I see on other forums, people with fibre connections just don't use limiters anymore.
-
@Lugie said in Netgate 2100 PPPoE Throughput:
From what I see on other forums, people with fibre connections just don't use limiters anymore.
If you have a symmetrical (or very close to symmetrical) connection, then IMHO "buffer bloat" is kind of a solution searching for a problem. It was much more of an actual issue with highly asymmetrical connections such as the early DSL technology. It can also still be an issue with cable ISPs that offer say Gig download speeds but maybe only a few tens of megabits/sec upload speeds. For example, before my symmetrical Gigabit fiber connection I had 1 Gig down and 50 megabits/sec up from a local cable ISP. The actual speed tests wound up averaging about 800 or so down and 49-51 up. That was an asymmetrical connection.
Not saying Limiters don't have their place in certain specialized applications, but for most home users with a symmetrical connection (where download and upload speeds are the same), they are not needed.
