Does the Traffic Shaper work in Pfsense 2.0-RC1?
-
Hi all,
As the title asks - Does the Traffic Shaper work in Pfsense 2.0-RC1? I have looked around and I have not come across a definite answer.
I've been doing some tests including me maxing out my 8Meg DSL line via a HTTP download and (With the help of the Traffic Shaper Wizard) setting a gaming port to a very high priority (The highest - 10) however my ping (That has also been prioritized) is still up in the 180's (When it's usually 13ms) playing CoDMW2 is laggy and it doesn't seem to make any difference if I play around with the priority settings.
So, does it actually work?
-
Hi all,
As the title asks - Does the Traffic Shaper work in Pfsense 2.0-RC1? I have looked around and I have not come across a definite answer.
I've been doing some tests including me maxing out my 8Meg DSL line via a HTTP download and (With the help of the Traffic Shaper Wizard) setting a gaming port to a very high priority (The highest - 10) however my ping (That has also been prioritized) is still up in the 180's (When it's usually 13ms) playing CoDMW2 is laggy and it doesn't seem to make any difference if I play around with the priority settings.
So, does it actually work?
Priority 10. What queueing discipline are you using?
-
Yup, I've tried the Priority 10 and it didn't make any difference. I'm using the HFSC Queuing Discipline.
-
The latency sky rockets because your line is getting saturated and this is on the routes further up the chain and flows back to your link. That means everything on your connection will lag regardless of the priority you set (your pfsense box only reschedules what it sends out or receives but it doesn't affect the upstream routers).
You will need to clamp down on the bulk downloads (I recommend setting the upperlimit to 75% or less of your line speed) so that the entire line doesn't bog down.
-
I thought that if you set the priority down on the HTTP port (Which I have), that it will slow port 80 down in the case of higher priority traffic trying to get through, therefore giving the guaranteed service to those higher priority services?
So if I set the ICMP service to priority 10 (Which I have done) and the HTTP port to Priority 2, should it mean the ping gets straight though as it is a higher priority? -
Yup, I've tried the Priority 10 and it didn't make any difference. I'm using the HFSC Queuing Discipline.
Priority is practically ineffective in HFSC as it only helps to decide in corner cases. Only bandwidth that matters.
High and Game queues should have higher real-time bandwidth.
Low, Default and P2P queues should have very small (if any) real-time bandwidth.
The P2P queue should have a upper limit bandwith. Set it to around 50% if there is latency problem.
10 queues are much. I recommend stick with the default number of queues (7).
You should make sure all important traffics are getting to the right queues. Besides ICMP and Games I also mean Web, P2P and other bulk downloads.
Last but not least, you should double check that the actual maximum bandwidth is really the one advertised by the ISP.
-
I know the throughput of my connection because I have tested it in the past :)
Any chance you could advise me to the most effective Queue Discipline for priority? I just left it at the default HFSC when I set up the Traffic Shaper.
-
I use exclusively HFSC because it is universal – it can do everything the other disciplines do. However some other people wouldn't believe it and would recommend PRIQ if you think priority is the key to the solution.
-
I have tested PRIQ against HFSC and I couldn't notice any difference in performance. For that reason I will be sticking with HFSC (Even though I don't think it is working - I switched my Traffic Shaper off and it had the same performance as it was when it was enabled).
-
Keep in mind that limiting downloads is problematic, compared to uploads.
-
To elaborate, when limiting downloads you are effectively just dumping packets that are coming your way and hoping that the applications involved actually notice that there are issues and throttle back on the speed when negotiating with the host.
So setting a 5Mb hard limit won't result in 5Mb heading your way on the WAN side. It's actually higher than that because the applications involved will request a re-transmit of the data that is dumped until the speed throttles back to an acceptable level.
In the worst case where the application or the host does not care, the result is actually a snowball effect where you get the transmitted packets and a duplicate of the packets that were dumped heading your way. This ends up saturating your line even further.