Traffic Shaper Drops qOthersDownH



  • Hi there,

    please see my attached screenshots. Why am I getting these drops? What can I do to fine-tune my setting? I am running 1.2.3-RC3 nanobsd embedded version.

    Thanks for any hints…
    ![Bildschirmfoto 2009-12-07 um 18.48.39.png](/public/imported_attachments/1/Bildschirmfoto 2009-12-07 um 18.48.39.png)
    ![Bildschirmfoto 2009-12-07 um 18.48.39.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2009-12-07 um 18.48.39.png_thumb)
    ![Bildschirmfoto 2009-12-07 um 18.48.58.png](/public/imported_attachments/1/Bildschirmfoto 2009-12-07 um 18.48.58.png)
    ![Bildschirmfoto 2009-12-07 um 18.48.58.png_thumb](/public/imported_attachments/1/Bildschirmfoto 2009-12-07 um 18.48.58.png_thumb)



  • Now I also get drops in qwandef and qp2pup, but the p2p queue doesn’t matter….



  • It doesn’t matter which way I configure the shaper, I am always getting drops. Can’t be that the shaper is working for all of you guys!? Nobody has got a problem with it?



  • @jlepthien:

    Hi there,

    please see my attached screenshots. Why am I getting these drops? What can I do to fine-tune my setting? I am running 1.2.3-RC3 nanobsd embedded version.

    Thanks for any hints…

    I’m getting the same thing.  In fact, if my speed test traffic gets piped into the qLanDef/qWanDef I get no drops and better speed.  If the speed test traffic gets piped into    qOthersUpH/qOthersDownH there are drops and therefore the traffic slows down.  It’s very weird the High priority traffic runs slower than the default traffic!  The only difference between the two queues is - default RED & ECN is enabled on the high priority queues and not on default queues.  Disabling RED & ECN on the high priority queue does not eliminate the drops or speed decrease.



  • Thanks for the info. So I am not the only one 😉
    Any word from the pfSense Team?



  • Any help would be really appreciated….

    Thanks 😉



  • try this,
    adjust ur qwanack to 50%, n qlanack to 50%



  • I will try that and report back. Thanks.



  • Still getting lots of drops. See attached screenshot…




  • 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.



  • @danswartz:

    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.



  • @danswartz:

    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…



  • @SlickNetAaron:

    @danswartz:

    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


Locked
 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy