Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer
    
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 0:29

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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