Traffic Shaper Drops qOthersDownH
-
But this makes no sense - you have no control over what gets put into the pipe at the ISP's end, only when you are uploading data. The only thing you can really control download-wise is the total bandwidth.
-
Okay. Then maybe I entered to small Mbit/s in my shaper config? How do you test your actual download speed and what are the numbers you enter in the wizard? 10% less of your real bandwidth?
-
I usually just put the supposed download speed, since it doesn't really matter that much (to me at least). 90% of usable speed seems reasonable.
-
No I tested again. I put in the supposed speed and raised qwanacks to 65% and qothersdownh to 70% started a torrent and a http download. Now the queues look like on the new screenshot. I get only some drops in my http traffic which is good, but still a lot in my p2p queue. Isn't this bad? But as you told me this is the only method to throttle the download speed?
Thanks guys…
 -
dropping packets is one of the two ways a shaper can slow down inbound traffic. dropped packets are not inherently bad for TCP traffic. unless you have an actual performance issue here, you are (IMO) spending a lot of time to try (futilely) to solve an intractable problem.
-
dropping packets is one of the two ways a shaper can slow down inbound traffic. dropped packets are not inherently bad for TCP traffic. unless you have an actual performance issue here, you are (IMO) spending a lot of time to try (futilely) to solve an intractable problem.
He's having the same problem I'm having. It's dropping packets when there is no congestion and well below the max pipe bandwidth. In order for my ~30mb connection to be fully utilized I have to tell the shaper I have a 40mb connection. If I set it to 35mb it drops packets and maxes me out at 25mb. If I set to 30mb I max out at about 17/18mb.
It's dropping packets when I'm using a paltry 64kb bandwidth on the "high priority" queue, but if traffic gets routed to the "others" low priority queue no packets get dropped. It's functioning in reverse, and shaping (dropping) far too early.
Also, if I try to set the upper limit on the root queue, it is 100% ineffective. I could set upper limit to be 1mb and it will still allow 30mb to cross on the wire. (yes, I've tested for both directions.) The shaper is pretty much not functioning correctly.
lastly, there are other ways to shape download - by delaying packet delivery which will cause the app to back off. see http://www.netequalizer.com/tsfaq.htm
-
Probably the shaper will be better in 2.0 which will hopefully be released next year…
-
I have got another question concerning the rules of the shaper. The wizards creates rules based on LAN net. Can I simply change LAN net to a single IP? I want some rules to apply only for one IP…
-
dropping packets is one of the two ways a shaper can slow down inbound traffic. dropped packets are not inherently bad for TCP traffic. unless you have an actual performance issue here, you are (IMO) spending a lot of time to try (futilely) to solve an intractable problem.
He's having the same problem I'm having. It's dropping packets when there is no congestion and well below the max pipe bandwidth. In order for my ~30mb connection to be fully utilized I have to tell the shaper I have a 40mb connection. If I set it to 35mb it drops packets and maxes me out at 25mb. If I set to 30mb I max out at about 17/18mb.
It's dropping packets when I'm using a paltry 64kb bandwidth on the "high priority" queue, but if traffic gets routed to the "others" low priority queue no packets get dropped. It's functioning in reverse, and shaping (dropping) far too early.
Also, if I try to set the upper limit on the root queue, it is 100% ineffective. I could set upper limit to be 1mb and it will still allow 30mb to cross on the wire. (yes, I've tested for both directions.) The shaper is pretty much not functioning correctly.
lastly, there are other ways to shape download - by delaying packet delivery which will cause the app to back off. see http://www.netequalizer.com/tsfaq.htm
Yeah, I'm aware of that technique. You have provided a better (more convincing) description of what is wrong. I would open a ticket on redmine.pfsense.org.
-
Having the same problem, the strange part is that it works fine for about a day or so but after that it starts dropping qOthersdownH and thus giving qP2p higher priority(internet pages either timeout or load slow).
The only thing that helps is restarting pfsense or the traffic shaper, can't find the problem as there are no errors in the logs and nothing has changed in the configs in the meantime.
This is with pfsense 1.2.3 final(4GB nanobsd) and it worked ok in 1.2.2 and in some of the early 1.2.3 builds, tried alot of different traffic shaper settings(lowering/raising bandwith for instance) but with no luck so far. -
i too suffer from this issue, and i thought its just me… with aggressive apps, drops could sometimes reach 5 digits.. it doesnt matter if qlimit is specified or not, but it happens either way.
would be good to hear feedback from a dev