# Is the bandwidth of cable constrained by its length?

If a certain cable has a bandwidth of `10 mbps`, that means in can contain 10 megabytes of data inside it at any given second.

However, does this assume some standard length?

The analogy I've been given is that the cable transmitting data is like a pipe carrying water, and the bandwidth is like the amount of water the pipe can hold. However, longer pipes can hold more water.

Do longer cables have more bandwidth?

If a certain cable has a bandwidth of 10 mbps, that means in can contain 10 megabytes of data inside it at any given second.

Not at all, it means it can send 10 megabits over the time period of one second.

However, does this assume some standard length?

This depends on the technology, but most often: yes. For example, the popular 10base-T ethernet specification assumes a nominal maximum length of 100m. Longer than that your bandwidth will most likely drop (quickly to 0). Even with short enough cables other factors can diminish your throughput however, e.g. bad connectors.

The analogy I've been given is that the cable transmitting data is like a pipe carrying water, and the bandwidth is like the amount of water the pipe can hold. However, longer pipes can hold more water.

Decent analogy, completely wrong interpretation. It is not about how much water a pipe can hold, almost nobody really cares about that. It's about how much water you can get through at a given time. E.g. you don't care that your garden hose can hold a full swimming pool worth of water at once, you care how fast that hose can fill that swimming pool so you can take a fresh dive. In hydraulics terms, you care about discharge. This does not increase as a factor of length (rather decrease). It increases based on diameter and pressure.

Bandwidth is comparable to discharge in this analogy, so no it does increase with length (again, rather decrese), but mainly depends on other factors like modulation and interference levels.

You cannot say that an ethernet cable can hold data (bits) as a water pipe can hold water. Bits are modulated on an electromagnetic wave, which is only there for as long as that wave is traveling your cable (which is even an over-simplified statement). There is not a tap that you can shut so that all the bits currently in the cable stay there.

Do longer cables have more bandwidth?

No

• Down vote from me, this answer is flat out wrong / misleading. Please see my answer below. Apr 10, 2017 at 20:17

I feel the other two answers here are actually giving you misleading information:

If a certain cable has a bandwidth of 10 mbps, that means in can contain 10 megabytes of data inside it at any given second.

OK first lets clarify terminology, “10Mbps” is used to denominate a unit of speed “megabits per second” which is 10,000,000 bits per second. Megabytes being 8 times larger and MB (MegaBytes) usually used to denote volume of data as a unit. I assume you meant the former, 10Mbps.

Secondly, I think you have misunderstood some basic networking aspects based on the wording in your question and I don’t think the other answers are clearing up your misunderstanding, only worsening it. There is almost no link to the length of a cable and the speed at which data is sent across it. The speed at which electrical signals travel down a copper wire is related to the dialectric constant of the physical cable and casing properties. Long story short, they can travel at nearly the speed of light, copper cabling for all intents and purposes isn’t slower than fibre optics which many people seem to think.

If you really want to say how much data a cable can "hold", irrelevant of length, the answer would be "1 bit" (a pair can be transitioning form DC+ to DC- or from DC- to DC+ at any one moment in time).

Thirdly, speed is not the same as bandwidth. In networking nomenclature we use the word "bandwidth" to describe the volume of data that was moved. We can move 10MBs (megabytes) of data and 1Mbps (megabits per second), or we can move it at 10Mbps and it will take 1/10th of the time it would have taken at 1Mbps. The speed at which data is transferred over a copper cable does not change based on the length of the cable. We can have a 5 meter cable that runs at 10Mbps, 100Mbps, 1Gbps, 10Gbps etc (there is a slight increase in delay with longer cables as I said above, the electrical signal does have to propagate down the cable, but this is so tiny it is negligible, it doesn’t change the speed of the network link).

`...a nominal maximum length of 100m. Longer than that your bandwidth will most likely drop (quickly to 0).` - the bandwidth doesn't drop, it either "is" or it "isn't". The data was either received without error at the speed the link operates at (10Mbps, or 100Mbps etc.) or it wasn’t and the data must be resent. This is only if you are using protocols that support re-transmission and/or you are sending data which must be re-sent (e.g. live TV streams, dropped packets are lost and not usually retransmitted). Since speed and bandwidth are not the same thing, it is possible for the error rate to increase without the bandwidth dropping by sending larger frames or packets for example, so few packets need to be successfully send and received because they carry more data.

`so no it does [not] increase with length (again, rather decrese)` - nope, bandwidth is not dependent on length. Again, the misuse of phrasing is making things unclear. I take bandwidth to mean "the goodput of data successfully transferred".

