Quote from: Seimus on Today at 02:42:26 AMRule of thumb;
Limit > bellow 10Gbit/s should be around 1000 (usable since 25.7.8)
Flow > If possible set to max 65535
Quote from: cookiemonster on December 01, 2025, 07:09:25 PMI admit I can't understand the current way to use the "limit" note of the docs, the reference to the bug.Prior OPN 25.7.8 there was a BUG that caused a CPU hogging due to excessive logging caused when the limit queue is exceeded. So the advice was to let Limit blank. Franco did FIX this (well at least on OPN side). So now is safe and beneficial to use the Limit queue and set it to 1000 for Speeds under 10Gbit/s.
Quote from: pfry on December 01, 2025, 08:18:47 PMI'd think a simple fair queue with no shaper would be the best option for you. I don't know the best way to accomplish that - perhaps open the pipe beyond 520Mb/s (toward single-station LAN speed).
Quote from: pfry on December 01, 2025, 08:18:47 PMI haven't looked at the fq-codel implementation in... a while. The one I recall used a flow hash, and you could set the number of bits (up to 16, I believe).FQ_C creates internal flow queues per 5-tuple using a HASH. There are examples where stochastic nature of hashing, multiple flows may end up being hashed into the same slot. This can be controlled by the flow parameter in FQ_C.
Quote from: pfry on December 01, 2025, 08:18:47 PMIt looks like the ipfw implementation has that limit (65536). I'd think more can't hurt - fewer (potential) collisions. I wouldn't expect any negatives, but you never can tell.This is a very bad idea if we speak about the "limit parameter". Limit is effectively the Queue size for the internal flows created by FQ_C. If you have a long Queue, but you are not able to process the packets in the Queue in time you create latency. FQ_C because its an AQM, measure sojourn time of each packet in the queue, and if it exceeds it either marks it or drops. But having to big of a queue is still overall bad. We want to TAIL drop packets when we can not handle them and not store them.
Quote from: pfry on December 01, 2025, 08:18:47 PMPIE just sounds like a RED implementation - I can't see that it'd have much if any effect, as I wouldn't expect your queue depths/times to reach discard levels.I really don't want to go into PIE to much e.g FQ_PIE, it work similar to FQ_C, but it has different use case, so I will say this:
Pie
- Probabilistic, gradual
- Usage in ISP networks, broadband, general traffic
Codel
- Adaptive, based on packet age
- Low-latency applications, real-time traffic
Quote from: meyergru on Today at 12:44:21 AMAlso, some devices look for firmware updates, can order consumables in advance a.s.o., let alone collect statistics and push that to the manufacturer without anyone knowing.Indeed, that's what I was implicitly hinting at, and rather than ordering consumables I'd rather have it send a mail to the admin instead, and use a local NTP server, but I accept that the default configuration might be catering to the person who plops down the device, pops in some cables and then expects it to work until it's decommissioned. Of course, this affords privacy and security only to those select "elites" who at least know what might be happening and therefore might try to prevent them.
There are good reasons to put "smart" devices into a separate VLAN.
Quote from: pfry on December 01, 2025, 08:18:47 PMIs a downstream shaper (particularly a single queue) likely to have the effect you want? I used downstream shapers in the past, but my purpose was to control offered load by adding latency, using multiple queues on a CBQ shaper. I didn't bother after my link passed 10Mb; it did help at 6-10Mb.You mean set it up as per the docs https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html ?
I'd think a simple fair queue with no shaper would be the best option for you. I don't know the best way to accomplish that - perhaps open the pipe beyond 520Mb/s (toward single-station LAN speed). I haven't looked at the fq-codel implementation in... a while. The one I recall used a flow hash, and you could set the number of bits (up to 16, I believe). It looks like the ipfw implementation has that limit (65536). I'd think more can't hurt - fewer (potential) collisions. I wouldn't expect any negatives, but you never can tell. PIE just sounds like a RED implementation - I can't see that it'd have much if any effect, as I wouldn't expect your queue depths/times to reach discard levels.
Of course, you could have upstream issues, at any point in the path.