Internet?

[edeca]

To return to my earlier (slightly tenuous) analogy of a water pipe. "ping" measures the time it takes for water to flow from one end of the pipe to the other and back again. This is the round trip time (or RTT). It is measured in some unit of seconds.

The "speed" or bandwidth/bitrate is the width of your water pipe, which determines how much water can flow at concurrently. It is measured in some unit of megabytes per second.

Imagine loading a 747 jumbo jet with terabyte hard drives. It has a massive bandwidth because it can carry lots of data at once but a very slow round trip time because it will take 8 hours to fly across the ocean.

 

[Sceadwian]

Traffic throttling for bit rate constraint is not directly related to ping, that's a separate routing decision made by the various trunks on the Internet to keep massive traffic from single target from saturating large capacity data lines. I have a 20+meg Internet connection, that could if properly constructed packets could be formed down some smaller websites.

In your example of the hurdles you'd have to look at each hurdle as an barrier that will slow the runner down depending on how massive they are as they pass through it. A lot of data will get slowed down to keep high bandwidth links from saturating higher speed links. But little packets like ping packets are important because they tell the actual transit time of the data. This is why bandwidth tests are always done as close to the originator as possible. The first time you hit a true major internet hub you bandwidth can get crippled. But that's on a per target basis, in the real world the Internet is far more distributed so even a single web page could actually be held on dozens of different web servers with the traffic dynamically routed.

PING can drastically effect TCP/IP bitrate outside of router based throttle simply because TCP/IP requires each and every packet to be acknowledge send and received by both parties and there can be some pretty serious delays if something arives out of order and it has to re-negotiate the packet order.

Many streaming protocols rely on UDP because you can flood that with as much info as you want as fast as you want, and if something along the way drops out you can request a resend, basically any smart UDP protocol will stream faster than TCP/IP

Both ping and bandwidth to a specific target have to take into account every point inbetween to have any true meaning.

My 20meg downlink doesn't mean much for some major sites because they bandwidth throttle, but that throttle is more than good enough for basic speed.

In something like a distributed torrent where you're connected to dozens of other source for the same data and it's distributed intelligently you can download at fantastic speeds because the load is handle a little bit here and there by the various sources, no one target is being loaded. The overhead slows the overall efficiency due to protocol overhead but the overall benefit is large amounts of data can be transfered very efficiently from 'the cloud' to a single target as fast as the conglomeration of links will allow.

 

[Sceadwian]

To return to my earlier (slightly tenuous) analogy of a water pipe. "ping" measures the time it takes for water to flow from one end of the pipe to the other and back again. This is the round trip time (or RTT). It is measured in some unit of seconds.

The "speed" or bandwidth/bitrate is the width of your water pipe, which determines how much water can flow at concurrently. It is measured in some unit of megabytes per second.

Imagine loading a 747 jumbo jet with terabyte hard drives. It has a massive bandwidth because it can carry lots of data at once but a very slow round trip time because it will take 8 hours to fly across the ocean.

The water analogy is a poor one it simply doesn't work like that, the Internet is a highly dynamic environment that can not have such simple comparisons applied to it (much like electricity)

The 747 references is also very poor because again the real Internet simply does NOT work like that, dynamic traffic routing and bandwidth throttling are more like the dynamic hurdle barrier I pointed at above.

The 747 reference can be shot down (pun intended) by the fact that bandwidth throttling can be eliminated by the use of many parallel data channels such as in the torrent protocol. More and more sites and system are using something similar to the torrent protocol to distribute data and processing load among many different servers to great effect. So called 'cloud' technology is very fault redundant (to a degree) and the inefficiency of the extra protocol layers is offset by the fact that the Internet has a glut of capacity currently, and plenty left to be able to use because of the fiber explosion a few years ago.

Shooting a million 1lb loads will get you data back and forth faster than shooting a single million pound load because it bypasses a lot of throttling considerations, the efficiency drops but the overall bandwidth increase is dramatic.

 

[edeca]

Traffic throttling for bit rate constraint is not directly related to ping, that's a separate routing decision made by the various trunks on the Internet to keep massive traffic from single target from saturating large capacity data lines.

Er, OK. "Ping" (ICMP in this instance) has nothing to do with data rates. It doesn't measure anything except the round trip time. There is no direct or indirect relationship. This is the only thing I have been discussing in response to the original question.

As I have said multiple times in this thread you could have a connection with massive bandwidth (gigabytes per second) but huge latency (round trip time on a wall clock). For example an optical fiber to the tropical moon of Endor: you may get good data rates (bytes/second) but slow transit times from data in at one end to data out at the other.

Let me be very clear in case my point was lost in translation: there is no relationship between an ICMP ping (latency) and the bandwidth (data rate) between two points.

The water pipe analogy is wholly correct and frequently used to teach this distinction.

PING can drastically effect TCP/IP bitrate outside of router based throttle simply because TCP/IP requires each and every packet to be acknowledge send and received

I have no idea how ICMP ping here is supposed to relate to TCP/IP acknowledgements. The two are not inter-related in any way.

With regard to acknowledgements per packet, reference to https://tools.ietf.org/html/rfc2018 is in order.

and there can be some pretty serious delays if something arives out of order and it has to re-negotiate the packet order.

Packet order is not "renegotiated", the OS simply reorders data in memory before it is passed to the application.

There are many things that affect absolute speed in TCP/IP: slow start, window scaling, MTU, TCP options, the evil bit. It is impossible to just throw together sentences with the word "dynamic" and "cloud" and "internet hub".

 

[Sceadwian]

Increase the ping time and you'll see the relation Edeca. The rate at which the ping times are sent will eventually trigger throttling, and the ping rate will drop. Based on rate alone, increase packet size and you may see a change as well. A true ping is a tiny little packet sent very infrequently, relative to the rest of internet traffic.

Water flow is directly linked to pressure and hole size. In the real world in referenced to the Internet, the size of the hole the packet sees is indirectly related to the number and amount of packets traveling. Again distributed 'cloud' based protocols can bypass the throttling effect of bandwidth through hubs, and reduce the effect of pings times because packet transfers occur at the same time to different locations.

 

[edeca]

can bypass the throttling effect of bandwidth through hubs

Pro-tip: the internet uses routers, not hubs.

 

[KeepItSimpleStupid]

ping is in units of time. bitrate is in the units of frequency. Frequency = 1/f . Probably not entirely true in this cae, but there is your analogy.

 

[Sceadwian]

Pro-tip: the internet uses routers, not hubs.

Pro-tip: Doesn't matter if the router is a perceived as a hub or not edeca... There are still hubs for the physical connections. Ever seen a physical connection mapping of the Internet? They all go through massive centralized physical hubs, the routing layer is an abstract of that... What you consider the net is an abstract of the physical layer which is as it is DEALT with by the various higher layers.

 

[3v0]

I was thinking the only place you will find hubs is flea markets and junk boxes.

 

[Electroenthusiast]

After reading all the above posts, i get the point. I had also used a throttling addon for firefox, which used to throttle my internet speed. I had also though its working to be in the same way, back then.