[afnog] Bandwidth measurement

[Brian Candler]

On Thu, Nov 25, 2004 at 09:09:05PM +0200, Antonio Godinho wrote:
> Thanks Brian. I think that is bing works, right?

Dunno, haven't used it. I prefer simple tools that are easy to understand -
and a straightforward measurement of RTT is about as simple as you can get.
You may be able to trust raw data like that more than derived data from some
tool whose inner workings you may not fully understand.

Any tool which tries to analyse network link bandwidths from latency
measurements is going to have limitations. For example, a router connected
to another router via a switch:
          R1 ------ S -------- R2
The packet goes from R1 to S, S to R2, R2 to S, and S to R1 (where S is a
normal store-and-forward switch). So it will take twice as long to get
around as you'd expect for a direct link, which means you'll be told wrongly
that the bandwidth is half what it actually is.

B.

> What I was actually going to do is use iperf. I found someone who is running 
> iperf server from the list so I will try that. I have used the bing tool but 
> it gives some very strange results on diff links, maybe due to many factors 
> like congestion, etc...
> I have used iperf here locally to test diff links and it works quite good.
> 
> Cheers,
> 
> 
> 
> On Thu, 25 Nov 2004 16:22:53 +0000, Brian Candler wrote
> > On Wed, Nov 24, 2004 at 07:31:29PM +0200, Antonio Godinho wrote:
> > > Does anyone in this list have a huge bandwidth pipe to the net? I would 
> like 
> > > to run some bandwidth tests on my link but I need a server on the other 
> side 
> > > connected to the Internet backbone (US, Europe).
> > 
> > If all you're going to do is ping that device, then often a good 
> > choice is the router at the far end of the link, or another router 
> > within your upstream network's ISP (unless they have configured ICMP 
> > rate limiting)
> > 
> > If the bandwidth of the pipe you're testing is not huge, then most 
> > any remote server will do.
> > 
> > I find this simple test very useful:
> > 
> > # ping -c100 -s1472 x.x.x.x
> > 
> > That sends packets of size 1500 bytes (20 bytes IP header, 8 bytes ICMP
> > header, 1472 bytes payload).
> > 
> > Now, ping the far end of your link, and take the *lowest* round-trip 
> > time you get. You can use this to estimate the bandwidth of the link 
> > between here and there. You assume the packet is transmitted down 
> > the link at X bits per second, when the whole packet has been 
> > received the reply is immediately sent back down the link at X bits 
> > per second.
> > 
> > Example from my home DSL line:
> > 
> > --- 212.74.111.194 ping statistics ---
> > 100 packets transmitted, 100 packets received, 0% packet loss
> > round-trip min/avg/max/stddev = 75.200/79.688/91.675/3.521 ms
> > 
> > Now, 1500 bytes = 12000 bits. The time is for a round-trip.
> > 
> > One-way time = 75.200 / 2 = 37.6 milliseconds = 0.0376 seconds
> > 
> > Bits per second = 12000 / 0.0376 = 319148
> > 
> > Actually, the link is asymmetrical, and the ISP claims it is 512Kbps 
> > down and 224Kbps up.
> > 
> > So, the round-trip time I would expect to see is
> > 12000/(512*1024)+12000/(224*1024)
> > = .0752040317 seconds
> > 
> > which matches, very closely, the time observed. So I believe my ISP 
> > is telling the truth.
> > 
> > The variation in the round-trip time gives you an indication of congestion
> > on the link. An uncongested link will have min.time = avg.time = max.time
> > 
> > And, of course, you will expect to see 0% packet loss. Anything 
> > higher could indicate bit errors, duplex mismatches, or (with big 
> > variance in RTT) severe congestion.
> > 
> > Regards,
> > 
> > Brian.
> 
> 
> --
> Antonio Godinho
> B.Sc., MCP+I, MCSE, CCNA, CCNP
> CIUEM
> Maputo
> Mozambique
> 
>