25.03 beta - Bufferbloat / FQ CoDel issues
-
@RobbieTT said in 25.03 beta - Bufferbloat / FQ CoDel issues:
Working fast.com harder doesn't really change my results. Presumably because the download and upload sessions are sequential:
They are.
The reasons is : a massive upload will not only saturation the upload pipe, but also use "a lot of" the download pipe.
After all, every TCP packet (about 1500 bytes in size) has to be acknowledged by an downstream "ACK", which will have the size of a minimal TCP ACK packet, or 46 bytes.
This means, you would lose 3 %. -
@Gertjan said in 25.03 beta - Bufferbloat / FQ CoDel issues:
@RobbieTT said in 25.03 beta - Bufferbloat / FQ CoDel issues:
Working fast.com harder doesn't really change my results. Presumably because the download and upload sessions are sequential:
They are.
The query is between a test format that runs upload and download stress tests in parallel and one that does it sequentially, nothing about packet sizes, TCP or overheads.
Your description of how every packet is ack'ed or the actual size of packets is not that relevant anymore; time has moved on in the age of IPv6 TCP, IPv4 UDP or even QUIC. The majority of my traffic is IPv6, including for the testing above, with many 'continuing' packets per Ack.
️ -
Humm.
"Packets size" determines speed. Like : how bigger and more there are, the faster the pipe fills up.IPv6 or IPv4 or something else : that close to irrelevant imho
-
No, speed is latency.
The 'pipe' is bandwidth.
The 'pipe' can be 'filled' with data, overheads, acks, padding and, unfortunately, the additional dead space of latency and buffering. A 'pipe' can be saturated well before it hits its bandwidth limits. This can be managed somewhat by techniques such as FQ_CoDel to shape throughput into the 'goodput' of the data we actually want to move.
But this thread is not about that, other than the exerting some existing methods of balancing them. It is about a shift in pfSense performance with the new pppoe backend that is in beta and the apparent impact on FQ_CoDel over multiple (active pppoe) cores.
The forum is full of threads where you have inserted yourself without understanding the topic, before you derail it by stating stuff that is both not relevant and often incorrect.
If you have nothing to offer on the subject or even have a relevant question to ask then try not to post. If you want to debate stuff of your choosing then start a thread on that topic in the correct place.
Hope that helps matters.
️ -
@RobbieTT said in 25.03 beta - Bufferbloat / FQ CoDel issues:
methods of balancing them. It is about a shift in pfSense performance with the new pppoe backend that is in beta and the apparent impact on FQ_CoDel over multiple (active pppoe) cores
So it's only on the new backend?
-
Seems so or possibly an interaction with if_pppoe and something else within the new beta.
Regressing to 24.11 again and symptoms vanish. Reverting to the old backend on the beta seems fine too (albeit with the old pppoe issues).
I had to work back again and re-test as I had the test diff patch applied with the revised beta, which drew some doubts on my results for a while. Fat-fingering in a config error when testing is something I try to avoid but you have to admit your mistakes.
I'm waiting for the next beta drop really, to see if the changes also impact the issues I see. Opening up all the cores may just be peeling back something that was already latent and just masked by the old backend process.
I did do a couple of tests that suggests the upload fq_codel settings may need adjusting against a different workload for if_pppoe; but too early to be sure.
I'm also being nudged to try Kea again, as apparently it has matured a bit since its launch.
️ -
R RobbieTT referenced this topic
