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. _______________________________________________ -- 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
