Calculate upload/download speed by ping

Question

How to calculate the speed of an internet connection by some average ping rates.What are the calculations involved in it.IS it possible to calculate upload/download limit by ping rate

EDIT If ping is not a solution what else is?

Answer 1

I used ping to calculate bandwidth in local network. I think it's as accurate as other means of measuring bandwidth (e.g. downloading a big file). You can use it too for your internet connection if you have a symmetric link to the internet (i.e. not adsl).

Here's how I do it:

I have a gigabit ethernet LAN and I want to measure speed between my computer and a host in server room. My MTU is 1500, so I use packet size 1472. Just randomly, I use 83,333 packets in this test (about 1 gigabit). Then:

sudo ping -f -c 83333 -s 1472 192.168.3.103

at the end of the result i get:

round-trip min/avg/max/stddev = 0.174/0.219/2.078/0.020 ms

so in average it takes 0.219 ms to send 1500 bytes and receive 1500 bytes, that's 24 kb.

24 kb / 0.219 ms = 110 Mb/s

If you want to use that to a server on the internet, you need to lower the packet size to something like 1464 (for MTU 1492), drop the -f option and lower the count so it won't take too long to finish.

p.s. I think this should go to superuser, not stackoverflow.

Answer 2

Latency is distinct from bandwidth. Imagine a truckload of DVDs being driven across the country. The bandwidth is high, but the latency is huge.

Answer 3

It is actually possible to derive bandwidth estimates from ping-like measurements alone.

It always takes 12.3µs to transmit a 1500-byte packet on a GigE link. In other words, if you are able to send two 1500-byte packets from one machine to another across an uncongested GigE link as rapidly as the protocol will allow, they will arrive about 12.3µs apart. Observing that happening confirms your GigE link is in fact not congested.

Now for a simple example of measuring across a WAN (again assume it's not congested):

HostA -------- RouterA -------- RouterB -------- HostB
        GigE             OC-3             GigE

Host A sends two 1500-byte packets in rapid succession. When router A receives the first packet, it begins forwarding it over the OC-3 WAN link (155Mbps). It takes 81.5µs to forward a 1500-byte packet onto an OC3, so Router A will be in the middle of forwarding the first packet when it receives the second packet from Host A. It has to queue this second packet until it's done transmitting the first.

When router B finishes receiving the first packet, it forwards it to host B which takes only 12.3µs; meanwhile router B is beginning to receive the second packet. When router B finishes receiving the second packet, it forwards it to host B.

So host B sees 12.3µs of packet reception, 69.2µs of silence, then 12.3µs of packet reception—in other words an 81.5µs inter-arrival time. From that observation, host B can deduce that the path bandwidth was limited to 155Mbps.

---

Now this is great in theory, but in practice things get more complicated. Congestion events tend to be bursty, so one moment a router's queues may be quite full, the next they're empty. Many samples are necessary to get anything meaningful. Making precise measurements is also tricky. The end-to-end latency may be in the tens or hundreds of milliseconds and you're looking at differences of a few microseconds. If there are multiple paths from A to B, good luck.

It's usually just easier to just blast traffic and see how much gets through. Then you'll know for sure what your available bandwidth is—zero.

Answer 4

A ping is one single packet sent over the network via ICMP. Usually one packet per second is sent to ping a remote machine and the route may differ from the TCP and UDP usually used for data transfers; remote machines may refuse to reply on ping requests. Thus measuring network throughput via ping requests is unreliable and probably useless.

Answer 5

Pinging a remote host will allow you to measure the network's latency (is that host responds). It will not give you useful information about the available bandwidth over that network connection.

Answer 6

No, it's not.

A ping packet is small and just used to verify the speed it takes from point A to point B (Or in more common usage - IF there is a path between them at all, IE if a computer responds at all)

The process of a Ping (to a Pong) is that a small packet is sent from A to B When B gets the packet, it responds with a Pong, which is instantly sent back to A. At the point A gets the Pong, the total time (which is in milliseconds, hopefully) is registered, and there you have your Ping in ms.

This of course assumes that B isn't set to refuse pings or simply doesn't get there, or is behind a VPN or other measure which slows the response down.

In the end, all you get is the time it takes for a Ping to run from A to B and back to A.

For comparison, try running across the street and back. Measure the time. And now find a way to calculate how much you weigh.

Answer 7

As others have said, ping will tell you latency but not bandwidth.
Try netperf. http://www.netperf.org/netperf/. You may have to give specific options (like TCP/UDP) etc.

Answer 8

It is possible although impractical and unreliable.

It would work best on your local network (LAN).

By default, ping send small packets which only indicated the latency. However the command takes arguments to modify the packet size and rate. The theory is that you can increase the size and rate of packets to the point where they would saturate the link, then you can use the packet statistics to calculate the speed at which this happens.

Answer 9

Ping measures latency (how quick). Not the throughput (capacity). Also, the time is measured in round-trip. Using option -c you can specify the payload size (in bytes) for ping to carry. The total data size is 'payload size + headers'.

In order to measure data rate (capacity or the throughput rate), you need to specify the MAX allowed payload size, which is 65536 bytes (0xFFFF bytes allowed by 2-byte header length field).

• in the most rated answer above, I saw 1500 bytes used per transfer. (and 83333 transfers! - why? ). It will give the wrong results because even if you have a large data pipeline, you are placing a very small data into it; and the data throughput rate will be incorrect - You need to saturate the ping with MAX allowed payload.

Here is my command, followed by my measurements:

 ping -v -f -c 100 -s 65507 192.168.0.24

• MAX payload used: 65507(i.e. 65535 including headers) bytes
• Number of round-trips: 100
• '-f' option used to flood (i.e. don't wait in between transfers)

I used it to connect to another PC in my subnet. Connected using wired ethernet. Here are the results:

linuxlab@linuxlab-murugan:/boot$ sudo ping -v -f -c 100 -s 65507 192.168.0.24
[sudo] password for linuxlab: 
ping: socket: Permission denied, attempting raw socket...
PING 192.168.0.24 (192.168.0.24) 65507(65535) bytes of data.
 
--- 192.168.0.24 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 1146ms
rtt min/avg/max/mdev = 11.428/11.490/11.702/0.153 ms, ipg/ewma 11.576/11.483 ms

Calculations:

65535 bytes x 2 sent and received 100 times. Avg time taken 11.490 milli seconds.

*Therefore: ( 65535 bytes x 2 to-and-fro ) x 8 bits-per-byte / 0.01149 sec = 91259878 bits per second i.e. 91.3 Mbps.

- please enter in comments if my answer is incorrect or needs improvement - Thanks