fq_codel 2.4.4 ping timed when speedtesting
-
Tried to play a little with codel using this guide:
https://www.youtube.com/watch?v=iXqExAALzR8
I saw ping timeouts while running a continuous ping and started a speedtest. I have tried to change the queue to (50, 500,1000, 2000, 5000, 10000) but this didn't help.
Reply from 91.214.22.65: bytes=32 time=4ms TTL=241
Reply from 91.214.22.65: bytes=32 time=4ms TTL=241
Reply from 91.214.22.65: bytes=32 time=4ms TTL=241
Reply from 91.214.22.65: bytes=32 time=4ms TTL=241
Reply from 91.214.22.65: bytes=32 time=4ms TTL=241
Reply from 91.214.22.65: bytes=32 time=4ms TTL=241
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 91.214.22.65: bytes=32 time=5ms TTL=241
Reply from 91.214.22.65: bytes=32 time=6ms TTL=241
Reply from 91.214.22.65: bytes=32 time=5ms TTL=241
Reply from 91.214.22.65: bytes=32 time=5ms TTL=241
Reply from 91.214.22.65: bytes=32 time=5ms TTL=241
Reply from 91.214.22.65: bytes=32 time=6ms TTL=241
Reply from 91.214.22.65: bytes=32 time=5ms TTL=241
Reply from 91.214.22.65: bytes=32 time=4ms TTL=241So is this to be expected or do anyone know the issue?
300mbit/300mbit fiber connection.
pfsense 2.4.4 barebone Asus UN68U (i5-8250u, intel nics, router on a stick VLAN's) -
This is something that others are seeing, including myself. I think the research is ongoing. I had disabled this protocol from the rule which classifies the ICMP traffic into an FQ_CODEL-associated limiter, reset states, and saw ICMP traffic move without issue afterwards.
-
I also began searching in the other topics and can see someones with similar issues and a lot of wall of texts :)
So much for: CoDel is a novel “no knobs”, “just works”, “handles variable bandwidth and RTT”, and simple AQM algorithm. :)
So I guess we should let the experts figure this one out.
-
Do you see the issues with ICMP only when the limiters are applied to floating rules on the WAN interface? If you apply them to the LAN side do you also see the issue with Ping?
Also, does the reducing the quantum on fq_codel help at all? I can see that as temporary fix potentially until the real issue is resolved.
Also, just a couple general notes:
- Sub queues under the limiter are not required to get fq_codel to work unless, you have a specific need to create multiple sub queues. You can create them still, but it may be a bit redundant.
- If you do use limiter sub queues and enable Codel on them, you don't really need to enable Codel as well for the limiter under Active Queue Management.
- Since fq_codel creates per flow Codel managed queues, I'm still not sure what the benefit is of enabling Codel AQM on the input queue to the fq_codel scheduler (whether on the limiter itself or on a limiter sub queue). In theory, it should work fine without AQM on the limiter input queue. With other schedulers (e.g. RR, QFQ, etc.) enabling AQM on the input queue makes sense since those schedulers are just pure schedulers, and don't perform any AQM like fq_codel. If anyone has any performance comparisons of AQM on the input queue vs. no AQM, it would be great to see them.
Hope this helps.
-
Tried applying to LAN with same result
Tried lowered quantum to 300 (not sure which value i should use but found another topic with one using 300)I have to read more about the subject before I can answer the rest. I just tried it out for fun to see what it could do. My connection does't suffer that much from bufferbloat but I have a few friends that does and wanted to see if this could help them out at some point.