The traffic download limit only applies half of what I give it. why?
-
@HLPPC Like others, I've just doubled the download speed in the limiters until someone finds the cause and can fix it.
Not sure why but this post get marked as spam so just typing some stuff in the hope that it get thru that way
-
I'm facing this issue too. Only worse! I have 2 wan connections grouped with load balance. For upload, I have to set half the desired speed (50 to get 100). For download double the desired speed (500 to get 250). This was reported from 9 months but has not been fixed until now.
-
@nhs7000 It happens when I run FQ_codel on LAN interfaces, either down on LAN and up on LAN or (like DDWRT) down on LAN and up on WAN. It has to do with how many times the packets are passed through the firewall and maybe how many times they are hashed. Sometimes I get unseen acknowledgements with TCP running fq_codel on any interface, and UDP checksum errors other times. I have even had videogames have their graphics pipes break because of what I think are these sorts of error, causing my TV to show two pictures at once. A few times I thought I overcame the issue but nope. I have even seen fqcodel start fragmenting UDP connections :P
-
@HLPPC FQ_Codel and DNS don't seem to get along either. Lots of new DNS connections can really ruin healthy priority, and localhost stepping out to do whatever it wants with NAT doesn't help either. I think unbound commonly interferes with fqcodel. I have tried keeping it away from fqcodel entirely but sometimes UDP packets seem to be in the same internal priority as UDP, especially if the DNS is over HTTPS and the UDP packets are riding that connection's sawtooth.
-
@HLPPC Thank you for your reply, I'm not even using FQ_codel, I used Tail Drop with the default scheduler worse case weighted fair queueing on the LAN interface. As some users had previously noted, version 2.6 didn't have this problem.
Maybe the new FreeBSD 14 caused some conflicts I'm not sure, but it should be an easy problem to reproduce and detect.
-
After trying it...
I end up using the limiter on Floating Rules.
I use Taildrop - Codel - Taildrop
Then put the queue on Floating rules with Out direction..
I finally get the expected upload / download results.I think that has to be like that from 2.7.2
-
S SteveITS referenced this topic on
-
Is it a bug or configuration change?
I have the same problem.
-
-
Has to be a bug. After updating (which was a task in and of itself) from 2.7.0 my limiters aren't working as before. With a good amount of testing, I ended up basically doubling the limiters bandwidth to reach what it should be limiting to. Hopefully they find the reason for it, what a pain in the butt last few days.
-
I can confirm the same issue on six different pfSense firewalls. This is for sure a bug somewhere in the conversion.
Here what I experienced:
10240 Mbit/s limit --> Traffic does not pass anymore, like a blocking rule
50 Mbit/s limit --> about 46 Mbit/s
51200 Kbit/s limit --> about 49 Mbit/s
52428800 Bit/s limit --> about 50 Mbit/sCan others confirm the same?
Edit: Found another thread with the same issue, that the set limit does not match the applied limit.
-
I have since situated my limiters and have got them working properly now. Before upgrading to 2.7.2 (which was a task due to a bug) I installed an additional fail-over wan, which didn't have rules for the limiters. My rules were set per lan/vlan to use my gateway group and it's respective limiter. I had only made limiters for upload/download. My problem seemed to situate once I put my rules into the floating ruleset, made my limiters simple tail-drop with worst-case waieghted fair queueing, then made a queue for each limiter utilizing PIE with ecn checked. The rules used default gateway rather than gateway group (pfSense gateway is set to use the gateway group rather now) and the limiters were the actual queues I set up under the limiters. Hope it helps someone out there.
