Testing 1gbps bandwidth

Luqman Kondeth luqman.kondeth at nyu.edu
Wed Aug 15 05:54:43 UTC 2012


Many thanks everyone for the response. Many people have been kind enough
to offer their iperf servers so I'll be trying the test today.
Now, with regards to the email chain, all of these are very valid points.
My objectives were two fold

a) Test Path throughput through ISP backbone
b)Test my 1gbps Internet link

If the tests in (a) return speeds of anything more than 750Mbps I will be
convinced that both (a) & (b) testing objectives have been met.  The best
way to test (a) is to find some ISP that connects to the same tier 1 ISP
as my immediate ISP does.

The reasons I asked for a udp server in Europe was to
1) Take out the tcp LFN problems, delay *bandwidth etc
2) Europe would probably have a server that is geographically closer and
hence have lower latency between server and client. Also it is more likely
to be connected to one of the peering points in London where my ISP
connects as well. Of course, I agree I need to verify all this and ensure
the peering exists etc.

I didn't want to do test (b) in isolation because I've seen a case like
you mentioned below and hence my comment on the SUP32(not really a fair
comment, apologies. I was trying to imply an improperly designed backbone
i.e. using access layer tech for the backbone ). I had an ISP give me
1gbps in UK but one particular path inside the ISP couldn't support that
bandwidth under load. Hence why I was trying to test (a).

I like the idea on using wireshark but wouldn't the LFN problem affect me
with that as well? I assume you are asking me to find a local server in
the region with a very large file that I can download ?

Let me know if my approach is correct.


Thanks

Luqman Kondeth

-----Original Message-----
From: Fred Baker (fred) [mailto:fred at cisco.com]
Sent: Wednesday, August 15, 2012 12:22 AM
To: valdis.kletnieks at vt.edu> <valdis.kletnieks at vt.edu; Luqman Kondeth
Cc: nanog at nanog.org Operators' Group; menong at mengon.net
Subject: Re: Testing 1gbps bandwidth


On Aug 14, 2012, at 4:40 AM, <valdis.kletnieks at vt.edu>
<valdis.kletnieks at vt.edu> wrote:

> On Tue, 14 Aug 2012 15:32:47 +0400, Luqman Kondeth said:
>> Is anyone aware of any public IPerf servers in the middle east or
>> close
>> by?(Europe) or anywhere that can do udp?. I have a 1gbps Internet
>> link which I've been asked to show that it has 1gbps download speeds.
>
> First thing that comes to mind is remembering the difference between
> end-to-end throughput and the throughput across one link in the chain.
> If you really need to validate the one link, you probably need to get
> some system to inject packets at the other end of the link.

You might take a look at http://www.ameinfo.com/broadband_speed_checker/.
I can't say I know anything about them beyond what Google says they say
about themselves, but they claim to be able to test such things.

Let me put hands and feet on what Valdis points out. With a gigabit
interface, you are able to carry about 83,333 1500 byte packets per
second. If you're trying to download a file from, say, an Akamai server,
TCP will allow you to move one window per round trip. If you are using
standard window scaling (e.g., your window is in the neighborhood of
65,000 bytes), you can achieve 1 GBPS only if your round trip time is in
the neighborhood of half a millisecond. Outside of a data center, such an
RTT is Really Unusual. The obvious alternative is to use a larger window
scaling value: if your RTT is 20 ms, scale up by at least 40 times, which
is to say a shift of 6 bits for a multiplier of 64. Even with that, TCP's
normal way of operating will prevent it from using the entire gigabit
until quite a way into the session. You'll need a Really Long File.

The reason you get such an interface, I would imagine, is that you have a
large number of users behind that interface and/or you are routinely
moving a large amount of data. You can make it easier for yourself if you
get a large number of your users to each download something really large
all at the same time, and measure the performance at the interface.

Or, and this is a lot easier but involves math, you can turn on
wireshark/Netflow/tcpdump/something that will record actual throughput,
and download a file of your choosing. Later, offline, you can determine
that you moved some number of bytes within some unit of time and the ratio
is 1 GBPS, although you only ran the test for 20 ms or whatever.

Even those have caveats; upstream, you're sharing a link within your ISP
with someone else. It's just possible that while your link will happily
carry 1 GBPS, at the instant you test, the upstream link gets hit with
some heavy load and AT THAT INSTANT only has 750 MBPS for you, making your
link look like it only supports 750 MBPS. That would be possible in any of
the tests I just mentioned.

What Valdis is suggesting is to have someone at your ISP literally connect
to their router and send you traffic at a 1 GBPS or faster rate for a
period of time, while you record that with wireshark/netflow/etc. You can
then do the math and record the result.




More information about the NANOG mailing list