Traffic Shaper Drops qOthersDownH
-
where did the others queues come from? how did you configure the shaper?
-
What do you mean by come from? I simply used the wizard…
After that I tried to adjust the percentages in the queues, that's all I did...These are my http(s) queues from what I understand. They were named like this from the beginning...
-
I don't have the "others" queues, which is why I asked. I know you used the wizard - what I was getting at was: what did you fill in in all the screens?
-
what ports drops?? http or https ?
can u set qp2pup n qp2pdown to priority 2 , of course after u set qotherupl n qotherdownl to 3.
then, move the qp2p after qother(down/up)l… so u can get the priority 0 - 1 -7 - 4 - 3 - 2 , and if u want, try move the priority to the bottom list too.
sorry, if this cann't help either.
-
I don't have the "others" queues, which is why I asked. I know you used the wizard - what I was getting at was: what did you fill in in all the screens?
Are you using 1.2.3, too? I am using the embedded version.
-
yes, on 1.2.3 here. it would help to know what the queues are and how the traffic is being directed to them.
-
Hmm. I will check this out again. I have p2p catch-all activated, but otherwise nothing special. I will re-run the wizard with all set to standard and see what happens.
-
I re-run the wizard again but it does not seem to be any better….
The only things I changed in the wizard is that I use p2p-catchall and I put http(s) and IPSec traffic on higher priority. Now have a look at my queues, I still have the others queues so that seems to be right.
Anything else I can do? I do not get it. Why all the drops? There is no other traffic at the moment, just a big iTunes download, so there shouldn't be any of these...
-
And here is a screenshot of my queues…
-
Curious about something. Is there actually a problem, or you just want to know why the drops happen? By "problem", I mean slow/stalled downloads? The only way pfsense can shape inbound traffic is to drop packets when the speed gets too high, which will slow down the sender.
-
Well, the "problem" is, that the speed is slower, when traffic shaping is enabled and I download via http. This should not happen. I want all speed for http traffic when it arrives. I do not do anything besides downloading via http when the drops happen…
-
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…
![Bildschirmfoto 2009-12-21 um 21.13.05.png](/public/imported_attachments/1/Bildschirmfoto 2009-12-21 um 21.13.05.png)
![Bildschirmfoto 2009-12-21 um 21.13.05.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2009-12-21 um 21.13.05.png_thumb) -
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.