Does increasing the bandwidth on a link from, let's say, 1mb to 30mb reduce the RTT?

I have found one answer saying no. Can someone please explain?

Also, what are the best mechanisms to reduce RTT?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Commented Jan 3, 2021 at 5:26

5 Answers 5


Does increasing the bandwidth on a link from lets say 1mb to 30mb reduce the RTT?

In short, yes; you are changing serialization delay; at 1Mbps the serialization delay is non-trivial.

Compare the serialization delay for a 1500 Byte packet at 1Mbps and 30Mbps:

1500 Bytes * 8 bits/Byte / 1,000,000 bits/second    = 12 milliseconds (at 1Mbps)
1500 Bytes * 8 bits/Byte / 30,000,000 bits/second   = 0.4 milliseconds (at 30Mbps)

Remember also that those are unidirectional numbers; you should double them when considering RTT. Whether you care about 11.6 milliseconds difference in each direction at 1500 bytes is another question, but strictly speaking you can influence RTT with link speed.

  • 1m vs. 30m on, say, a 100m ethernet link, will make no difference. Each frame, atm cell, etc. moves at link speed.
    – Ricky
    Commented Jun 15, 2014 at 19:08
  • 1
    As common as ethernet is, nobody said anything about it so it's premature to insist that it is required. There are plenty of WAN services offered without ethernet. Raw bitrate in the NIC is what should be used in the formula above Commented Jun 15, 2014 at 20:24
  • Hi Mike, Thank you for your answer appreciate it. What if I'm simply using ping? If I ping from one end to the other will the ping RTT remain the same indifferent from 100Mb link to a 1Gb link. (Complete different physical NIC) Not transferring any data from one point to another where serialisation delays are accounted for. Thanks Commented Jun 16, 2014 at 1:45
  • 1
    Please explain what problem you're solving by reducing latency. It sounds like you could be trying to solve a specific problem but we need more information about it Commented Jun 16, 2014 at 10:37

Does increasing the bandwidth on a link from lets say 1mb to 30mb reduce the RTT?

No, increasing the bandwidth does not reduce RTT strictly speaking. I say "strictly speaking" because it depends on what your are measuring!

Scenario 1: The physical layer

Given the following simple topology which is easy to follow, a copper Ethernet connection running at 1Mbps with an MTU of 1500 bytes between two devices with a 10 meter cable, this has the same RTT (the time it would take for an ICMP echo request packet to travel from device 1 to device 2 and the ICMP echo reply message to travel from device 2 back to device 1) as a 10/30/50/100mbps copper Ethernet connection between them with a 1500 byte MTU on the same 10 meter cable.

This is because the "delay" of the signal down the copper cable is related to its dialectic constant (relative permittivity). See those two Wikipedia pages for additional information on the physics which are out of scope here.

Essentially the "flight time" of the electrical signals down the copper cable is the same speed for a 10Mbps and a 1000Mbps connection when using the same length and grade Cat5e cable. The difference is that with a 10Mbps connection data is encoded on to the wire less frequently then a 100Mbps connection, so there are smaller gaps between the bits of data as they are placed on to the wire (this is called serialisation delay). These two wikipedia articles expand these concepts further: Bit time and Slot time.

Scenario 2: Layer 4 and above (TCP example)

Given the following example topology, a copper Ethernet connection running at 1Mbps with an MTU of 1500 bytes between two devices with a 10 meter cable. If you have X amount of data which we shall pretend is 100 Megabytes of data to transport between device 1 and device 2, this will take longer than it would with an 30 or 100Mbps copper Ethernet connection with an MTU of 1500 bytes on a 10 meter copper cable between the same two devices. This is because it takes longer to encode and transmit the data on the wire and the receiving NIC will be equally as slow at receiving and decoding the signals.

Here the RTT of "actual data" that is perhaps a single 100MB file will take longer because with the higher level protocols introduced you not only have to transfer the data but also may SYNs, ACKs and PUSH's packets exchanged here using additional bit times, before at the application layer a message can be sent from device 2 to device 1 saying "I have received all the data now".

Also, what is the best mechanisms to reduce RTT.

Short answer: not much

Long answer:

To bring this into a real life example expanding on the examples above; If you are "pinging" between two devices that are connected together via several intermediary routers and/or switches the RTT is a product of the physical distance and the time it takes for the signals to travel that far and back through all those devices (basically). If QoS is configured on these devices that can increase the end-to-end delay too and complicate the model further.

