@dvserg: @Still: I got the same issue here, qOthersDownH is moving SOMETIMES but max. value i saw was about 32kbit/s , othertimes am browing the web and dont see it move at all. I already tried to edit the rules making it 3128 instead of 80, same results. any input is appreciated. You must use squid bandwidth option. Squid traffic can't be catch by traffic shaper rules. Do you mean squid traffic managment? if so then yes i do for some specific extensions, so should i enable throttling for all traffic so can TS do its job? thanks for your attention and reply.

is anyone out there?  :-\

My problem may not be traffic related, but possibly a hardware incompatibility. When I go to the webui and bring up the traffic shaper, my pings to the internal interface of the pfSense increase in latency.  You can see the period before I click on the traffic shaper, 1ms.  Then while the rules are all loading the latency increases substantially.  Then when the rules are done loading, the latency drops back to normal. C:\Documents and Settings>ping -t 192.168.3.1 Pinging 192.168.3.1 with 32 bytes of data: Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Reply from 192.168.3.1: bytes=32 time=141ms TTL=64 Reply from 192.168.3.1: bytes=32 time=173ms TTL=64 Reply from 192.168.3.1: bytes=32 time=208ms TTL=64 Reply from 192.168.3.1: bytes=32 time=220ms TTL=64 Reply from 192.168.3.1: bytes=32 time=234ms TTL=64 Reply from 192.168.3.1: bytes=32 time=266ms TTL=64 Reply from 192.168.3.1: bytes=32 time=286ms TTL=64 Reply from 192.168.3.1: bytes=32 time=300ms TTL=64 Reply from 192.168.3.1: bytes=32 time=314ms TTL=64 Reply from 192.168.3.1: bytes=32 time=328ms TTL=64 Reply from 192.168.3.1: bytes=32 time=329ms TTL=64 Reply from 192.168.3.1: bytes=32 time=359ms TTL=64 Reply from 192.168.3.1: bytes=32 time=361ms TTL=64 Reply from 192.168.3.1: bytes=32 time=366ms TTL=64 Reply from 192.168.3.1: bytes=32 time=398ms TTL=64 Reply from 192.168.3.1: bytes=32 time=403ms TTL=64 Reply from 192.168.3.1: bytes=32 time=410ms TTL=64 Reply from 192.168.3.1: bytes=32 time=409ms TTL=64 Reply from 192.168.3.1: bytes=32 time=413ms TTL=64 Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Reply from 192.168.3.1: bytes=32 time<1ms TTL=64 Ping statistics for 192.168.3.1:     Packets: Sent = 28, Received = 28, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 0ms, Maximum = 413ms, Average = 211ms I get the same results when pinging the internal interface or the external interface. These tests were run while there was no major data being passed. The hardware is a Dell Optiplex GX150 using the built in NIC and a 3c905b NIC.

I thought the traffic shaper was limited to 2 interfaces only.

Update for today, I switch the web gui access page to https, and the status_queue.php loads almost instantly … Please somebody confirm.

NO.

