I don't know if this question is on-topic here, so please redirect me if not.

Trying to understand how TCP works, I had simulated a single point to point link using ns-3 simulator. On setting the bandwidth of the link to 5 Mbps, a suitable error rate and the delay to 5ms, I got a raw throughout of around 4.9 Mbps. However, after increasing the link to 50 Mbps, I could get only 16 Mbps. Further, reducing the delay to 1ms takes the throughput to ~40 Mbps.

Can someone please explain this huge difference?

EDIT: I understand how bandwidth and latency are different. I just want to know if my simulator is buggy, or is this expected from TCP.

  • 1
    I typed "how does latency affect tcp bandwidth" and found a number of useful articles, including this one. This question is off topic for Server Fault.
    – Tim
    Aug 24, 2017 at 2:54
  • 1
    Latency doesn't affect bandwidth. They're two different things. More or less latency doesn't change the bandwidth and more or less bandwidth doesn't change the latency. Perhaps you're wondering how bandwidth and latency affect network performance and how more or less of one or the other affects the perceived "speed" of the connection?
    – joeqwerty
    Aug 24, 2017 at 3:12
  • 1
    Latency, bandwidth, and throughput are each a different thing. Your link rate is your bandwidth, the latency is the link delay, and throughput is how much data you can push across the link (taking into account delays, including the host processing delays, and protocol overhead) in a specified time period.
    – Ron Maupin
    Aug 24, 2017 at 3:31
  • What happens if you set the rate to 15Mbps? Do you get almost 15Mbps? I suspect you are just hitting a limit of the simulator on your hardware. Aug 24, 2017 at 4:33
  • @Appleoddity the rate keeps reducing as I increase bandwidth. Another observation, if I make the delay 1ms, I get throughout around 40mbps, so I don't think hardware is at fault.
    – pulsejet
    Aug 24, 2017 at 4:52

3 Answers 3


In short: yes, too much latency can lower your total bandwidth, and the effect is more pronounced on serial-type connections - ie: connection which can not transfer any more data until an ACK for previous transmission is received.

The latency/bandwidth correlation become a problem only when the two values are much apart, for example having a very "wide", but high latency, link (or vice-versa - a very low latency but extremely "narrow" link).

Let me do an example using something as simple as a ping of 32 bytes on a WAN connection with about 50 ms latency (100 ms RTT). With such a connection, you can send a maximum of 10x 32b pings, for a grand total of 320b/s only in each direction! It is not a surprise that ping floods explicitly do not wait for the other party confirmation, or the flood would be non-existent.

If you can't lower latency, how can you work around the problem? Mainly using two ways:

  • sending larger packets (eg: using 1400 bytes sized pings);
  • sending more packets before waiting for confirmation.

TCP uses both systems: after a streaming connection is established (eg: a download is started), it both increases packet size up to a maximum value (the MSS - maximum segment size) and the number of packet sent without waiting for any confirmation/ack - aka TCP window scaling. Much work was spent on creating network stack capable of dynamically adjust the TCP window scaling, so this rarely needs to be manually adjusted nowadays. However, sometime a bad network driver and/or a strange corner case can prevent correct scaling, leading to reduced bandwidth.

Protocols which does not natively implement a window scaling (ie: IP and UDP) are more sensible to the bandwidth problem, and generally need assistence from the higher level application (where possible) or specific system tuning (for example, increasing maximum packet size, know as MTU).

Clearly, WAN connections are, due to their intrinsics higher latency, more prone to the problem. However, even very fast local connections can be affected.

Cases in point:

  • on a 10 Gb/s ethernet network, with ping RTT in the range of 0.05 ms, I initially achieved only about 30-40% of the total available bandwidth. Increasing the interface MTU to 9000 bytes (up from the standard 1500 bytes) completely solved the problem;
  • on a Gigabit ethernet connection, an Athereos interface driver interacted with the Linux network stack in a manner that prevented the TCP window to "open" to its maximum value, reducing performance. Manually setting an TCP window solved the problem.
  • Would like a small input of your thoughts in our case. We are accepting TCP requests from GPS devices located in India and using AWS server regions in US east. We are facing lagging issues (for a random set of devices) in terms of TCP data reception and see ACK packets missing in tcp dumps sometimes. Is latency also the/one of the, cause here?
    – coderunner
    Jul 17, 2019 at 13:41
  • @coderunner if you see missing ACKs, than you probably have a packet loss problem, rather than a "simple" latency issue.
    – shodanshok
    Jul 17, 2019 at 22:10
  • Yes thats what we are trying to figure out. What are the causes of delay. We went through the tcp dumps and it isnt significant enough to conclude its packet loss. Any ideas on how can we debug more to check if its packet loss and what can be the causes? In some cases the communication works fine but in some it does not, which is making it hard for us.
    – coderunner
    Jul 18, 2019 at 7:09

Too long for a comment but not quite a complete answer, but latency can effect throughput (bandwidth is a fixed property) :

Your TCP network stack needs to keep a copy of all transmitted packets in memory until it receives confirmation from the recipient that the packet was received, so packets can be retransmitted in case of packet loss.

The minimal size of that buffer is a simple multiplication:

<throughput> * <roundtrip time> = <retransmit buffer size> 

i.e. To support the maximum throughput for a gigabit NIC with a round trip time (=latency) of 0.2 milliseconds in your LAN the needed retransmit buffer would be:

  (1Gigabit/s = 10^9 bit/s) * 0.0002 s = 200000 bits = 25 Kb 

A fairly modest amount. A more realistic WAN latency of 2 milliseconds and you would need 250 Kb.

Unless your network driver dynamically adjusts the amount of memory allocated to your TCP retransmit buffer size, that buffer effectively becomes a limiter on the throughput your system can sustain, regardless of the available bandwidth in the network:

<max throughput>  = <retransmit buffer size> / <roundtrip time>

And any increase in latency reduces the effective throughput of your system.

Now imagine that rather than for a low latency LAN/WAN that same 250 Kb buffer is set for a high latency , high bandwidth connection such as for instance a satellite uplink with a typical 500 ms latency and your throughput gets limited to:

250 Kb / 0,5 s = 2 000 000 / 0,5 = 4 Mbit/s 

rather than the 1 Gbit bandwidth that a satellite internet connection can actually support (according to Wikipedia)

  • +1 cause this is interesting, but I doubt that its the real limiting factor in my case, since my latency at 5ms is still pretty low.
    – pulsejet
    Aug 24, 2017 at 11:56

Bandwidth = Capacity

Latency = Delay

Imagine that I have a 500 gallon pool and that I have a 1 gallon bucket for carrying water and a 5 gallon bucket for carrying water. It takes me 1 minute to carry either bucket from my water supply to the pool. If I use only the 1 gallon bucket to fill the pool then I'll need to make 500 trips, totaling 500 minutes of time spent carrying water from the water supply to the pool. If I use only the 5 gallon bucket to fill the pool then I need only make 100 trips, totaling 100 minutes of time spent carrying water from the water supply to the pool.

The time it takes to walk to the pool (latency) doesn't affect how much water I can carry with each bucket (bandwidth) and conversely, the size of the bucket (bandwidth) doesn't change the time it takes to walk to the pool (latency).

The end result is that the pool will fill up 5 times faster when using the 5 gallon bucket than when using the 1 gallon bucket because the 5 gallon bucket is bigger, not because it's faster.

  • I know this, but that doesn't answer why the observed throughout is different. So do you mean the simulator is buggy? I was hoping on something related to the way TCP works.
    – pulsejet
    Aug 24, 2017 at 4:23
  • 2
    I'm not an expert, but I believe latency does affect TCP bandwidth. it says here "Excessive latency creates bottlenecks that prevent data from filling the network pipe, thus decreasing effective bandwidth. "
    – Tim
    Aug 24, 2017 at 5:00
  • @Tim, I guess we need to decide if we're talking about bandwidth as as a technical definition or if we're talking about effective bandwidth, throughput, etc. I wasn't speaking of effective bandwidth, throughput, etc. Bandwidth is a fixed property. My 1GbE connection is 1GbE regardless of how much latency exists. It can't be changed by latency. You make a very good point though, dealing with the effects of latency on effective bandwidth/throughput is a real world problem. I got caught up answering the question a little too literally I suppose.
    – joeqwerty
    Aug 24, 2017 at 11:20
  • 1
    Ah, I see the confusion. I believe I mistyped bandwidth everywhere where I meant throughput. Like I said, I have fixed the bandwidth of the simulated link; what is to be checked is the effective TCP throughput.
    – pulsejet
    Aug 24, 2017 at 12:00

Not the answer you're looking for? Browse other questions tagged .