There isn't much you can do here apart from (in a purely hypothetical situation where money is no object and politics don't matter etc); Install a fibre connection that runs directly from device 1 to device 2 cutting out all the switches and routers in between. That would be an ideal scenario. Realistically you could upgrade any copper or wireless links to fibre (not that fibre is hugely faster [i], [ii]) and try to make the connection path as direct as possible so that data passes through the least amount of intermediary devices and different physical connections. QoS tuning and traffic engineering (constraint based routing) can also help over larger distances with many hops in between.

If you are wanting to transfer data between to points with what you consider to have "too high an RTT" you can look at technologies like TCP SACK which is in use in many places already, but if you read up on that it will give you a starting point as there are other similar technologies you can then look into. This includes technologies such as WAN accelerators and compressors, although that would be digressing out of the scope of this topic. You must consider with data transfer over a link with a high RTT the BDP (Bandwidth Delay Product, [iii]) - when using something like TCP this will always hold you back.

[i] The "flight" time over a copper dielectric medium is very similar to a fibre waveguide

[ii] This could change though, new research and technologies will hopefully bring the speed of light in a fibre up from the average of 0.6*c to near 1.0*c, http://www.orc.soton.ac.uk/speedoflight.html

[iii] http://www.kehlet.cx/articles/99.html - BDP example

  • Thank you for your answer Bensley. So if I want to improve my ping to my ISP (lets say I have a dedicated servers in my ISP) can I reduce my ping to them by increasing my link at my office? Thanks Commented Jun 16, 2014 at 1:49
  • Unless you make a major change - prehaps if you currently had a wireless link and you went to fibre, or you had a coppper ADSL link which passes through many routers (as ADSL often does) before you reach your servers, then changing to fibre might reduce the RTT. Just going from 10 to 30mbps on the same link wont change the RTT though.= (perhaps by some nanoseconds! Nothing you would notice though). This is becasue your signal travels through less peices of equipment (usually) to get to the destination...
    – Baldrick
    Commented Jun 16, 2014 at 20:37
  • ...If you had a copper connection over 10 miles, if would need to be connected to many switches and/or routers because the signal has to be repeated. Each time you insert another devices into the path, the RTT increases. This is because each devices that receives the signal must interpret it before forwarding it on. When you compare a 1Gbps connection and a 10Gbps connection, you are NOT moving 1Gb of data 10 times per second, you are moving 10Gb of data once per second (You're moving more data, not moving data faster)
    – Baldrick
    Commented Jun 16, 2014 at 20:42
  • @networkninja why are you so obsessed with reducing ping times. If you really are on a 1Mbps link, ping isn't always an accurate measurement of latency since it may be different than the packet size of your real traffic
    – user5025
    Commented Jun 17, 2014 at 14:08

The thing most directly affecting RTT is signalling speed. Look at the progression of ethernet over the eons: 10M, 100M, 1G, 10G, 40G, and 100G. Each following version (except 40G) is 10x faster than the previous; the time to transmit a single bit is 1/10th as long. The time to transmit a full (1500B) frame drops by a factor of 10.

So, the answer to your question depends on the link layer. If the change in bandwidth has no corresponding change in link speed, then it will have minimal effect on RTT -- because traffic policing isn't done per bit. For example, my office metro-e connection is physically 1G, but it's shaped to 100M at both ends. Bits flow at 1G speeds; ethernet frames will be delayed as necessary to keep the average (over 1s, 10s, etc.) at or below 100M. In simple terms, a single frame transmits at link speed.

If you're talking about DSL, then the change in bandwidth is most likely also a change in link speed. But not always. The sync speed will normally be higher than the profile rate. My DSL line syncs at 8M down, 1M up, but the profile limits it to 6/512k. I've seen Uverse lines sync as high as 60M but still have a 25M profile.


No one mentioned the link loading.

On otherwise empty links then not much difference between 1Mb and 30Mb - sure the encoding can be done in 1/30th the time but this is negligible if the distance is the dominating factor.

However, if the 1Mb link is heavily loaded (overloaded?) then you will see increased (and fluctuating) ping times.

The same traffic load on a 30Mb link represents only a few % of its capacity and so ping times will be faster and more consistent.

The Two-Way Active Measurement Protocol (TWAMP) defines a flexible method for measuring round-trip IP performance among any two devices in a network that support the standard.


The real answer is it's complicated.

Latency is made up of multiple components.

  1. Time spent travelling through the physical medium
  2. Time spent sitting in queues
  3. Time spent serialising and deserialising data
  4. Time spent in processing

Time spent travelling through the physical medium can only be changed by choosing a different physical medium.

Time spent sitting in queues will generally be reduced by having faster links. So will time spent serialising and de-serialising data.

The effects on processing can get complicated. If the processing step stays the same then it will generally take less time at a faster data rate. However techniques designed to extract more bandwidth from existing links may also introduce additional processing delays. A classic example of this is DSL interleaving.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.