Iperf or Iperf like test points?

Wed Aug 24 18:15:08 UTC 2005

Initial caveat:  If this is off topic please just let me know now and 
please suggest a good forum for this type of question/discussion.

The main premise of the question/discussion is the ability to 
establish/utilize random (or not so) test points (like looking 
glasses) scattered across the planet to gauge real time bandwidth 
performance on larger broadband connections.

Second caveat:  I have done a bit a research trying to figure this 
out before posting and have had no luck to this point.  If this topic 
has already been covered in depth or otherwise please advise.

With that said, the problem that I am facing is that there are no 
consistently reliable tools that NetOps (or end users for that 
matter) can use to truly evaluate bandwidth performance on large pipes.

Ex: All of the test sites that I have tried from a 100M/FD attached 
Linux box, riding a GigE backbone to multiple GigE transit lines 
typically yields BW test results in the 3-7Mbps range.  Yet when I 
Iperf across the backbone I get more reasonable results of between 
80-90Mbps TCP.

The extent of the problem is that I hand off 10M - GigE connections 
to my end users and they want a way to test it that is 'Off-Net'.  My 
on-net test platforms give them great results, however since they are 
on-net the end users dismiss the results (thinking they are fixed I guess).

To date I have not found a reasonable method of accomplishing this.

Now with the understanding that bandwidth testing at these rates (or 
any rate for that matter) can prove to be a complete waste of 
bandwidth simply to give someone a warm and fuzzy, I am willing to 
let that one go on a case by case basis to simply make the end user happy.

That being said, is anyone on this list aware of such a formation of 
Iperf nodes across the net connected at GigE or better to accomplish 
this goal?  If not I would be willing to start one and give up a 
server or two and some of my bandwidth to help others out who are 
probably experiencing (or have experienced) this type of problem in the past.

This issue is just burning up a lot of my tech supports time trying 
to educate the end users.  I just feel that a cooperative effort that 
yields more accurate and consistent results may be a better way to 
approach this.

Thank you in advance.

____
    o  Walter C. Ames
    o  MDConnect Internet Services
    o  (410)290-8088 (phone) MD
    o  (410)290-8180 (fax) 