aphelps Loc: Central Ohio

Internet speeds are not the same as bandwidth. Think of two water pipes with different diameters. In the smaller pipe the water is flowing at 10 units/sec. This is equivalent to Mbps download SPEED. Now look at the larger pipe where the water SPEED is the same 10 units/sec. However, the larger diameter at the same SPEED can deliver a much higher VOLUME of water. The volume of water per sec is much higher than with the small pipe. So it's BANDWIDTH is greater. Marketing folks mistakenly equate speed with bandwidth. It is really bandwidth (using above) that determines how apps perform. This is usually measured by adding up the rated bandwidth requirement of each connected device. This can be measured in info packets per sec or volume of info per second. In summary, internet speed Mbps is a measure of bit speed while true bandwidth is a measure info packets per second.

fetzler Loc: North West PA

Your thinking is not correct. Morse code is the simplest form of data communication. It is well known that the faster Morse is sent the bandwidth of the signal increases. This increase in bandwidth is a result of the mathematics of wave forms. Modern digital signals are more complex than a Morse Signal none-the-less more bandwidth is required to send more information per unit time.

The speed of information on a wire is the speed of light reduced by a factor to account of interactions with the medium of transfer. Information travels at the speed of light in a vacuum (e.g. Radio Signals in space). Using more frequency space is required to transfer more information.

TriX Loc: Raleigh, NC

It’s perhaps an obtuse concept to grasp (and I take your point about Morse speed and bandwidth consumed), but think about it this way. Speed does drive bandwidth (high bandwidth depends on high speed), but they are not synonymous. There are several considerations. First, our internet traffic is typically TCP/IP. The TCP transport layer assures complete transfer of the data packets, in order, with error correction and retries if necessary. Those retries and retransmission of bad or lost packets limits the bandwidth of the actual information sent even though the speed of the connection remains high and unchanged.

Then there’s the issue of latency, which is driven not only by the speed of the transmission media, but the distance and the number of “hops” of the connection. Each retry or acknowledgement of a packet involves latency, which decreases bandwidth. And of course, there’s the “payload” (the actual data) size of the packet. Not the entire packet is data and the payload size is not always the same. There’s overhead from the header and CRC/trailer of the packet plus depending on the support for jumbo packets, the payload may vary in size. The net-net is you may have a 1Gbit internet connection, but the actual bandwidth of the link will vary due to latency, the number of errors/retries, and the size of the data files transmitted (the header and CRC/trailer size or “overhead” of the packet remain the same whether the payload is 100 bits or 1500 bits).

So the net-net is that BW and speed ARE related and more information transmitted does equal more bandwidth, but they are not synonymous. Make sense?

fetzler Loc: North West PA

What you are discussing is the issue of error correction that is often necessary for digital communications. If noise increases the number of errors then of course information transfer slows as additional packets must be sent.

Early modes of transmission did (do) not have error correction. Morse signals have a rather narrow band width. AM radio has a considerably wider band width as 2 side bands and a carrier is sent. The frequency band with is moderate for AM. FM radio signals send even more frequencies (higher fidelity) hand have a higher bandwidth than AM radio.
Analog Television has a much greater band width than FM as both a picture and sound are send. Again more information more bandwidth.

TriX Loc: Raleigh, NC

Since I’ve been a Ham radio operator since the late 50s, and hold an extra class license as well as formally holding an FCC license and being an engineer at a UHF TV station, you can bet I understand bandwidth for every communication mode you can think up from FT8 to Analog TV.

Similarly, from the years I spent at NetApp (who popularized NAS in the world), DDN (who networked the world’s fastest storage with IB (infiniband), EMC/Isilon (networked NAS) and Panzura (global file systems over IP), I’ve done a LOT of benchmarking of network speeds, and I can tell you that the actual BW NEVER meets the theoretical transfer speed for the reasons I’ve provided. When GigE (1,000 Mb) came out and later 10GigE (10Gb) we never saw TCP/IP running at much over 50%-60% of the theoretical BW. Even using UDP (without error correction) and jumbo frames, the best we could do was about 90% of theoretical BW, and that using large data sets. At Panzura, our limitation on BW was the coast to coast latency for TCP/IP (typically in the 60-70 nsec region). If you look at the packet (transport layer of the OSI model) diagram I posted, it should be clear to you that there is ALWAYS overhead in every packet that prevents the entire packet from being used for data.

But don’t take my word for it. Just Google network speed vs BW and read the distinction published by commercial/enterprise ISPs and long haul providers. Here are a few:

https://lightyear.ai/blogs/internet-speed-vs-bandwidth
https://www.highspeedinternet.com/resources/internet-speed-vs-bandwidth
https://blog.equinix.com/blog/2019/05/09/network-speed-vs-bandwidth/
https://www.techadvance.co.uk/bandwidth-vs-internet-speedwhats-the-difference/
https://www.utopiafiber.com/2020/10/15/bandwidth-vs-speed/

aphelps Loc: Central Ohio

All I said was that network speed and bandwidth are not the same. This from reliable knowledge. Also see further respnses below. I did make this up out oh thin air. I was simply reporting what my research shows. Trying to help fell ow UHH members. Your respnse about Morse Code confirms the misundetstanding. Try to be more helpful in your respnses.

Schoee Loc: Europe

With 500 Mbps up and down, my bandwidth is fine :)

alinoh Loc: Westerville OH

Your internet speed is fine. How did you calculate bandwidth?

lindmike

My head hurts

jerryc41 Loc: Catskill Mts of NY

We would all like the maximum possible, but that isn't possible. I am limited to what Spectrum decides to send my way.

Schoee Loc: Europe

it takes me approx 2 seconds to download an episode of Seinfeld from Netflix to my phone to watch at the gym. Not very scientific but good enough for me :)

BebuLamar

You said units/sec what do you mean? If a pipe is deliver 1gal/sec regardless of how big it is it's still 1gal/sec. So what kind of unit are you talking about?

TriX Loc: Raleigh, NC

MB or GB of DATA/sec. would be a useful measurement. A benchmark usually consists of uploading or downloading various file sizes (a few larger files will typically yield a higher throughput than a plethora of small files) and reading the results. You could read packets/sec, but since each packet could contain a different amount of data, that’s not a representative measurement.

What we really want to know is how fast we can move a file or files from point A to point B. Example: you may have a 1Gb/sec pipe, but if it only moves real world data at 60 MB/sec (the theoretical max is 125MB/sec) due to latency, errors and retries, that’s what really matters.

BebuLamar

1MB/sec is the same regardless. If you subcribe to 1Gb/sec internet and you get 100Mb/speed then it just doesn't perform as promised. Yeah I know the actually speed is always somewhat less than what they told you but that's just that. Just like all the flashes I tested their GN is less than what listed in the manual.

TriX Loc: Raleigh, NC

If you want to look at it that way, fine, but the important point is that there IS a difference between the theoretical frame rate of a link (referred to as the speed) and the actual throughput or bandwidth of the connection. Internet providers know this and are careful to make the distinction - see the links I provided above.

Btw, in addition to the overhead I mentioned previously, it’s important to remember that unlike IBM’s ill fated token ring where transmissions over the network are controlled by passing a token. Ethernet has no “traffic cop” to insure that multiple clients don”t “talk” at the same time - when this happens, it causes delays and retries or times out. If you want to read more on collision detection on Ethernet (CSMA/CD) here’s a link: https://en.m.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection