Beta 1.0 Livecd - Does shaping actually work?
-
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
-
Please PM me your config xml or paste it here, something is fishy, I have done testing with 3-400 mbiton a dual xeon in the past and as long as I had the shaper config done correctly it did behave as expected.
PS. this is free sw, devs spend tons of time for free to help others, so to call our efforts worthless and shit isn't very nice !!
-
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
Seeing as inbound queuing is a lie in the first place, I'd like to see how you plan on doing inbound shaping. I have half a mind to remove that part of the code altogether, it can't work, it's impossible, it's too late. Also, altq doesn't actually allow for inbound queueing…for that exact reason, the packet has already crossed the wire. We don't need testers for the shaper, we need someone who can spend the time to fix issues they find with it. When that person has something to test, I'm sure they'll call for testers.
--Bill