Re: [asterisk-users] Latency woes, qos the fix?
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? Thanks ___ -- 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
Re: [asterisk-users] Latency woes, qos the fix?
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
Re: [asterisk-users] Latency woes, qos the fix?
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
Re: [asterisk-users] Latency woes, qos the fix?
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. You were both right I was just double checking. I fired up a soft phone on a desktop that has relatively low ping rates and experienced similar response times ns1*CLI sip show peers Name/username HostDyn Nat ACL Port Status vitel-outbound/rsreese 64.2.142.29 5060 Unmonitored vitel-inbound/rsreese 64.2.142.1165060 Unmonitored 102/10268.156.63.118D N 56558OK (145 ms) 101/10168.156.63.118D N 1038 OK (135 ms) Thank you both for your insight. ___ -- 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
Re: [asterisk-users] Latency woes, qos the fix?
On Sun, Oct 19, 2008 at 12:31 AM, Stephen Reese [EMAIL PROTECTED] wrote: My latency is kind of high and the voice delay is noticeable. Then pretty much all you can do is lower the latency to lower the voice delay, or use a connection to th e PSTN that has a marginally lower delay if you have no other options. ___ -- 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
[asterisk-users] Latency woes, qos the fix?
My latency is kind of high and the voice delay is noticeable. The Asterisk server is on a dedicated host outside of the network. I am performing PAT/NAT using a Cisco router. ns1*CLI sip show peers Name/username HostDyn Nat ACL Port Status vitel-outbound/rsreese 64.2.142.22 5060 Unmonitored vitel-inbound/rsreese 64.2.142.1165060 Unmonitored 101/10168.156.63.111D N 1038 OK (133 ms) This seems pretty high when my ping time from a host on the same network is ~30ms: Pinging 209.251.157.93 with 32 bytes of data: Reply from 209.251.157.93: bytes=32 time=30ms TTL=51 Reply from 209.251.157.93: bytes=32 time=27ms TTL=51 Reply from 209.251.157.93: bytes=32 time=36ms TTL=51 Reply from 209.251.157.93: bytes=32 time=28ms TTL=51 Any suggestions or is this normal? Should I enable qos on my Cisco 3725 router and 2950 switch? Would I also need to enable the following in the sip.conf ;tos_sip=cs3; Sets TOS for SIP packets. ;tos_audio=ef ; Sets TOS for RTP audio packets. ;tos_video=af41 ; Sets TOS for RTP video packets. ;tos_text=af41 ; Sets TOS for RTP text packets. ;cos_sip=3 ; Sets 802.1p priority for SIP packets. ;cos_audio=5; Sets 802.1p priority for RTP audio packets. ;cos_video=4; Sets 802.1p priority for RTP video packets. ;cos_text=3 ; Sets 802.1p priority for RTP text packets ___ -- 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
Re: [asterisk-users] Latency woes, qos the fix?
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. Stephen Reese wrote: My latency is kind of high and the voice delay is noticeable. The Asterisk server is on a dedicated host outside of the network. I am performing PAT/NAT using a Cisco router. ns1*CLI sip show peers Name/username HostDyn Nat ACL Port Status vitel-outbound/rsreese 64.2.142.22 5060 Unmonitored vitel-inbound/rsreese 64.2.142.1165060 Unmonitored 101/10168.156.63.111D N 1038 OK (133 ms) This seems pretty high when my ping time from a host on the same network is ~30ms: Pinging 209.251.157.93 with 32 bytes of data: Reply from 209.251.157.93: bytes=32 time=30ms TTL=51 Reply from 209.251.157.93: bytes=32 time=27ms TTL=51 Reply from 209.251.157.93: bytes=32 time=36ms TTL=51 Reply from 209.251.157.93: bytes=32 time=28ms TTL=51 Any suggestions or is this normal? Should I enable qos on my Cisco 3725 router and 2950 switch? Would I also need to enable the following in the sip.conf ;tos_sip=cs3; Sets TOS for SIP packets. ;tos_audio=ef ; Sets TOS for RTP audio packets. ;tos_video=af41 ; Sets TOS for RTP video packets. ;tos_text=af41 ; Sets TOS for RTP text packets. ;cos_sip=3 ; Sets 802.1p priority for SIP packets. ;cos_audio=5; Sets 802.1p priority for RTP audio packets. ;cos_video=4; Sets 802.1p priority for RTP video packets. ;cos_text=3 ; Sets 802.1p priority for RTP text packets ___ -- 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 -- 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
