Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

jitter guarantees

Hi Guys,

I understand that normally QOS is aimed at VOIP and that an end to end jitter target of 30ms is what should be aimed for. OK

However, I have another real time application that will not work if the jitter is any more than 10ms. I have found using VOIP analysis analysers (netIQ vivinet) that even with QOS enabled it is impossible to achieve this target 100% of the time, even with 6500 cat switches with Sup720 and utilising the priority queue. The average jitter is 1ms for the priority queue class with QOS enabled - a good value I know - but with occasional packets at 25ms. Surely QOS should minimise jitter for ALL packets that match the prioirty queue class?

Any thoughts on this guys?

Steve

1 ACCEPTED SOLUTION

Accepted Solutions
Purple

Re: jitter guarantees

Steve,

Unfortunately, QoS simply cannot guarantee that jitter for all packets will be minised. The problem with non-RSVP based QoS is that you can protect priority traffic from other traffic but how do you protect priority traffic from other priority traffic ? To get an idea of what sort of jitter you can expect on each interface, work out the maximum queue depth possible for the priority. Then, based on the line-rate of the interface you can work out the maximum possible queue occupancy of a priority packet which directly gives you an upper bound on the jitter through that interface.

The fact that you are queueing priority packets means that there will be jitter, albeit less than that experience by the non-priority queues.

Hope that helps - pls rate the post if it does.

Paresh

5 REPLIES
Purple

Re: jitter guarantees

Steve,

Unfortunately, QoS simply cannot guarantee that jitter for all packets will be minised. The problem with non-RSVP based QoS is that you can protect priority traffic from other traffic but how do you protect priority traffic from other priority traffic ? To get an idea of what sort of jitter you can expect on each interface, work out the maximum queue depth possible for the priority. Then, based on the line-rate of the interface you can work out the maximum possible queue occupancy of a priority packet which directly gives you an upper bound on the jitter through that interface.

The fact that you are queueing priority packets means that there will be jitter, albeit less than that experience by the non-priority queues.

Hope that helps - pls rate the post if it does.

Paresh

New Member

Re: jitter guarantees

That's an excellent reply Paresh. Thankyou.

Where can one work out this buffer depth for various Catalyst platforms? I take it that when the output interface is NOT congested then the jitter will be derived from the depth of the hardware queue on the interface. Where can one learn this information? If QOS DOES get activated because of congestion, 15% of the output buffer gets allocated to the priority queue. In that case the jitter could be as hogh as the hardware queue PLUS the depth of the priority queue in the worst case...????

Thanks Paresh

Steve

Blue

Re: jitter guarantees

Steve,

As a practical matter, I am surprised you are seeing max jitter that high if the traffic is traversing 6500s only. I have a 100mb TLS link between two 6509s that often runs as high as 10mb/s voice, with data sometimes filling the rest of the pipe, and have never seen max jitter exceed 5 ms on the voice.

Are you sure the traffic is really hitting the priority queue? Have you verified marking, as well as the port QOS mapping in the switches?

Paresh is right on with his analysis, and if you make everything priority nothing is priority, but what percentage of your traffic is actually being priority queued, and how full are the links?

Please rate helpful posts.

Purple

Re: jitter guarantees

Steve,

On most IOS-based platforms, the 'sh controller' command for a particular interface will shouw you the tx-ring size for the interface. That is the size of the hardware queue.

As for the size of the priority queue, it depends on the particular queueing mechanism being used. I'm not terribly familiar with QoS on the 6500s but there would surely be some command that shows you the max size of the priority queue....

Having said that, I would have to agree with David that there would have to be some exceptional circumstances for you to see such high jitter through a network of only 6500s... And I'm pretty sure that no matter how deep the queues are, it will not add up to what you are seeing.

I suggest you take the approach of measuring jitter/latency over one network element at a time to isolate where exactly it is occuring.

Pls do remember to rate posts.

Paresh

New Member

Re: jitter guarantees

Thanks for the reply.

Yss I am surprised as well. I have two 6509 systems with Sup720's, onnected together with one Gig between them (via 6516 blades). My CPE devices conect into 100Meg ports on the 6748 blades. You'll note this is all top spec kit !!

I am sure the packets are hitting the priority queue. They are being marked DSCP EF by the end Application (RAD mux systems) -checked with an analyser - and this is being trusted by the ingress interfaces. There is also a trust statement on the gig ink. The cos-dscp map ensures that the EF maps to COS 5. I have checked the marking of the packets on the gig link and they are still EF and are marked COS 5 (it's a trunk between the 6500's).

The RAD muxes send in 45Megs of traffic on the ingress interfaces. Since this is the only deviceson the interface, QOS will never get engaged.

The Gig link is realtively lightly loaded with peaks up to 300Meg now and then. Again, QOS shouldn't even get engaged since there is no congestion.

Despite all of this I average 1ms jitter. However I sometimes get 25 ms jitter for some packets.

Working out the maths from Paresh, even in worst case scenario I should not get more than about 5 ms end to end,assuming all the priroty queue buffers get filled - and I am sure they aren't !!!

I am going to get our IXIA tbit blast testers on this in our lab and try to bottom this out since it is most weird.

IF ONLY THERE WAS A WAY TO CHECK THE PRIOIRTY QUEUE IS BEING HIT !!!!!

Best regards, Steve

150
Views
7
Helpful
5
Replies
CreatePlease to create content