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 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
