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

[Alex Balashov]

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 Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599