[asterisk-users] Latency woes, qos the fix?

[Jerry Jones]

On Oct 19, 2008, at 1:21 AM, Alex Balashov wrote:

> Stephen Reese wrote:
>>> Does the latency remain more or less the same regardless of the
>>> bandwidth load on the pipe?
>>>
>>> If so, TOS bits (what you refer to as QoS) won't help you.  You've
>>> either got network issues (very likely if you have an intra- 
>>> network ping
>>> of 30 ms) or the outside host you're sending the traffic to is  
>>> just that
>>> far away in latency terms.
>>
>> Interesting. Just to clarify, the computer I'm pinging from is on the
>> same switch as the phone so I don't see how there could be so much
>> variance since the remote Asterisk server is on a very fast pipe.  
>> I've
>> seen several people post that they have well under 100ms response.
>>
>> Is the time that the Asterisk displays just a ping to the device or
>> are there more calculations? Any ideas besides TOS since that will  
>> not
>> help much as you mentioned?
>
> Theoretically, the time Asterisk displays is just the result of
> round-trip time for a SIP OPTIONS ping which results in some sort of  
> SIP
> feedback.
>
> In practise, that often ends up being considerably longer than the  
> ICMP
> ping time and is often a very specious metric that does not give any
> real insight into the true end-to-end latency for media relay etc.
>
> Some of that has to do with the speed with which the far end's UAC  
> core
> responds, so application-level latency as well as other latency within
> the propogation of the request up the stack plays into it.  It may  
> also
> have to do with inaccurate and/or wandering timing resolution used
> within Asterisk to time the return of those requests, especially if it
> depends on any kind of heavily locked threaded processes or other
> unknown event intervals.  I do not know the answer to that.  What I do
> know is that the time Asterisk shows for its 'qualification' pings can
> be 100+ ms higher than the ICMP round-trip time.
>
> I would use ICMP echo (traditional pings) to figure out if the latency
> is really the problem.
>
> The TOS field is meant to solve contention issues on the upstream path
> because routers that are set to differentiate between various DiffServ
> code points can packets marked as being of a certain class at a much
> lower contention ratio, depending on what else is enqueued.  In
> practise, that means media can receive higher packet dequeueing  
> priority
> if it contends with many other types of packets for upstream  
> bandwidth.
>
> It won't help you on the downstream unless your provider is doing
> DiffServ tagging and your edge router is set to recognise the right  
> bits
> and forward the packet on.  But unless you've got that kind of setup
> going, you can't affect the contention of the traffic that is
> transmitted to you from somewhere else.
>
> As far as figuring out the true essence of the problem, ICMP pings can
> probably help to diagnose it along with accurate bandwidth usage
> measurements on your upstream pipe.  Of course, the problem could also
> be caused by interface errors, duplex mismatches, bad cables, bad  
> NICs,
> bad WICs, and just about anything else that can cause network problems
> that may not be easily detectable with conventional data applications
> but show up in real-time ones such as VoIP media relay.

Alex is correct. Always check thereare no half-duplex links in your  
path. If you have an older dsl/cable modem or router that only has a  
10M ethernet, it is probably half. Also make certain there are no hubs  
in the path. Keep in mind that colissions ar NORMAl for a hlaf duplex  
connection. TCP traffic simply retransmits, but voice (on asterisk) is  
RTP/UDP and the packet gets dropped. Even if it were TCP there is no  
time for a retransmit to be detected and resent. Using ehternet to  
detect the collision it does get resent, but there comes your jitter -  
which has much worse effects than simply latency.

As far as measuring latency, doing a sip show peer andlooking at the  
qualify times is a GUIDELINE. It is my no means a correct indication,  
the real time can be much lower. I have noticed various ATA on the  
same networks as Polycom phones wil have sub 20ms times and the  
Polycoms will be <50ms. Yet all is as it should be and working great.

Generally QOS will help with packet loss and jitter.

Hope this helps.