Rich Adamson wrote:
In other words, as the ttl value is increased and additional icmps are sent, you might see what you believe is congestion, but you still don't have any clue as to whether hop #2, #5, or #10 actually was involved with that congestion.
Sure. But there is a way around this.
The traceroute-style statistics gathering technique that PingPlotter uses tries all the hops at the same time and plots the return rate for each one. So a 10 hop path has 10 packets go out, with individual packet's TTL set to expire at each hop. Done over and over again and averaged over many probes, you get a very clear picture. Packet loss at one node affects all the probes to that node and further ones, resulting in an increasing loss rate as you go down the path. For example:
Hop Loss
1 0% 2 1% 3 1% 4 5% 5 5% 6 6% 7 15% 8 15% 9 16% 10 16%
It's easy to see there is a big problem between hops 6 and 7 and a smaller problem between hops 3 and 4.
With the broadvoice router I was seeing (at first) a jump from 0% to 9% at my local ISP, then small increments over the next 10 hops until it was at about 14%, then a big jump to 29% at the last hop.
The data has varied cyclically between as high as the above and as low as <1% all the way across. Right this very moment, it is 2% within my ISP, still 2% all the way to PNAP, then a jump to 14% at the broadvoice ingress router at PNAP.
Again, temper the above with the fact that the packet loss may be intentional, and these statistics not representative of real RTP traffic, as per my previous message. But I can predict with high accuracy what the caller on the other end of my broadvoice call will say about my voice quality based on the last number I see for the broadvoice ingress router.
-Johnathan _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
