Steelhead Appliance

[joshtseng]

Hi Jon,

QoS is like a carpool lane.  If everyone is allowed into the carpool lane, then the carpool lane will be going at the same speed (or even slower) than the other non-carpool lanes.

Even though you gave jonsruleall "realtime" priority, the problem here is that all traffic is being put into that traffic class.  The objective of QoS is to pick winners and losers.  You allow only your winners (e.g., your VoIP traffic) into the carpool lane, and you force your losers (everyone else) into lower traffic classes.

To test your TCP ping, I would modify jonsruleall to include just the IP addresses of your test client and server.  Make sure everyone else is using a lower traffic class.  Finally, make sure that this Steelhead is able to control all traffic accessing the WAN.  Then test your TCP ping.

Josh

[jond]

I've been playing around with QOS on my StealHeads and it doesn't seem to be working from what I can see. Everything else works perfect in terms of compression, caching, etc.


I'm prepping for a VOIP roll-out and I'm trying to get what is currently erratic latency(ranging from 9ms to 200ms) down to a constant 9ms or so.


I created the rule below just to test. The bottom class 'jonrulesall' (I made this before I thought I would be sharing it), is set to realtime, has guaranteed bandwidth with full link share weight. The rule is set to run against all traffic from my laptop to a remote server.


I then ping the remote server(and also use "tcping") and I don't see a difference. Pings are still all over the place and spike when I copy large amounts of data(using a different computer).


Any thoughts?