New TCP congestion algorithm - BBR
-
@Sergei_Shablovsky said in New TCP congestion algorithm - BBR:
net.inet.tcp.functions_available
It would only work if the tcp_rack kernel module is present and it isn't included in 2.7.2.
Additionally pfSense use the gui system tunables instead of /etc/sysctl.conf so the persistent part would not work.
-
@stephenw10 said in New TCP congestion algorithm - BBR:
@Sergei_Shablovsky said in New TCP congestion algorithm - BBR:
net.inet.tcp.functions_available
It would only work if the tcp_rack kernel module is present and it isn't included in 2.7.2.
So, if I understand You correctly, we return to old queston "when Netgate compile kernel with CDG/BBR2/RACK/QUICK support for pfSense+ or CE ??!!!!" or workaround "how to recompile kernel with CDG/BBR2/RACK/QUICK support for pfSense CE" (as we see discussion abowe) ?
Additionally pfSense use the gui system tunables instead of /etc/sysctl.conf so the persistent part would not work.
No problem to modifying script to editing "system tunables" in config.xml ...:)
-
@w0w said in New TCP congestion algorithm - BBR:
@mikehu44444 said in New TCP congestion algorithm - BBR:
https://github.com/mikehu404/pfsense-bbr
Great work!
In reality, there are very few situations where pfSense acts as a client or a server.
It would be nice to re-test the pfSense client's speed, but not pfSense itself.
I don't think we will see any difference. The tuning that is applicable should be applied to all FreeBSD kernels during the test.With all appreciation to Your R&D, but let's to make some small note that may explain so big difference in numbers:
-
Mostly, ISPs installing own separate Speedtest OOKLA server on their infrastructure (and sometime even routing all requests from users to own Seedtest server, if this possible) : because OOKLA Speedtest app (desktop, mobile or webapp) AUTOMATICALLY using the nearest Speedtest's server (selected by lowest lathency) and 90%+ OF USERS NOT CHOOSING OTHER TEST SERVER IN OTHER LOCATION in app settings, - THE SPEEDTEST's RESULTS WOULD BE a little INCORRECT (5-25%) from real;
-
Mostly, ISP making their own "Speedtest page" where in code it's own Speedtest's server are HARDLY PRE-SELECTED. So, the situation goes to item.1 above;
-
Because A LOT OF ISPs (in some US states (probably in a middle states or with less developed infrastucture states, in Western Europe, in MIddle Asia this percentage may be 80-95%) using core network equipment, and equipment on aggregate levels with simply OLD CONGESTION CONTROL (CC) like Tahoe, Reno, Westwood+, CUBIC, etc., this mean THE MODERN TCP/IP CC protocols WOULD BE ALWAYS WINNER IN REAL LIFE (probably NEXT 10-20years, up to the time, when MOST of equipment/os switch to modern TCP/IP CC, and then would be "next round").
-
So, ordinary unmodified FreeBSD v.14+ by default using CUBIC as the default TCP/IP CC algorithm. Previous versions used New Reno. However, FreeBSD supports a number of other choices.
P.S.
May be this is one of reasons why Netgate till now not including Speedtest (even as separate pkg) in CE or + version.
Because very hardly to explain to ordinary users "what this pesky Speedtest measurements mean".BUT I HOPE one day I have a time to make separate pkg for Speedtest, FAST, Librespeed and even smokeping to giving ability to all pfSense users flawlessly using this tools to measure WAN UPLINKs on initial pfSense setup at home or small office.
-
-
@Sergei_Shablovsky said in New TCP congestion algorithm - BBR:
May be this is one of reasons why Netgate till now not including Speedtest (even as separate pkg) in CE or + version.
Because very hardly to explain to ordinary users "what this pesky Speedtest measurements mean".
BUT I HOPE one day I have a time to make separate pkg for Speedtest, FAST, Librespeed and even smokeping to giving ability to all pfSense users flawlessly using this tools to measure WAN UPLINKs on initial pfSense setup at home or small office.Honestly, I don't know why WAN speeds need to be measured on the firewall. By its nature, pfSense is simply not designed for this, as it works in a pass-through mode, meaning the maximum speeds should be on the client PCs connected to pfSense, not the other way around. Of course, it would be great if the speeds were the same on both pfSense and the clients, but as I understand it, this is impossible and unnecessary overall.
As for BBR, I would conduct tests if I had the opportunity, but I'm not sure if it would offer any advantages in my configuration. Probably none.
I can't recall the exact reason why Netgate didn't even consider including this algorithm and compiling the necessary options in the kernel. Compatibility and stability, obviously, @stephenw10?
-
@w0w said in New TCP congestion algorithm - BBR:
@Sergei_Shablovsky said in New TCP congestion algorithm - BBR:
May be this is one of reasons why Netgate till now not including Speedtest (even as separate pkg) in CE or + version.
Because very hardly to explain to ordinary users "what this pesky Speedtest measurements mean".
BUT I HOPE one day I have a time to make separate pkg for Speedtest, FAST, Librespeed and even smokeping to giving ability to all pfSense users flawlessly using this tools to measure WAN UPLINKs on initial pfSense setup at home or small office.Honestly, I don't know why WAN speeds need to be measured on the firewall. By its nature, pfSense is simply not designed for this, as it works in a pass-through mode, meaning the maximum speeds should be on the client PCs connected to pfSense, not the other way around.
Honestly, please spend 20min for searching in this pfSense Users Forum how much times users asking again and again "why my speeed to internet so low..."! A LOT OF!
Of course, part of this questions are from newbies which not read pfSense docs carefully and because of this make some misconfiguration OR just not really understanding all ground aspects about Networking.But there are also a common PURE QUESTION: what is my UPLINK TO ISP SPEED?
@w0w, please told me, are YOU PERSONALLY not interested in to know WHAT IS REAL WAN UPLINK SPEED (i mean between Your WAN Eth port and Your ISP)?
Because may be something in ISP's hardware, cables, aggregate switches, etc. that IN YOUR CERTAIN CASE GIVE YOU LESS BANDWIDTH that you pay for?And how for example personally You measure UPLINK TO ISP BANDWITH ?
Of course, it would be great if the speeds were the same on both pfSense and the clients, but as I understand it, this is impossible and unnecessary overall.
I not wrote about that. (That's not possible at all technically for a couple of reasons.)
As for BBR, I would conduct tests if I had the opportunity, but I'm not sure if it would offer any advantages in my configuration. Probably none.
Thank You so much! I'm waiting ! :)
I can't recall the exact reason why Netgate didn't even consider including this algorithm and compiling the necessary options in the kernel. Compatibility and stability, obviously, @stephenw10?
Stability? Compability ? Please explain, what You are about in details?
CDG, BBR/BBR2, RACK, QUIC working last 5 years with no any issues in a lot of facilities and DC.And I still thinking the reason why Netgate not including the CDG, BBR/BBR2, RACK, QUIC support in their pfSense only because not making R&D bot on simulated (TRex or similar utility) and a real traffic and obtain a certain dataset that quickly pushing it to take a decision which CC to compile in kernel.
This decision also follow to impact on next 2(two) IMPORTANT items:
-
Is current Netgate applience (not U-rack, small models for home / small office use) able to working well with may be increased workload on NICs controllers and whole CPU/RAM/bus ?
Changing the factory's production process in current economical situation may be not good way. And of coarse this is INVESTING IN A FUTURE with NO IMMEDIATELY REVENUE RISE UP. -
Because "Each congestion control algorithm is implemented as a loadable kernel module." would be a some sort of problem to EXPLAIN TO END USERS which option (CDG, BBR/BBR2, RACK, QUIC) make by default and (more important!) WHY USER MAY NEED TOCHANGE this DEFAULT CC.
As we here all see, 90%+ of network appliances users in SOHO become less and less educated, and even more and more stupid...
P.S.
Of what we are speaking? Look at reality: this tread are in "Off-topic section", other threads related to CC on this pfSense Users Forum are with significant small views.
At the same moment this 'small' changing the CC in pfSense may increasing bandwith utilisation, speed, etc. to + 10-30% (depend on setup and use case). -
-
Good evening everyone
Did quick BBR and no-BBR tests, and the theory is absolutely confirmed. Even if you want to test your ISP speed with BBR on pfSense, you might not get the full speed, but it will be very close to it.
There's no benefit on client PC when BBR is active. The difference is statistically negligible, even with a small sample size. -
@mikehu44444
So, what is about tests? -
@w0w
Why You using SOHO SpeedSest (especially in situation where in 2024 must of all ISPs have OWN SPEEDTEST SERVER node installed or CREATE A HI-SPEED/LOW LATENCY routing by policies especially for impressing own clients) instead of TRex (best choice), Fast (more usable for ordinary peoples) or iperf3 (in multi-thread mode, not good and more synthetic tool, but anyway better than Ookla Speedtest) ?????!To be serious, only testing by TRex (both way - from outside and from inside) GIVE YOU ADEQUATE PICTURE OF what happened with Your REAL TRAFFIC.
Not like You type ‘speedtest’ in CLI and have right decisions. Not at all!
P.S.
You even not indicated which parameters of BBR2 on client node, which QoS on router (in the middle, if You use it), which parameters of BBR2 on pfSense’s BSD node, and CE or Plus version of pfSense You use for this tests! -
@Sergei_Shablovsky
Create your own software build, test everything you need, and ensure it meets your requirements. It's beyond my capabilities, and I don't want to waste my time anymore. -
It’s definitely not MY personal requirements, this affect EACH pfSense user. More (in case office/small/middle company in US/Europe ) or less (web surfer from Tanzania, techno-geek at home network or DevOps at home).
But making decision based on wrong testing strategy and wrong instruments -> wrong way and certainly wasting time and effort.
Agree?Before in this thread You wrote:
——
RACK and BBR will mostly have an effect running on endpoints, like streaming servers or tunnel endpoints. Since pfSense is a firewall there are not so many situations when BBR or RACK will give any benefit,
——
TCP congestion control is managed by endpoints (sever and/or client e.g. web browser and web server), so anything not placed on the firewall is not using cognestion control, like newreno or any other.
Endpoint means that firewall iself is an endpoint, then congestion control is applied, otherwise all other traffic is just passed to upstream/downstream interface.
——-I friendly pointing You that this is not correct and by saying “TCP congestion control is managed by endpoints” You show that You not deeply understanding how exactly QUIC (and so-called HTTP/3) working and how overall CC strategy, BSD/NIX TCP stack parameters, NICs parameters, ISPs switches on aggregate levels, ISPs routers (with sophisticated routing policies, shapers and limiters) on core level routers impact on packets flow back and forth between external users and Your application’s server.
And now You make that decision based on … ordinary SpeedTest ? Really wrong way to comparing CCs!
P.S.
Do You know that small (but important) example: Your server’s ~72Mb/s with 1ms ping -> after 1% PL (packet loss) on a user’s “last mile” BECOME ~54Mb/s with 4ms ping ~> after +100ms RTT added by “fat magistral” BECOME 5,7Mb/s with 104ms ping.Only 1% of PL and +100 RTT make Your “magic server’s 72Mb/s” to “5,7Mb/s” !
Imagine, what happened with 2-3% PL and 80-120 RTT ?
This all about YOU NEED MAKE PROFESSIONAL-GRADE MEASUREMENTS WITH RIGHT TOOLS !
