@SiGGy:

It's working on the snapshot release :)  Just finishing up tweaking the rules now!

thanks again!

Glad it worked for you.

This is a diffserv value, another implementation to use the same bits in the header like the TOS field. Unfortunately pfSense can't handle these values atm. See http://en.wikipedia.org/wiki/Diffserv

The trafficshaper only works on 2 interfaces currently out of the box, the pppoe users will have a new interface for each connection that is not shaped. At least download won't be shaped. Upload through WAN will be shaped and put in the default queue.

@Gitsum:

Any new progress reports on getting traffic shaping to work with load balancing?

No.

These snapshots are based on a newer version of FreeBSD.  Something must not be agreeing with your hardware.

Turn on remote syslogging so you can see what is causing the reboot.

I have got the same message on the older version. If you used the Trafic Shaper wizard then change the bandwidth on the qlanroot it should work.

Imho IN and OUT directions of connection services different queue's

nothing??? :(  ….at least a start point guys!

pfSense can't share bandwidth evenly. It's using a different trafficshaping mechanism (altq).

Recent Realtek Gigabit cards are nice.  The ones with the bigger buffers.

Pick Halo2 in the wizard.  It uses the same ports.  Meanwhile I commited a "Xbox 360" option which is identical to Halo 2 but added it for completeness.

Yes

Make a queue for pc1 and 2, edit that queue to have a max as described above, set it to have a priority of 3 or so just make it smaller then the next queue you will make.

Make another queue for pc3, edit that queue to have the max described, give it a priority of 5.

Go status > Dhcp server > and statically map the macs of those three computers to an IP

under aliases make an alias for each group

Make rules that tell each alias to go to its corresponding queue, make sure to make both an inbound and an outbound rule for both.

The aliasing is optional, but will make it more dynamic and easier to change in the future.

We still got this problem, about once a day the router barely working. We caught a queue graph (when the router is stinky) and we saw a huge lanack speed. (300-1000Kbit/s) We do not have a rule which use the ack queues, expecting default ack queue. I think we found the problem. Do you have any idea?
I made some tests with Traffic Shaper and I think we found the ideal speedlimit.
We will try to reconfig the pfsense from default setting.

qwanack is quite small. Please have a look at
http://wiki.pfsense.com/wikka.php?wakka=TrafficShapingGuide&show_comments=1#comments

Also, try qwanroot = 600 kb/s, qlanroot = 4800 kb/s. Sometime it helps.

do not crosspost that is not helping !!

Ok Thx

databeestje has added a penalty option that exactly does this integrated as additional step in the wizard. Give it a try: http://forum.pfsense.org/index.php/topic,3135.msg18892.html#msg18892

@Helix26404:

Hmm. Tell me if my logic is correct: if the WAN interface is shaped properly, and the traffic flows over the VPN (which goes out the WAN interface), will that traffic be shaped?

It will be shaped as part of one class.  Although, since the tunnel originates from the pfSense box and our shaper setup classifies traffic as it enters the LAN interface so it can be appropriately shaped going out the WAN, what you'll likely see is the VPN traffic hitting the default class on the way out.  This would apply to both the traffic outbound from your network, but also the traffic inbound to your network.  At some point, I'd love to see the layer 7 changes I was working on completed so we can dynamically move traffic to appropriate queues.  But until that's done, I don't expect we'll be able to shape VPN traffic of any kind properly.

–Bill