Beta 1.0 Livecd - Does shaping actually work?
-
I saw this older thread and saw that Scott Ullrich posted that it was still being worked on.
This was back in november since then the Beta 1.0 version has been released. Does this mean the the shaping still doesn't really work?
I'm just trying to diagnose similar performance issues with the traffic shaping in that it doesn't appearto doing anything different than normal. ie. high icmp packet times when there alot of uploads is the same regardless of what priority queue the upload traffic is put into.
I had a rule for all traffic from a certain IP address to be prioritied at the lowest possible value. If I started an upload on this machine the ping times from other machines went out the window. Yet the ICMP rules has the second highest value queue associated with it.
My classification of the traffic isn't a problem as its showing up correctly in the queue's almost identically to "ebpbs" post.
To further check that it wasn't an issue with my link I reduced the available bandwidth in the parent queues to 1/3 of both my up and down links. Thus, surely removing any possibility that the connection time issues were with buffers on the dsl modem or isp links.
My problem is that people are saying in other posts "it works fine". If it doesn't actually work i'd like to know so I'm not banging my head against a wall trying to get it to do so.
Please don't take any offence to this post if it does actually work as im not out to insult pfsense or its developers in anyway (maybe its just a screw up i've made somewhere).
Thanks
Koops
-
See, this is exactly the battle that I'm fighting. I claim it's b0rked (although I'm not sure why), but I seem to get very little confirmation from others that it's b0rked. I've spent a lot of time debugging and trying to fix it, but if I'm fixing something that ain't broke, it's kinda pointless to continue right? :)
Sounds like you are seeing identical results to me. Stuff is getting queued (mostly) right (yay), but latencies suck (which shouldn't be) and speeds aren't the greatest. I'm working on creating a VMWare testbed for this so I can troubleshoot it (it's hard to tell if the issues are the 'net or the shaper at times) and will continue working on it. Thanks for the feedback, good to know that I'm not crazy :)
–Bill
-
I can confirm that you are not crazy too ;D
-
I too get lousy ping times with large amounts of traffic. I could be very wrong, as I don't know what i'm talking about, but I think it may only happen with the ack queue being high(bittorrent)
-
I too get lousy ping times with large amounts of traffic. I could be very wrong, as I don't know what i'm talking about, but I think it may only happen with the ack queue being high(bittorrent)
Bittorrent will make your latencies go to hell regardless of what you dom, but I suspect you're seeing the same issues as me. My VMWare test bed sort of worked, but I'm hitting CPU limits on my machine (Athlon 64 3000 running at 80+% cpu utilization for the last 48 hours now) so will probably end up having to switch to physical hardware for the shaper testing. That's going to delay things a bit as my lab isn't setup and won't be for a while.
–Bill
-
ahh good and bad news I suppose then ::) Atleast some people here with a bit of authority and not a noob end user (me) is experiencing the same thing.
My theory around the whole bittorrent traffic classification thing was to do the following.
On my machine with bt set my client to a specific IP ie. 192.168.0.20. My normal pc IP address would be say .19. Create a new interface on the pc with the IP of .20.
Now all bt traffic has the same IP address ".20". This was confirmed with a look at the connections table and pftop. Then I made a rule with it as the lowest possible priority.
Test results with other traffic from the original .19 address showed no improvement with the shaping.So is it a problem with the number of acks that come from BT then? Maybe I could just create a more refined ack rule.
Just disregarding BT for a second. Does the shaping work for other traffic types though? ie. http/ftp uploads/downloads while low latency traffic ssh/battlefield2 remain unaffected?
Any pointers to any commandline utils that show more information about queue times? I'm from a solaris/linux background.
Cheers,
Koops
-
Well I'v gotten around to understand altq traffic shaping and QOS quite a bit (been reading and getting my hands dirty for a week). Now what I need to do is try a similar setup and report my results. From what you guys are saying it seems latency goes belly up when uploading. The only reason that comes to mind is that the queues are full all the time, but my guess is that it shouldn't happen if RED or ECN is enabled on a queue. Oh well this is just my theory, I should just experiment with this as much as I can.
-
So is it a problem with the number of acks that come from BT then? Maybe I could just create a more refined ack rule.
We only have one ACK queue per interface. I might work on modifying that for P2P stuff (it kinda makes sense there).
Just disregarding BT for a second. Does the shaping work for other traffic types though? ie. http/ftp uploads/downloads while low latency traffic ssh/battlefield2 remain unaffected?
In my experience, I saw BF2 pings in the 700's with shaper on and NO other traffic. Without shaper, pings in th 50's. I added back in CBQ (for 1.1 as there's no way it's getting much attention before then) and didn't seem to have any better luck. So I'm either butchering the queues somehow grrr or ALTQ on FreeBSD w/ PF doesn't work (I'm skeptical on that one).
–Bill
-
Any pointers to any commandline utils that show more information about queue times? I'm from a solaris/linux background.
Koopspfctl -sq -v , shouldl show you how full your queue is and how many packets have been dropped.
-
Status -> Queues also shows this information without a shell.
-
I have a question.
In general, where does "priority" count when using HFSC scheduling? From my readings HFSC guarantees realtime bandwidth under certain circumstances.
Each queue is guaranteed a realtime bandwidth given that the sum of leaf queues realtime bandwidth is less than or equal to the bandwidth of its parent.
So if I have two queues p2p and icmp:
altq on $ext_if hfsc bandwidth 512Kb queue{ p2p icmp }
queue p2p priority 1 bandwidth 10% hfsc(realtime 25% linkshare 10% upperlimit 100%)
queue icmp priority 7 bandwidth 10% hfsc(realtime 25% linkshare 10% upperlimit 100%)If p2p is saturated and approaches 100% once traffic arrives at icmp hfsc would relinquish some amount of p2p’s bandwidth so that icmp realtime bandwidth can be satisfied.
So how does queue priority, interact with the “realtime” specification? That is, where does the “realtime” part come into play vs. the “priority” part?If there is a lag in icmp pings my only guess would be that the icmp queue is saturated, or something isn’t configured right.
I’m still reading but my guess would be that priority takes effect after realtime and linkshare has been satisfied, as both queues approach its upperlimit, more bandwidth is given to the queue with the higher priority. I may be wrong. In the case where only PRIQ queues are used then I guess it isn’t working as it should.
-
In my experience, I saw BF2 pings in the 700's with shaper on and NO other traffic. Without shaper, pings in th 50's.
Same deal here. I'm a fairly regular BF2 player so a nice playable connection is my holy grail. In my travels to find a free traffic shaper, that doesn't involve 3months of dedicated full time work, I also tried out a mod for smoothwall 2.0 (QOS). It used HTB it also had the same problem with BT traffic and game response.
Last night I even resorted to trying a windows based traffic shaping solution (it didn't do anything at all, and i've probably got some spyware to boot now!).
If only packeteer had a software only version of their product I could use on an old pc would probably cost a fair few $$$'s tho.
-
I have a question.
In general, where does "priority" count when using HFSC scheduling? From my readings HFSC guarantees realtime bandwidth under certain circumstances.
Each queue is guaranteed a realtime bandwidth given that the sum of leaf queues realtime bandwidth is less than or equal to the bandwidth of its parent.
So if I have two queues p2p and icmp:
altq on $ext_if hfsc bandwidth 512Kb queue{ p2p icmp }
queue p2p priority 1 bandwidth 10% hfsc(realtime 25% linkshare 10% upperlimit 100%)
queue icmp priority 7 bandwidth 10% hfsc(realtime 25% linkshare 10% upperlimit 100%)If p2p is saturated and approaches 100% once traffic arrives at icmp hfsc would relinquish some amount of p2p’s bandwidth so that icmp realtime bandwidth can be satisfied.
So how does queue priority, interact with the “realtime” specification? That is, where does the “realtime” part come into play vs. the “priority” part?If there is a lag in icmp pings my only guess would be that the icmp queue is saturated, or something isn’t configured right.
I’m still reading but my guess would be that priority takes effect after realtime and linkshare has been satisfied, as both queues approach its upperlimit, more bandwidth is given to the queue with the higher priority. I may be wrong. In the case where only PRIQ queues are used then I guess it isn’t working as it should.
In theory….p2p is guaranteed 25% and icmp is guaranteed 25% - I'll ignore linkshare for now cause it just makes it more complicated. Let's take this example, 75% of your bandwidth is eaten by p2p, 25% is actually eaten by icmp...just for grins, it's an easy example. What happens if more ICMP comes in? That's where priority comes into play. ICMP can't take more than 75% of the bandwidth assuming p2p is using it's 25% guarantee, BUT p2p can't use more than 25% if ICMP is eating 75% because ICMP has a higher priority on it. Make sense?
--Bill
-
In my experience, I saw BF2 pings in the 700's with shaper on and NO other traffic. Without shaper, pings in th 50's.
Same deal here. I'm a fairly regular BF2 player so a nice playable connection is my holy grail. In my travels to find a free traffic shaper, that doesn't involve 3months of dedicated full time work, I also tried out a mod for smoothwall 2.0 (QOS). It used HTB it also had the same problem with BT traffic and game response.
Last night I even resorted to trying a windows based traffic shaping solution (it didn't do anything at all, and i've probably got some spyware to boot now!).
If only packeteer had a software only version of their product I could use on an old pc would probably cost a fair few $$$'s tho.
Not sure if this is what you were trying to say, but BT and any other traffic is just a bad idea. It should work well w/ HTTP, but it's not behaved anywhere near well enough to allow low latency stuff to be happy. With that said, 700ms w/ NOTHING running is bad, that's my primary goal - make it actually work. It's odd though, I'd almost swear this is a FreeBSD issue considering that CBQ doesn't seem to work any better for me (and it's a cinch to configure).
Anyone interested in testing out CBQ needs to upgrade /usr/local/www/wizard.php to HEAD as well as /usr/local/www/wizards/traffic_shaper_wizard.xml. This is of course not supported, you are on your own, etc, etc…but I'd be really interested if anyones brave enough (honestly, it shouldn't blow up your box, but mixing RELENG_1 and HEAD is just a plain bad idea, so disclaimer stands, be able to fix it yourself) to hear about differences between the two schedulers. Oh, did I mention that there will be no support, we'll just laugh at you if you do this and ask for help fixing your broken box? :) I personally am interested in hearing about the differences, feel free to email me bill.marquette at gmail.com to inform me of differences (or lack thereof) and differences ONLY - support questions will be rm -f'd (and the offending email address will earn a place in my delete on sight filter)
--Bill
-
In theory….p2p is guaranteed 25% and icmp is guaranteed 25% - I'll ignore linkshare for now cause it just makes it more complicated. Let's take this example, 75% of your bandwidth is eaten by p2p, 25% is actually eaten by icmp...just for grins, it's an easy example. What happens if more ICMP comes in? That's where priority comes into play. ICMP can't take more than 75% of the bandwidth assuming p2p is using it's 25% guarantee, BUT p2p can't use more than 25% if ICMP is eating 75% because ICMP has a higher priority on it. Make sense?
--Bill
yeah it makes sense.. but I guess if low delay is really important then you should set realtime 50% or more.
-
yeah, BF2 just does not work with PFSense
-
-
yeah, BF2 just does not work with PFSense
? worked fine last time I used it.
–Bill
did you? i thought you had like 700ms ping when traffic shaper was on? how did you get it to work?
-
Ok, I opened another thread about this very issue and no one responded with anything remotely useful. So here is the evidence I have collected to confirm that the traffic shaper in it's current form is worthless!
Here is the test setup I have isolated. I have removed everything I can possibly think of to make this as simple as possible:
Cisco 2924 switch #1 with my test "workstation" and the internal pfsense interface. Cisco 2924 #2 with pfsense outside and uplink to network. This is all 100meg links and thoroughly tested that it all works. I got a clean pfsense box with nothing else on it. It has 2 broadcom bg0 interfaces in it (I have tried 2 intel, 2 realtek, 2 dc0, it doesn't matter), there is no other packages running, I turned off all unnecessary services. I can run 75 meg/s through this box and it barely breaks a sweat! The ping times stay at under 1ms at ALL TIMES!
As SOON as I turn on the shaper it all goes to SHIT! I can set the shaper to 5 meg/s and make sure I don't go anywhere near that, and i will start to see fluctuations in the ping times. If I get about 90% of the shaper bandwidth, the pings really start to go off. Before I reach 95%+ of the bandwidth, the box is pretty much worthless. The pings will time out, traffic and streams start to break up.
Before everyone starts with the normal misconfig crap: I have ICMP set to highest priority. I can setup m0n0wall or IPCop on the same box and it is silky smooth with the shaper on and does exactly as I would expect. The only reason I am even spending my time here, is because I want to see it get resolved. Unfortunately, I do not have the time to solve this myself. If you need help testing, I am happy to help.
One piece of advice, move the LAN (downstream) shaping to the WAN interface on an ingress queue where it belongs. If you need an example of this, just drop me a line.
Roy
-
yeah, BF2 just does not work with PFSense
? worked fine last time I used it.
–Bill
did you? i thought you had like 700ms ping when traffic shaper was on? how did you get it to work?
You must be mistaking me for someone else. I no longer use the shaper, but it has nothing to do with pfSense, it has to do with the 10second latencies my ISP likes to randomly tack on upstream of pfSense. No sense in shaping when I can't do any realtime crap anyway.
–Bill