`The original Ethernet specification limits the individual copper cable lengths to 100 meters, because of the latency time of getting a packet from end-to-end then getting the returning ACK before timing out.` - No. ACK is something that happens at the transport layer in TCP. The length of 100 meters likely stems from CMSA/CD (Carrier-Sense Multiple Access with Collision Detection). This is the process of listening on the wire for a specific time, to check if another device is transmitting, if no device is transmitting (nothing is received) then it is assumed to be safe to transmit without a collision occurring. How long should we wait before we know its safe to transmit? We wait as long as it would take for the signal to travel from a device 100 meters away!

`For instance: when you are transferring 10 MB of data, longer cables will be a bit slower to transfer that total amount than shorter ones simply because the signals travel at about 2/3 of the speed of light in copper. More length means more latency.` - this is a bit of misnomer. I touched on it above. The increase in delay from the extra cable length is so small it has no measurable impact. Wikipedia (https://en.wikipedia.org/wiki/Speed_of_electricity) lists the speed of electricity to be in the range of 50%-99% the speed of light. At 0.5 c it takes 0.0000006 seconds for the electrical signal to travel 100 meters. For a 10 meter cable it takes “one less zero”, 0.000006 seconds. This has no measurable impact on you day-to-day application performance. What does have an impact is the operating speed, such as 10Mbps or 100Mbps. On a 10 meter length of Cat5e cable running at 10Mbps you will only get 10Mbps, no more, no less. Equally, if you now connect that same 10 meter length of Cat5e up at 100Mbps it will run at 100Mbps, no more, no less. What really makes a difference are factors like the encoding scheme used (https://en.wikipedia.org/wiki/64b/66b_encoding), serialisation delay, the error detection and correction methods used (see https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction and https://en.wikipedia.org/wiki/Hamming_code), etc. This is because as the length increases so will the attenuation, NeXT, FeXT (https://en.wikipedia.org/wiki/Crosstalk and https://en.wikipedia.org/wiki/Attenuation-to-crosstalk_ratio) etc. resulting in (eventually) data loss.

• You contradict yourself: First you state that data is or isn't received (so a binary situation), but then you also state that it is possible that there are partial errors, which contradicts the binary situation. So according to that the 'useful bandwidth' (i.e. bytes received without errors) decreases and is not an all/nothing situation. Though I do admit (also state this in my answer) in classical ethernet this is a very windowed situation, you will go very quickly from almost 0% error rate to almost 100% error rate. Apr 11, 2017 at 8:24
• @KillianDS `First you state that data is or isn't received (so a binary situation), but then you also state that it is possible that there are partial errors, which contradicts the binary situation` - I have not said `partial errors` anywhere in my answer. I have said `The data was either received without error at the speed the link operates at (10Mbps, or 100Mbps etc.) or it wasn’t`. Apr 11, 2017 at 8:31
• ... in the case of bit errors and depending on what detection and restoration coding’s are being used, the error can be detected and corrected (so the entire frame is intact and can be used/kept), or an error detected but not corrected (so the entire frame must be retransmitted) – there is no in-between scenario in which specific bits of a frame could be retransmitted. Apr 11, 2017 at 8:31
• but that is on frame level, not on an entire stream. Are you saying that if a single frame contains errors all frames will contain errors? Then yes it's either all or nothing, but if some frames come through correctly and some incorrectly then your actual BW will be anywhere between 0 and max. Apr 11, 2017 at 9:39
• To come back on the first one: yes, you don't explicitly say partial errors. But you talk about frame-level errors, frames are part of a stream and nobody is going to look at BW in terms of a single frame. So if only a subset of frames in a stream have errors this translates to partial errors. But I could have stated that clearer. Apr 11, 2017 at 10:01

No. Bandwidth is not something the cable contains. It is simply a physical connection medium. 10mbps is the speed of data flow, not the quantity.

The original Ethernet specification limits the individual copper cable lengths to 100 meters, because of the latency time of getting a packet from end-to-end then getting the returning ACK before timing out.

To go further than that you need a bridge.

None of this should affect the speed of the cable. But it can affect total throughput.

For instance: when you are transferring 10 MB of data, longer cables will be a bit slower to transfer that total amount than shorter ones simply because the signals travel at about 2/3 of the speed of light in copper. More length means more latency.

Adding bridges will also slow down the total throughput a bit because of the latency involved in receiving packets, acknowledging them, then regenerating them to be passed along to the next segment.

• That length has nothing to do with latency and ACK. The 100m limit comes from the fact that with the (minimum) cable parameters that the 802.3 standard demands your signal degrades significantly around that 100m mark. Apr 11, 2017 at 8:34
• Also, bridges by itself don't necessarily reduce throughput. If you take a decent (\$\$\$) bridge and just put it in a point-to-point link you should see no throughput drop. The throughput drop usually comes from either cheap bridges that simply can't reach max throughput or from the fact that you're sharing the network and colissions reduces your actual throughput. Apr 11, 2017 at 8:37
• Finally, while the latency point is technically correct, this is negligible, we're talking about ~500ns transmission time with 100m vs e.g. ~50ns with 10m Apr 11, 2017 at 8:41