Well, I'm running pfSense on a 10Mb connection with 512 MB of RAM and a 1.2 GHz CPU (Fabia FX5620) and despite having added traffic shaping and a good number of plugins (including Squid and IMspector) it's rarely more than 50% loaded (either CPU or RAM).

Of course, I rarely max out that 10Mb link, if your usage profile is different then you'll have different results :)

I don't think ALTQ behave well on loopback since loopback is not treated as a real network interface.

Though you might play with it but take in consideration playing with tbrsize(tbrconbfig) parameter to not have performance issues.

You're seeing a problem where one likely doesn't exist.

First, your cable company probably didn't "shape" traffic. They may have, but from what you describe that doesn't seem to be the case.

Your cable company was likely limiting traffic basically the same way your DSL is limited to 5000/800. On cable networks, the cable modem is where your throughput cap resides. When you're pegging your connection, queuing occurs in the modem, which causes latency to increase substantially.  500 ms with a pegged connection isn't bad at all. If I really hammer my cable modem (15/1.5 Mb) I can get gateway ping times in excess of a second. That's normal, especially if you're uploading heavily.

DSL works basically the same way.

The goal of traffic shaping is to move the queuing up to where it can be more controlled - your firewall. Once the traffic gets to your modem, if you reach your cap, it's too late. Things queue and they go out in FIFO (first in first out) fashion. Traffic shaping basically orders that traffic so the important traffic goes before the less important traffic. It's a lot more complex than that, but this post is long enough without a dissertation on traffic shaping.  :)

Back to my point - your ping times from pfsense will suffer when your link is loaded to capacity, regardless of the type of connection (not just cable and DSL, T1's do it, fiber connections do it, wireless really does it, it's just how networks work). The only way to keep ping times from pfsense low would be to shape your traffic at a lower speed than your actual connection speed. Then you'll ensure at least relatively good response times. But what's the point? All you're doing is making your graphs pretty and keeping yourself from using your full Internet connection speed.

I'm not familiar with the pfsense traffic shaper as I don't use it, so I won't offer any specific recommendations on configuration.

@sullrich:

The wizard instructs you to enter the "phone ip".    That is the reason you reversed them.

Oops, sorry, must have mis-read that. That makes sense now.

Ben

Disable the userland FTP-Proxy application.

@The:

Any more ideas on this one?

Many commercial router vendors said that it's impossible to bandwidth limit encrypted P2P traffic. Only one router vendor claims that they can limit encrypted Bittorrent & Obfuscated eMule traffic (don't remember the company name). I've been using MikroTik RouterOS from the beginning, and since some P2P clients implemented encryption, it's now only possible to block the encrypted traffic. I asked the MikroTik vendor and they said that it's impossible to bandwidth limit encrypted P2P traffic.

This problem forced me to add rules for all normal traffic, and one for the rest (unknown traffic).

This is not doable ATM.

Ya, the best advice I can give in that case then is to just figure out what services you primarily use and stick two that setup.  So if you typically use tons of download go 8mb down 2mb up etc. What essentially needs to happen for this to work right would be a link share between the wan/lan root queues indicating that they can use 10 mb cummativley.  That is way out of my ball park though, hopefully someone else can advise.  I'm guessing that for it to work right you'll need to post a fat bounty or have a fair amount of knowledge yourself.

Hi,

I solved the problem by editing /etc/inc/interfaces.conf

The default list of altq supported drivers seems outdated. Since the comment referse to FreeBSD 6.0

/* Per:          * http://www.freebsd.org/cgi/man.cgi?query=altq&manpath=FreeBSD+6.0-current&format=html          * Only the following drivers have ALTQ support          */

Also stge supports vlan so I add it to vlan supported devices list too.

Hope this helps someone

oytun

Newer snapshots has a version that is fixed.

@sullrich:

What kind of NICS are you using.  This is starting to sound like a driver issue.

I really think it is a driver problem. I got a new 10Mb/s cable connection at home moving up from 3Mb/s. I didn't have a problem before I upgraded but now my ping times are as high as 3000ms when my traffic rate hits around 4Mb/s. Browsing degrades to a crawl so obviously http was also affected when I'm using just little under half my assigned speed … and I do setup my queues to give http higher priority over all traffic. At first I though it was an ISP configuration problem, didn't want to blame my Pfsense box, so I called and reported the problem. They told me the obvious thing to do ...  "plug the Ethernet cable from the modem directly into the pc" .. Boom problem vanished even when the connection speed is near maxed, my pings times were constant and very good.

Im running Pfsense on a PII 366Mhz with 380 Mb of memory.. even when near maxed at 9Mb/s the cpu is still 80% - 85% idle, so it wasn't a performance issue problem...........

Well skipping out my long story of testing and probing I did eventually got rid of the problem when the traffic shaper was disabled. The problem returns if the statement altq on $wan for example ever showed up in the pf rules file. I'm using two nic that uses the dc driver but can't recall the manufacturer or brand at the moment. I have been reduced to using my old Linksys router for my network because the internet goes bad whenever the traffic goes to 4 megs. I want to try to get Intel nics to see if it would fix my problem but I can't get any to buy here locally. Oh well.

If your CPU is pegged under those circumstances, I don't think it's going to matter what CPU you use. It's likely a problem with some run away process that's going to use 100% of your CPU regardless of how fast it is.

Your calculations are right.  Do you have bandwidth dedicated in other locations as well?  I think this could be a cumulative number.  I bet your ack queue is fairly large as well.  I do know for a fact that if your queues with dedicated bandwidth add up to more than 100% (in your case the 368), that is trouble.  Hope that helps.

I fixed the problem by disabling the userland FTP-Proxy application on LAN interface.

But the problem I see is that (with uTorrent at least) the source port number it uses to outward connect just keeps incrementing.  See the notes I have written up here http://doc.pfsense.org/index.php/Multi-Wan/Load-Balancing#Supporting_bittorrents
If you know a better way of doing this, I'm keen to hear it…  ;D

You can direct all of one type of traffic out one interface using firewall use.  You may also search policy based routing to find this.  Its included in the load balancing docs.  For the other, there is no official way to multi-wan traffic shape