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