No problem!  I hope it helps!  One of my favorite speed testing sites is http://www.speedtest.net It's very reliable, and it stores results for your IP.  You set your download AND upload to 2700?  This is a good starting point, and you may be able to fine tune it some more by averaging your capacity over time.  Again, if this is a business you are setting this up for, make sure you also know if the phones use the paired T1's. A good stress test on your shaper is to ALLOW P2P traffic and attempt to download multiple Ubuntu (for example) torrents.  The goal is to saturate your pipe and to start sending out as many ACKs as possible to make sure you have everything tuned correctly.  You have the added benefit of also testing out other queue reservations, to make sure the saturation isn't bringing everything else down to it's knees.  (Like system related traffic, mail server, web server, vpn server, etc)  P2P traffic is a good way to do this, since you are connected to so many peers with a lot of data coming down. Then when you're done, PENALIZE P2P traffic in it's lower priority queue.  :)

actually i didnt set the penalty box in the wizard so can any1 tell me how to specify it manually now?

Do you mean you lose internet connectivity when enabling traffic shaping? used the wizard? what about your firewall rules? any more info. will help for sure.

@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. "