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?

Stjohn

nice article by the way about latency and bandwith rescomp.stanford.edu/~cheshire/rants/Latency.html – Ombudsman

Ping measure ICMP latency, not TCP or UDP. You cannot compare ICMP latency to TCP or UDP uploads or downloads. – Ensiform

The link posted by @Janning is down, here is an alternative: stuartcheshire.org/rants/Latency.html – Endrin

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.

Couscous

i dont understand your math: "1500 bytes and receive 1500 bytes, that's 24 kb." -- can you explain this? thanks – Enrollee

It's bytes to bits conversion, 3,000 bytes = 24,000 bits = 24 kb – Couscous

why i cant flood without sudo? – Glance

requirement for ping -f $ ping -f host PING host (X.X.X.X) 56(84) bytes of data. ping: cannot flood; minimal interval allowed for user is 200ms – Neotropical

This calculation is fundamentally wrong. If confuses latency with bandwidth and it fails to fill the wire. If I run the test once to my router (and properly divide data sent+received by time), I get 80Mb/s. But if I run 3 pings simultaneously, EACH gets 80Mb/s for a total of 240Mb/s. And if I run 10 simultaneously, I get 40Mb/s each for a total of 400Mb/s. Over gigabit ethernet (full duplex), which suggests router a little sluggish replying. – Stench

@Stench does it make any difference if you use bigger packet size? – Couscous

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.

Misdemean

To tie your analogy in with my answer, you can measure the bandwidth by sending 2 trucks one right after the other. If they show up on the other side of the country 30 minutes apart, then the bandwidth of your system is limited to 2 truckloads per hour. Perhaps the network is congested at a particularly inefficient tollbooth with a 30-minute queue. The fact that it took 5 days for each truck to get across the country is orthogonal. – Villalpando

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.

Villalpando

Thank you! All these persons that are full of confidence and answer NO! But in in theory, ping can measure maximum throughput by means of changing packet size and rate. However it is somewhat unreliable and definitely impractical, therefore uncommon. – Aromatize

See work like Estimating Available Bandwidth Using Packet Pair Probing or Informed Bandwidth Adaptation in Wi-Fi Networks usingPing-Pair or tools like Van Jacobson's pathchar. – Transcend

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.

Bifurcate

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.

Beef

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.

Delphine

To measure speed, you need size and time: 1) size: the packet size you're sending. | 2) time: the time of the packet spend between point A and B. | Your saying: "In the end, all you get is the time it takes for a Ping to run from A to B and back to A." All you get? This seems exactly what I need :p – Slow

Yes it is, maybe your knowledge is limited, but ping packets are small by default, but their size and rate can be increased to a point where they saturate the link, therefore they can be used to estimate link capacity. – Aromatize

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.

Flem

You can tweak ping packet size and ratio until you reach bandwidth limits, so it can also be used to give you an idea of that. – Aromatize

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.

Aromatize

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

Sickly

Ping uses ICMP, so it only measures the latency for that protocol, and that measurement can be very, very different than that for TCP, UDP, or other protocols that are actually used by applications. Ping is really only designed to test IP connectivity. – Ensiform