|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Traceroute versus other performance measurement
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. Attachment:
pgp00034.pgp
|