Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds?
Do you have a server/software that customer can test too?
Thanks,
Mark Urbach
PinPoint Communications, Inc.
100 N. 12th St Suite 500
Lincoln, NE 68508
402-438-6211 ext 1923 Office
402-660-7982 Cell
mark.urbach@pnpt.com
[cid:image003.jpg@01CA5BD5.1A5CEE20]
iperf is fairly standard and supports some handy features -
http://en.wikipedia.org/wiki/Iperf
-Jack Carrozzo
Anyone have a good solution to get "accurate" speed results when testing at 10/100/1000 Ethernet speeds?
If you want accuracy, you want to buy a packet generator/router tester unit.
I just built a tool for a customer (a last-mile network provider) that runs a series of iperf tests over several days, and generates a report.
iperf works well enough, but it seems to be much better when driven by humans, vs. driven by scripts.
I'm not aware of any free tools that do just ethernet frames.
Do you have a server/software that customer can test too?
Not sure what you're after here - do you want to host your own speedtest.net-like service so your customers can self-test their access links? Does this mean much, or should they be testing against a server outside your network?
Also, if you host your own service and you're talking about 10/100/1000mbit connections, you might want to put something in place that prevents several people testing at once.
perfsonar livecd offers npad service that remote hosts can connect and see the performance and results.
http://www.internet2.edu/performance/toolkit/index.html
TcpOptimizer helps tunning the tcp/ip for windows systems.
http://www.speedguide.net/downloads.php
nuttcp is good to generate packets/sec.
-Azher
Nathan Ward wrote:
I use iperf with packet capture on both sides, then analyze the packet
capture for per-second throughput and re-transmits. I usually do 10
TCP streams for 30 seconds.
Note that on GigE with significant RTTs (5-15 ms) some TCP tuning is
needed to deal with the bandwidth delay product. It is also possible
that Ethernet drivers will have an effect. Local testing of the pair
of test machines should be done if you can't get to about 980 Mbps on
a Gig link (keeping in mind the comment about TCP tuning as latency
increases).
Jon
Hello,
Anyone have a good solution to get "accurate" speed results when
testing at 10/100/1000 Ethernet speeds?
iperf. Check
http://www.nanog.org/meetings/nanog43/abstracts.php?pt=MjkmbmFub2c0Mw==&nm=nanog43
and
http://www.merit.edu/mail.archives/nanog/2009-03/threads.html#00388
Do you have a server/software that customer can test too?
You can set up your own iperf server on your net, or install the
server side parts of the browser based software from 'speedtest.net'
http://speedtest.net/mini.php
Note: IMHO that one has issues selecting the correct test based on
the perceived RTT and will deliver misleading results sometime.
-andreas
Nathan Ward wrote:
Nathan Ward wrote:
>
>>Anyone have a good solution to get "accurate" speed results when
>>testing at 10/100/1000 Ethernet speeds?An NDT server?... such as:
http://ndt.anl.gov:7123/
I just tested that server, and couldn't get any results which were even
vaguely close to accurate. Of course it probably didn't help that the
only routes I could find to the test server were either Chicago - Palo
Alto - Chicago or Chicago - Ashburn - Chicago, but this doesn't seem
like it would ever be useful for testing gigabit anything.
For end user testing, I've actually seen reasonable results from
speedtest.net. http://www.speedtest.net/result/610596179.png for
example, better than ndt.anl.gov at any rate. 
For quick and dirty high speed Internet testing up to a gigabit, this is
my favorite standby (it often helps to eliminate your local disk from
the equation by writing the downloaded file to /dev/null too):
fetch -o /dev/null http://cachefly.cachefly.net/100mb.test
/dev/null 100% of 100 MB 102 MBps
But the best (and conveniently enough the most commonly used) tool for
in-depth high speed testing was already mentioned, iperf. Another useful
tool if you're trying to troubleshoot tcp issues is
http://www.tcptrace.org/.
One wonders how netnod does this... I believe they put in some servers
specifically so their local users could verify that bw bought was bw
received...
Maybe someone from netnod even wrote up their
methods/procedures/process/utilities/tools? 
(Maybe one would even
give a talk about it at an upcoming meeting?)
-Chris
Hello,
Iperf is pretty good at this ... It s free
Ben
-----Message d'origine-----
Please take note with using iperf that you'll want to make sure the
appropriate TCP Window Size has been negotiated. We recently did some
testing with systems that had decided to pick less than optimal window sizes
and in turn had to manually set the size within iperf options.
Jason
True, we usually find Linux based machines work better running IPerf
then Windows (at least out of the box) because of the TCP window
size....well Windows XP at least, don't know about Vista or 7.
Jason Biel wrote:
Please take note with using iperf that you'll want to make sure the
appropriate TCP Window Size has been negotiated. We recently did some
testing with systems that had decided to pick less than optimal window sizes
and in turn had to manually set the size within iperf options.
Jason
Please take note with using iperf that you'll want to make sure the
appropriate TCP Window Size has been negotiated. We recently did some
testing with systems that had decided to pick less than optimal window sizes
and in turn had to manually set the size within iperf options.
Indeed this is true.
Also, if you use one of the Internet2 network test web100-enabled servers, you can try testing through a web browser. There's both NPAD and NDT on distributed on different nodes, although each has its own slightly different tests. It's also not a bad set of tools for support people wanting to troubleshoot bandwidth problems caused by duplex misconfigs.
Jason
Hello,
Iperf is pretty good at this ... It s free
Ben
-----Message d'origine-----
De : Mark Urbach [mailto:mark.urbach@pnpt.com]
Envoyé : lundi 2 novembre 2009 22:57
À : nanog@nanog.org
Objet : Speed Testing and Throughput testingAnyone have a good solution to get "accurate" speed results when testing at
10/100/1000 Ethernet speeds?Do you have a server/software that customer can test too?
Thanks,
Mark Urbach
PinPoint Communications, Inc.
100 N. 12th St Suite 500
Lincoln, NE 68508
402-438-6211 ext 1923 Office
402-660-7982 Cell
mark.urbach@pnpt.com
[cid:image003.jpg@01CA5BD5.1A5CEE20]--
Jason Biel
wfms
Linux always worked best for us as well, was easy running a livecd with
laptops. We found that two windows XP machines, same identical hardware and
OS load yielded different registry settings (or lack thereof) for TCP Window
setting.
Jason
We had a problem where our (mostly research network connected, international) users were getting generally low HTTP transfer speeds, even though the path was often gigabit. The classic high bandwidth/high latency problem.
Initially I tried using iperf/ndt and friends but found that iperf required too much user knowledge and interaction, and NDT was sometimes inaccurate at diagnosing problems -- it seemed to be overly fond of saying there was a duplex mismatch or congestion. Iperf in TCP mode either requires manually seeking the number of streams to try and find optimum throughput, or doing window size tweaks.
I also found that packet captures were useful for discovering problems in the path; you can load it up in wireshark or tcptrace and get a sequence no. vs time graph, look for packetloss, or other good things like that.
Anyways I didn't find much out there in terms of automating this type of thing (simple throughput tests with packet capture) so I just ended up making my own. It does a dump of 10 sec. of test traffic, uses a somewhat dumb algorithm to seek up the number of TCP streams, and gets an AS path from a BGP route server and displays it to the user. The caveat is that it only tests your download speed, not upload, since that was primarily what I was interested in.
You can give it a try at: http://caranthir.dao.nrc.ca/netperf-www/ (login nanog/nanog). User guide here: http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/netperf/testdetail.shtml
I might end up packaging and releasing the code if there is interest.
I would have thought that (netperf's) UDP tests were more appropriate
than TCP for testing link speed. Am I missing the point?
Hi Michael,
Zitat von Michael Helmeste <mhelmest@uvic.ca>:
[...]
You can give it a try at: http://caranthir.dao.nrc.ca/netperf-www/ (login nanog/nanog). User guide here: http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/netperf/testdetail.shtmlI might end up packaging and releasing the code if there is interest.
If you have time it would be great if you could do that. - I'm very interested in it!
Kind Regards,
Axel
We actually used both tests to finally narrow down the TCP window size
issue. We first used the UDP test to make sure the link was good.
Jason
ml@axmo12.de wrote:
Hi Michael,
Zitat von Michael Helmeste <mhelmest@uvic.ca>:
[...]
You can give it a try at: http://caranthir.dao.nrc.ca/netperf-www/ (login nanog/nanog). User guide here: http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/netperf/testdetail.shtmlI might end up packaging and releasing the code if there is interest.
If you have time it would be great if you could do that. - I'm very interested in it!
+1
Today we use Postini for inbound email protection.
Today we use Symantec's SMTP Gateway (running on Solaris) for outgoing email
filtering. (helps stop bad stuff from our customers sending email to the
Internet) This SMTP Gateway software is "End of Life"
Does anyone have recommendations for other products/software to filter our
outgoing email, from our customers going to the internet.
Thanks,
Mark Urbach
PinPoint Communications, Inc.
100 N. 12th St Suite 500
Lincoln, NE 68508
402-438-6211 ext 1923 Office
402-660-7982 Cell
mark.urbach@pnpt.com
