Traceroute versus other performance measurement
I have been reading NANOG posts for probably 2 years now.. this is my 1st post. I need help with a reality/sanity check. Traceroute is a good tool for checking for routing type problems (loops). Does anyone feel it's a good tool to use for testing "bandwidth".... My obvious answer is it isn't a good tool for that.... One problem I see is that the way traceroute works, if a transport mixes media between say Ethernet to LANE and back to Ethernet you give room for Destination unreachable responses from a trace route because you have to to packet switching medias with a fast cell switched media in between.... packets less than 64k (like traceroute info) are easily lost in the conversion from ethernet to LANE. Does this sound right? Thanks, Paul A. Bradford
Have you tried pathchar? It's pretty much the same as traceroute, but it is to estimate e2e bandwidth. When it first came out, I tried it. It didn't give good results. I heard it had been enhanced since. Go to ftp://ftp.ee.lbl.gov/pathchar/ - Ping On Wed, 29 Nov 2000, Paul Bradford wrote:
I have been reading NANOG posts for probably 2 years now.. this is my 1st post.
I need help with a reality/sanity check. Traceroute is a good tool for checking for routing type problems (loops). Does anyone feel it's a good tool to use for testing "bandwidth".... My obvious answer is it isn't a good tool for that.... One problem I see is that the way traceroute works, if a transport mixes media between say Ethernet to LANE and back to Ethernet you give room for Destination unreachable responses from a trace route because you have to to packet switching medias with a fast cell switched media in between.... packets less than 64k (like traceroute info) are easily lost in the conversion from ethernet to LANE.
Does this sound right? Thanks, Paul A. Bradford
FYI - there is anether program, available with source (unlike pathchar) called pchar: http://www.employees.org/~bmah/Software/pchar/ Grisha Wed, 29 Nov 2000, Ping Pan wrote:
Have you tried pathchar? It's pretty much the same as traceroute, but it is to estimate e2e bandwidth. When it first came out, I tried it. It didn't give good results. I heard it had been enhanced since. Go to ftp://ftp.ee.lbl.gov/pathchar/
- Ping
On Wed, 29 Nov 2000, Paul Bradford wrote:
I have been reading NANOG posts for probably 2 years now.. this is my 1st post.
I need help with a reality/sanity check. Traceroute is a good tool for checking for routing type problems (loops). Does anyone feel it's a good tool to use for testing "bandwidth".... My obvious answer is it isn't a good tool for that.... One problem I see is that the way traceroute works, if a transport mixes media between say Ethernet to LANE and back to Ethernet you give room for Destination unreachable responses from a trace route because you have to to packet switching medias with a fast cell switched media in between.... packets less than 64k (like traceroute info) are easily lost in the conversion from ethernet to LANE.
Does this sound right? Thanks, Paul A. Bradford
Programs such as pathchar can AT MOST tell you about latency, not about bandwidth. Any cases where links are in parallel (e.g. multilink PPP of multiple ISDN or T1 lines, or trunked Ethernet links) will typically NOT show up in the calculations, since all packets from the test tool will travel only one of the possible links in these cases. (Yes, multilink PPP permits splitting packets across links, which would make it possible to see the added bandwidth, but I haven't seen an implementation actually do this). This compounds other issues with trying to determine path characteristics with such tools, most especially (and as others mentioned) asymmetric paths. ----- Original Message ----- From: Ping Pan <pingpan@cs.columbia.edu> To: Paul Bradford <paul@adelphia.net> Cc: <nanog@merit.edu> Sent: Wednesday, November 29, 2000 11:09 AM Subject: Re: Traceroute versus other performance measurement
Have you tried pathchar? It's pretty much the same as traceroute, but it is to estimate e2e bandwidth. When it first came out, I tried it. It didn't give good results. I heard it had been enhanced since. Go to ftp://ftp.ee.lbl.gov/pathchar/
- Ping
On Wed, 29 Nov 2000, Paul Bradford wrote:
I have been reading NANOG posts for probably 2 years now.. this is my
1st post.
I need help with a reality/sanity check. Traceroute is a good tool for checking for routing type problems (loops). Does anyone feel it's a
good tool
to use for testing "bandwidth".... My obvious answer is it isn't a good tool for that.... One problem I see is that the way traceroute works, if a transport mixes media between say Ethernet to LANE and back to Ethernet you give room for Destination unreachable responses from a trace route because you have to to packet switching medias with a fast cell switched media in between.... packets less than 64k (like traceroute info) are easily lost in the conversion from ethernet to LANE.
Does this sound right? Thanks, Paul A. Bradford
If memory serves me right, "Daniel Senie" wrote:
Programs such as pathchar can AT MOST tell you about latency, not about bandwidth. Any cases where links are in parallel (e.g. multilink PPP of multiple ISDN or T1 lines, or trunked Ethernet links) will typically NOT show up in the calculations, since all packets from the test tool will travel only one of the possible links in these cases. (Yes, multilink PPP permits splitting packets across links, which would make it possible to see the added bandwidth, but I haven't seen an implementation actually do this).
Programs such as pathchar, clink, and pchar do have this limitation, because they only have one outstanding probe packet in the network at a time. This is indeed a problem. (Another problem is switched networks, where there are multiple queues below the IP layer.) Suggestions for ways to detect and/or correct these problems are welcome. (As someone else pointed out, the source code for pchar is available, as is the source code for clink.) You can see an annotated listing of similar bandwidth-measuring tools below: http://www.caida.org/analysis/performance/bandwidth/ Other researchers are working on new algorithms that may or may not perform better in the environments you described. I'm looking forward to seeing them, to see if I can use their ideas to make pchar do a better job. Ping Pan wrote:
Have you tried pathchar? It's pretty much the same as traceroute, but it is to estimate e2e bandwidth. When it first came out, I tried it. It didn't give good results. I heard it had been enhanced since. Go to ftp://ftp.ee.lbl.gov/pathchar/
A minor correction: pathchar hasn't really changed since it was first released (as an executable only). pchar and clink are independent, open source implementations. Cheers, Bruce.
On Wed, 29 Nov 2000 10:07:59 EST, Paul Bradford <paul@adelphia.net> said:
I need help with a reality/sanity check. Traceroute is a good tool for checking for routing type problems (loops). Does anyone feel it's a good tool to use for testing "bandwidth".... My obvious answer is it isn't a good tool
Well, if you're looking at the numbers, and hops 1 to 12 are each adding 3-5ms to the RTT, and between 12 and 13 you get a hit for 400ms+, that tends to indicate a *possible* problem (or a satellite link ;) I'd not trust it any further than that, however... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
I need help with a reality/sanity check. Traceroute is a good tool for checking for routing type problems (loops). Does anyone feel it's a good tool
It's probably a poor tool for all kinds of really good technical reasons, but "Matts traceroute" aka MTR is useful to me, often shows overstressed routers or connections... especially when normal traceroute just shows garbage. Example screen: Packets Pings Hostname %Loss Rcv Snt Last Best Avg Worst 1. shredder-48-1.higherbandwidth.net 0% 6 6 0 0 1 2. shredder-131-1.higherbandwidth.net 0% 6 6 1 0 1 3. 500.Serial3-11.GW7.ATL1.ALTER.NET 0% 6 6 3 3 5 4. 174.at-1-0-0.XR2.ATL1.ALTER.NET 0% 6 6 3 3 4 5. 194.at-1-0-0.TR2.ATL5.ALTER.NET 0% 6 6 5 4 4 6. 129.at-6-0-0.TR2.NYC9.ALTER.NET 0% 6 6 27 27 27 7. 186.ATM6-0.XR2.BOS1.ALTER.NET 0% 6 6 40 35 36 8. 152.63.16.117 0% 6 6 42 41 46 9. adel-buf2-gw.customer.ALTER.NET 17% 5 6 106 78 110 10. c4700lwa.buf.adelphia.net 0% 5 6 76 76 113 11. 64.8.0.85 0% 5 5 97 97 130 12. ??? 13. ??? 14. mx1.cdp.adelphia.net 0% 5 5 105 98 119
I need help with a reality/sanity check. Traceroute is a good tool for checking for routing type problems (loops). Does anyone feel it's a good tool
It's probably a poor tool for all kinds of really good technical reasons, but "Matts traceroute" aka MTR is useful to me, often shows overstressed routers or connections... especially when normal traceroute just shows garbage.
the fact that it does all the probes in parallel, without waiting for any single probe to time out is definitely a plus.
Example screen: ...
try mtr with -r (report mode) and -c (number of probe cycles to send) to get nice little snapshots. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."
participants (8)
-
Andrew Brown -
bmah＠acm.org -
Daniel Senie -
grisha＠verio.net -
Paul Bradford -
Ping Pan -
Quark Physics -
Valdis.Kletnieks＠vt.edu