1

Let's consider A (client) and B (server) where A makes download from B.

  • How much can a bad routing from A to B affect the download speed ?

    A traceroute from A to B returns a path that is 10 hops long, with a round-trip latency of 300ms. It also shows ~10% packet loss at hop four. Under normal conditions, the average round-trip latency between A and B is between 10ms and 30ms.

  • Could this sort of impact reduce A download speed drasticaly or as long as both side and routes have enough link for the full speed of A from B and vice-versa it should maintain the same speed ?

  • Besides tracert and the ping analyse of A to B what else is used to identify the problem ?

If you need extra information please let me know.

voretaq7
  • 79,345
  • 17
  • 128
  • 213
Prix
  • 4,703
  • 3
  • 23
  • 25

2 Answers2

4

This question touches on several issues relating to various things. I'll try and answer them in order, and then provide a bit more detailed explanation.

(Paraphrasing slightly):

A traceroute from A to B returns a path that is 10 hops long, with a round-trip latency of 300ms. It also shows ~10% packet loss at hop four. Under normal conditions, the average round-trip latency between A and B is between 10ms and 30ms.

Addressing these points in order:

  1. The number of hops in a path is pretty much irrelevant to effective throughput. What matters is the end-to-end latency, average packet loss, and the settings in the TCP stacks in A and B, particularly relating to TCP windowing. (More details below.)
  2. 10% packet loss at hop four in a traceroute is unlikely to be symptomatic of problems with the end-to-end connection. Many routers implement features such as control plane policing or ICMP rate limiting (particularly the generation of ICMP "TTL expired in transit" messages, which traceroute relies upon). The only reliable way to measure packet loss is to examine the counters in your TCP stack, or to capture packets from your actual data flow using tcpdump/Wireshark and examine the capture using a protocol analyser.
  3. It's very rare that a round trip latency to a given internet destination will change from 10-30ms to 300ms. Such changes would most likely be the result of a disastrous routing policy change within an ISP, and would likely be rectified as soon as possible. Perhaps the only case where I can see this occurring normally would be in a site which had a single physical (Ethernet, DSL etc) connection to their ISP with a satellite backup.

Regarding the impact of latency on download speed, many TCP implementations are configured to use a receive window size of 64kbytes. When you have a high latency connection between two hosts (more specifically a high bandwidth delay product, this window size can often limit your effective throughput, as TCP will stop transmitting buffered data until it starts receiving ACKs for already sent data from the far end.

EDIT: Depending on how you have pingplotter configured, it may not be providing you with an accurate representation of the loss on your connection. If pingplotter is using ICMP, it's possible that networks will drop/deprioritise this traffic in times of congestion, as it is not considered 'user traffic'. Also, any data about the loss at intermediate hops should be considered suspect, for the reasons mentioned above.

If possible, it would be interesting to have a packet capture running on your host (this can be done with Wireshark for example), and to look at the analysis within Wireshark relating to the actual TCP conversations that your applications are performing.

Murali Suriar
  • 10,166
  • 8
  • 40
  • 62
  • Very interesting reply thank you. Well currently there seems to be a problem on one of the networks I am and the packet loss jumped from 10% to 40% in a day. When it used to be normal the latency was around 10 to 30 ms but right now from the first step to 3rd step that is within the local provider network it vary from 100 to 900 ms. Which was why it raised me the curiosity of the impact of it on the network. so first step is router second step is the link 3rd step is the first IDC connection and 4th step is the external link where it goes to the internet. – Prix Jan 14 '11 at 20:33
  • @Prix: How are you measuring packet loss? – Murali Suriar Jan 14 '11 at 20:54
  • Sudden increase in packet loss usually indicates something bad happening. It may be simple saturation of the link, or developing problems in the router. I have used the `mtr` program a rates as low as I per minute to monitor such changes. – BillThor Jan 14 '11 at 21:10
  • @Murali using pingplotter. @BillThor im using pingplotter updating every 15 seconds. Left it running for an entire day. – Prix Jan 14 '11 at 23:09
  • @Prix please see my updated answer. Another question: what applications are you trying to use over this connection? Are you mainly browsing web pages? If so, does performance vary based on the type of page? (Static text vs. streaming video, for example?) – Murali Suriar Jan 15 '11 at 00:29
  • Loading any type of page takes long time. Pingplotter was using TPC packets http port. Mainly doing backup download of huges files 5gb + daily. – Prix Jan 15 '11 at 01:40
  • Sorry, meant to say TCP on the above comment and thank very much for all the information this is very good material :) – Prix Jan 15 '11 at 01:50
  • @Prix: I'd get in touch with your ISP and ask them if they're experiencing any congestion or other performance problems. How many devices are there between your client machine and your internet connection? This answer to a previous question gives you some information on how to troubleshoot connectivity issues: http://serverfault.com/questions/12341/how-to-tell-if-its-your-problem-or-your-isps-problem/12351#12351 – Murali Suriar Jan 15 '11 at 22:23
  • @Murali yes I already got in touch with the IDC that provide the link to us, they are having a problem with a node that connects me to their internal network before we hit the external network, and they are working to solve it ... wonder how long it can take after initial dectection of the problem, it's been 2 days now. – Prix Jan 15 '11 at 23:12
  • I've read that bandwidth is not the same as speed. That latency has to be factored in as well. Say I have a 100 gigabit file, and I want to transfer it from A to B. A 100 Gbs connection doesn't necessarily mean it will transfer the 100 gigabit file in 1 second from A to B, because we haven't factored in the latency. If A and B are far away from each other, doesn't this affect the transfer speed negatively and conversely if they are close to each other, then the real transfer speed should be higher? – CMCDragonkai Mar 20 '15 at 09:18
1

Yes, high latency on a network connection can certainly impact on download speed (there will be a lower impact if the TCP window is reasonably large, so that the source can send several packets without having to wait for each one to be ACKed). And any significant packet loss will have a catastrophic effect on performance, as every time a packet is lost the download will effectively stop for the duration of the TCP retransmission timeout.

Mike Scott
  • 7,903
  • 29
  • 26