Calculate upload/download speed by ping

2020-02-16 12:01发布

问题:

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?

回答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.



回答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.



回答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.



回答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.



回答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.



回答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.



回答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.



回答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.