… may be someone knows a solution or a similar open source product, which can do that (shaping Traffic going through with no need of filtering the traffic)? But please no pure *nix/*bsd solutions as this is too complicated for me ,)

Here is the current config from a cisco switch on our network with the settings for QOS for the phones.  I read somewhere that this is only possible with 1.3…..  Is that true? mls qos map cos-dscp 0 8 16 26 32 46 48 56 mls qos srr-queue input bandwidth 90 10 mls qos srr-queue input threshold 1 8 16 mls qos srr-queue input threshold 2 34 66 mls qos srr-queue input buffers 67 33 mls qos srr-queue input cos-map queue 1 threshold 2  1 mls qos srr-queue input cos-map queue 1 threshold 3  0 mls qos srr-queue input cos-map queue 2 threshold 1  2 mls qos srr-queue input cos-map queue 2 threshold 2  4 6 7 mls qos srr-queue input cos-map queue 2 threshold 3  3 5 mls qos srr-queue input dscp-map queue 1 threshold 2  9 10 11 12 13 14 15 mls qos srr-queue input dscp-map queue 1 threshold 3  0 1 2 3 4 5 6 7 mls qos srr-queue input dscp-map queue 1 threshold 3  32 mls qos srr-queue input dscp-map queue 2 threshold 1  16 17 18 19 20 21 22 23 mls qos srr-queue input dscp-map queue 2 threshold 2  33 34 35 36 37 38 39 48 mls qos srr-queue input dscp-map queue 2 threshold 2  49 50 51 52 53 54 55 56 mls qos srr-queue input dscp-map queue 2 threshold 2  57 58 59 60 61 62 63 mls qos srr-queue input dscp-map queue 2 threshold 3  24 25 26 27 28 29 30 31 mls qos srr-queue input dscp-map queue 2 threshold 3  40 41 42 43 44 45 46 47 mls qos srr-queue output cos-map queue 1 threshold 3  5 mls qos srr-queue output cos-map queue 2 threshold 3  3 6 7 mls qos srr-queue output cos-map queue 3 threshold 3  2 4 mls qos srr-queue output cos-map queue 4 threshold 2  1 mls qos srr-queue output cos-map queue 4 threshold 3  0 mls qos srr-queue output dscp-map queue 1 threshold 3  40 41 42 43 44 45 46 47 mls qos srr-queue output dscp-map queue 2 threshold 3  24 25 26 27 28 29 30 31 mls qos srr-queue output dscp-map queue 2 threshold 3  48 49 50 51 52 53 54 55 mls qos srr-queue output dscp-map queue 2 threshold 3  56 57 58 59 60 61 62 63 mls qos srr-queue output dscp-map queue 3 threshold 3  16 17 18 19 20 21 22 23 mls qos srr-queue output dscp-map queue 3 threshold 3  32 33 34 35 36 37 38 39 mls qos srr-queue output dscp-map queue 4 threshold 1  8 mls qos srr-queue output dscp-map queue 4 threshold 2  9 10 11 12 13 14 15 mls qos srr-queue output dscp-map queue 4 threshold 3  0 1 2 3 4 5 6 7 mls qos queue-set output 1 threshold 1 138 138 92 138 mls qos queue-set output 1 threshold 2 138 138 92 400 mls qos queue-set output 1 threshold 3 36 77 100 318 mls qos queue-set output 1 threshold 4 20 50 67 400 mls qos queue-set output 2 threshold 1 149 149 100 149 mls qos queue-set output 2 threshold 2 118 118 100 235 mls qos queue-set output 2 threshold 3 41 68 100 272 mls qos queue-set output 2 threshold 4 42 72 100 242 mls qos queue-set output 1 buffers 10 10 26 54 mls qos queue-set output 2 buffers 16 6 17 61 mls qos

I was under the impression that with RED, the more bandwidth a person is using, the more likely he will be dropped. http://www.openbsd.org/faq/pf/queueing.html#red "Random Early Detection….When dropping packets, RED randomly chooses which connections to drop packets from. Connections using larger amounts of bandwidth have a higher probability of having their packets dropped. "

OK, That thread looked to me to be the correct. Thirty lashes for the noob…. got there via google, didn't realize it was bounty territory! I have installed 1.2 and setup the traffic shaper.  This is nicely leveling the playing field for the users at 300kbs. The penalty box will be great for really putting the screws to someone if needed! What I am really looking for is a way to let certain IPs bypass the TS ( like the apt mgr) and get full speed.  I would like to use firewall rules generated by scripts in the login portal.  I had figured this out with monowall and dummynet pipes a few years ago.  Not sure how this would work in the pfsense world. I have seen things in the posts here that are close, but addressing different issues.  I just need a push in the right direction.....or told it is not possible. Thanks.

It's quite simple.. Make sure you set your upstream and downstream bandwidth correctly… otherwise your shaping won't work properly. In your shaper rules, set all source and destinations as a wildcard ( * ). Next, edit your qwandef and qlandef queue. Check the box that says "Random Early Detection". Give it a test... Let me know how you make out. /asl

Sorry, there's actually a bit more work you need to do. Once you set your rule's source and dest as *, you need to modify the qwandef and qlandef queue. Edit them and check "Random Early Detection" Save, apply, done!

Ermal look at the trouble that I have to modify SourcePHP.rar.txt on pfsense 2.0

I'll have to try it again. I did do that, but it looked like it was shaping traffic in one dir and not both