Difference between revisions of "FAQ network"

From AMule Project FAQ
Jump to: navigation, search
(=Prefixes=)
(Reformatting, fixed some bad grammer and the expansion past the window-width.)
Line 1: Line 1:
=Network speed: what you should know before asking questions=
+
= Network speed: what you should know before asking questions =
 
  by Froenchenko Leonid, lfroen@gmail.com
 
  by Froenchenko Leonid, lfroen@gmail.com
  
 
   
 
   
==Preface==
+
== Preface ==
 
The purpose of this document is to clarify different issues regarding network  
 
The purpose of this document is to clarify different issues regarding network  
speed that pops up from time to time in amule forum. Generally speaking, there're several reasons for questions about "amule & network":
+
speed that pops up from time to time in amule forum. Generally speaking, there're several reasons for questions about "amule network":
<ul>
+
 
  <li>Speed reported by amule doesn't match provider given rate</li>
+
* Speed reported by amule doesn't match provider given rate
  <li>Poor performance of amule itself or another network application on the same computer</li>
+
* Poor performance of amule itself or another network application on the same computer
  <li>What are key factors influencing network performance while amule is running
+
* What are key factors influencing network performance while amule is running
  </li>
+
 
</ul>
+
Intended audience for this document are users who want to get better understanding of network functionality in general and in practical implication to amule functionality.
Intended audience for this document are users who want to get better understanding of network functionality in general and in practical implication to amule functionality.<br>
+
 
 
This page, however, is not to be seen as comprehensive general purpose "Network  
 
This page, however, is not to be seen as comprehensive general purpose "Network  
FAQ". <br>
+
FAQ".
 
   
 
   
==Network speed - how much is it ?==
+
== Network speed - how much is it? ==
 
While talking about network speed, people are using "bps" units, which mean  
 
While talking about network speed, people are using "bps" units, which mean  
"bit per second". The reason for <i>bit</i> rather that <i>byte</i> is pretty  
+
"bits per second". The reason for ''bit'' rather that ''byte'' is pretty  
match historical, but also have engineering motivation behind. This motivation  
+
much historical, but also have engineering motivation behind.  
comes from the fact, that not all networks in the world are transferring bytes.<br>
+
 
 +
This motivation comes from the fact, that not all networks in the world are transferring bytes.
 +
 
 
There's also convention to use capital "B" in "Bps" when speed is marked  
 
There's also convention to use capital "B" in "Bps" when speed is marked  
in "bytes per second". However, this convention is not widely accepted. Particularly, organizations like IETF and IEEE are stick to original "bps".<br>
+
in "bytes per second". However, this convention is not widely accepted. Particularly, organizations like IETF and IEEE are stick to original "bps".
 
   
 
   
==Prefixes==
+
== Prefixes ==
 
Since their invention, networks made quite a progress, and now we have networks  
 
Since their invention, networks made quite a progress, and now we have networks  
that transfers thousands and millions bits and more bits per second. For marking  
+
that transfers thousands and millions bits and more bits per second. For marking those speeds, prefixes ''"kilo"'', ''"mega"'', ''"giga"'', ''"tera"'' etc. are used.  
those speeds, prefixes <i>"kilo"</i>, <i>"mega"</i>, <i>"giga"</i>, <i>"tera"</i>
+
 
etc. are used. It is a <u>common mistake</u> to think that values with those prefixes are the same as in computer science, i.e. powers of 2. The truth is that, for historical reasons, prefixes in networking have a decimal base, and not a binary one.
+
It is a <u>common mistake</u> to think that values with those prefixes are the same as in computer science, i.e. powers of 2. The truth is that, for historical reasons, prefixes in networking have a decimal base, and not a binary one.
 
   
 
   
 
<table cellpadding="2" cellspacing="2" border="1" width="100%"
 
<table cellpadding="2" cellspacing="2" border="1" width="100%"
Line 34: Line 36:
 
     <tr>
 
     <tr>
 
       <th valign="middle" title="Table 1" align="center"
 
       <th valign="middle" title="Table 1" align="center"
  bgcolor="#33ff33">Prefix<br>
+
  bgcolor="#33ff33">Prefix</th>
      </th>
+
       <th valign="middle" align="center" bgcolor="#33ff33">meaning in computers</th>
       <th valign="middle" align="center" bgcolor="#33ff33">meaning in computers<br>
+
      </th>
+
 
       <th valign="middle" title="Table 1" align="center"
 
       <th valign="middle" title="Table 1" align="center"
  bgcolor="#33ff33">meaning in networks<br>
+
  bgcolor="#33ff33">meaning in networks</th>
      </th>
+
       <th valign="middle" align="center" bgcolor="#33ff33">difference, %%</th>
       <th valign="middle" align="center" bgcolor="#33ff33">difference, %%<br>
+
      </th>
+
 
     </tr>
 
     </tr>
 
     <tr>
 
     <tr>
       <td valign="top">K (kilo)<br>
+
       <td valign="top">K (kilo)</td>
      </td>
+
       <td valign="top">2^10 = 1024</td>
       <td valign="top">2^10 = 1024<br>
+
       <td valign="top">10^3 = 1000</td>
      </td>
+
       <td valign="top">2%</td>
       <td valign="top">10^3 = 1000<br>
+
      </td>
+
       <td valign="top">2%<br>
+
      </td>
+
 
     </tr>
 
     </tr>
 
     <tr>
 
     <tr>
       <td valign="top">M (mega)<br>
+
       <td valign="top">M (mega)</td>
      </td>
+
       <td valign="top">2^20 = 1,048,576</td>
       <td valign="top">2^20 = 1,048,576<br>
+
       <td valign="top">10^6 = 1,000,000</td>
      </td>
+
       <td valign="top">5%</td>
       <td valign="top">10^6 = 1,000,000<br>
+
      </td>
+
       <td valign="top">5%<br>
+
      </td>
+
 
     </tr>
 
     </tr>
 
     <tr>
 
     <tr>
       <td valign="top">G (giga)<br>
+
       <td valign="top">G (giga)</td>
      </td>
+
       <td valign="top">2^30 = 1,073,741,624</td>
       <td valign="top">2^30 = 1,073,741,624<br>
+
       <td valign="top">10^9 = 1,000,000,000</td>
      </td>
+
       <td valign="top">7%</td>
       <td valign="top">10^9 = 1,000,000,000<br>
+
      </td>
+
       <td valign="top">7%<br>
+
      </td>
+
 
     </tr>
 
     </tr>
 
     <tr>
 
     <tr>
       <td valign="top">T (tera)<br>
+
       <td valign="top">T (tera)</td>
      </td>
+
       <td valign="top">2^40 = 1,099,511,627,776</td>
       <td valign="top">2^40 = 1,099,511,627,776<br>
+
       <td valign="top">10^12 = 1,000,000,000,000</td>
      </td>
+
       <td valign="top">9%</td>
       <td valign="top">10^12 = 1,000,000,000,000<br>
+
     </tr>  
      </td>
+
       <td valign="top">9%<br>
+
      </td>
+
     </tr>
+
    <tr>
+
      <td valign="top"><br>
+
      </td>
+
      <td valign="top"><br>
+
      </td>
+
      <td valign="top"><br>
+
      </td>
+
      <td valign="top"><br>
+
      </td>
+
    </tr>
+
 
+
 
</table>
 
</table>
<br>
+
 
As you can see from the table above the error in calculation is about 5% when the prefix  
+
As you can see from the table above the error in calculation is about 5% when the prefix is incorrectly interpreted. Please note that the speed your provider tells you is "speed in network", i.e. calculated on decimal base.
is incorrectly interpreted. Please note that the speed your provider tells  
+
 
you is "speed in network", i.e. calculated on decimal base. <br>
+
 
For example when your provider tells you that your link is "ADSL 256/128" you  
 
For example when your provider tells you that your link is "ADSL 256/128" you  
should understand that he means 256000/128000 bps. Which means, that you have
+
should understand that he means 256000/128000 bps. Which means, that the speed of your connection is 32000/16000 bps.
32000/16000 bytes per second speed in your link.<br>
+
  
==Protocol overhead - what is it about==
+
== Protocol overhead - what is it about ==
When amule is running, it constantly "talks" with other "mules" and servers.  
+
When amule is running, it constantly "talks" with other clients and servers.  
 
This data exchange is needed to identify itself, request information about  
 
This data exchange is needed to identify itself, request information about  
available sources and files, perform searches and so on. Since this information  
+
available sources and files, perform searches and so on.  
has no use for the user itself, it's called "overhead" i.e. inevitable addition  
+
 
to the data you actually want to upload or download. Amule calls this "<i>connection  
+
Since this information has no use for the user itself, it's called "overhead" i.e. inevitable addition to the data you actually want to upload or download.  
overhead</i>". However, the number amule presents, includes only the size of the actual
+
 
data that amule itself is sending to the network stack. Later, this data is
+
aMule calls this "''connection overhead''". However, the number amule presents, includes only the size of the actual data that amule itself is sending to the network stack. Later, this data is sent down to the net with more overhead - now of network protocols. How much is it - lets see that in the next section.
sent down to the net with more overhead - now of network protocols. How much
+
is it - lets see that in the next section.<br>
+
 
   
 
   
==Network overhead==
+
== Network overhead ==
 
First of all - we're talking about IPv4 network. Once upon a time, there  
 
First of all - we're talking about IPv4 network. Once upon a time, there  
was only one type of IP network. Now there's 2 - IP version &nbsp;4, the old
+
was only one type of IP network. Now there are two - IP version 4, the old
we all know; and IP version 6 - the new one. ED2K protocol by design, is
+
we all know; and IP version 6 - the new protocol made to fix the limitations of IPv4.  
unable to talk over IPv6 network, so users who have it (in Japan and China  
+
 
for example) will not be able to connect "as is". Using IPv4 means, that each
+
ED2K protocol by design, is unable to talk over IPv6 network, so users who have it (in Japan and China for example) will not be able to connect "as is". Using IPv4 means, that each packet (TCP, UDP, ICMP) will have IPv4 header.
packet (TCP, UDP, ICMP) will have IPv4 header. The minimum size of this header
+
 
is 20 bytes. Header can have optional parts (each 4 bytes) and it's up to
+
The minimum size of this header is 20 bytes. Header can have optional parts (each 4 bytes) and it's up to your provider - for example my adds 1 option dword. <-- WTF?
your provider &nbsp;- for example my add 1 option dword.<br>
+
 
When talking to other thing on ed2k network, amule uses the widely known TCP protocol.
+
When talking to other thing on ed2k network, amule uses the widely known TCP protocol. UDP is also used, but on a much smaller scale. As the reader might know, TCP is a reliable protocol, i.e. it's guaranteed that data which sent from one side will arrive on the other or an error will be reported.
UDP is also used, but in much smaller scale. As the reader might know, TCP is a reliable protocol, i.e. it's guaranteed that data which sent from one side will arrive on the other or an error will be reported. In order to achieve this, TCP send its own data in addition to the actual transfer. This data includes TCP client initial negotiation, checksums, sequence numbers and acknowledgments. All this is in the <i>TCP header</i> which is added to each packet sent. The size of this header  
+
 
is 20 bytes minimum. While being small overhead for large bulk transfer, it
+
In order to achieve this, TCP send its own data in addition to the actual transfer. This data includes TCP client initial negotiation, checksums, sequence numbers and acknowledgments. All this is in the ''TCP header'' which is added to each packet sent. The size of this header is 20 bytes minimum.
can take significant part of bandwidth when small amounts of data are being
+
 
exchanged. <u>This is exactly what happens on source discovery part of amule</u>.
+
While being small overhead for large bulk transfer, it can take significant part of bandwidth when small amounts of data are being exchanged. <u>This is exactly what happens on source discovery part of amule</u>.
Our client is trying to establish a connection and negotiate with a large number
+
 
of other clients. Doing this, amule opens new TCP connections <u><i>all the
+
Our client is trying to establish a connection and negotiate with a large number of other clients. Doing this, amule opens new TCP connections <u>''all the time''</u>. The amount of those connections is controlled by the ''"Maximum number of connections in 5 seconds"'' setting in the preferences.  
time</i></u>. The amount of those connections is controlled by the <i>"Maximum
+
 
number of connections in 5 seconds"</i> setting in the preferences. A typical number
+
A typical number is about 100. Each TCP connection results in at least 3 packets traveling the net - one is a SYN packet, i.e. connection request, and one an ACK or a RST when the connection is accepted or refused, and SYN+ACK to establish the session.  
is about 100. Each TCP connection results in at least 3 packets traveling
+
 
the net - one is a SYN packet, i.e. connection request, and one an ACK or a RST
+
There's more overhead of DNS queries when an address is resolved, retries when a host doesn't reply and so on.
when the connection is accepted or refused, and SYN+ACK to establish the session.  
+
There's more overhead of DNS queries when an address is resolved, retries when a  
+
host doesn't reply and so on.<br>
+
 
   
 
   
===On low level:===
+
=== On low level ===
 
After passing TCP and IP layers packets go down to the network interface  
 
After passing TCP and IP layers packets go down to the network interface  
 
driver. The kind of this driver depends on the way your computer is connected to the internet. For simplicity sake we will assume that this computer is connected to the ISP directly, i.e. you have no LAN (or switch or router) between.  
 
driver. The kind of this driver depends on the way your computer is connected to the internet. For simplicity sake we will assume that this computer is connected to the ISP directly, i.e. you have no LAN (or switch or router) between.  
Common setups that I'm aware of:<br>
+
 
 +
Common setups that I'm aware of:
 
   
 
   
<ol>
+
* Analog modem, connected to telephone line (ISDN modem falls in this category too)
  <li>Analog modem, connected to telephone line (ISDN modem falls in this category too)</li>
+
* Cable modem, connected through ethernet, ISP gives you an IP address through DHCP
  <li>Cable modem, connected through ethernet, ISP gives you an IP address through DHCP</li>
+
* Cable modem, connected through ethernet, ISP requires you to configure PPPoE or PPTP tunnel
  <li>Cable modem, connected through ethernet, ISP requires you to configure PPPoE or PPTP tunnel</li>
+
* ADSL modem, connected through ethernet. You must have a PPPoE or PPTP tunnel
  <li>ADSL modem, connected through ethernet. You must have a PPPoE or PPTP tunnel</li>
+
* Variation of above - modem connected to PC by USB.
  <li>Variation of above - modem connected to PC by USB.&nbsp;</li>
+
 
   
 
   
</ol>
+
In each of above setups there are different protocols in use, and different headers added to transmitted packets. But there's one important thing to note: <u>''ethernet frames traveling between cable/ADSL modem and PC, and don't reach the ISP''</u>.  
In each of above setups there are different protocols in use, and different headers added to transmitted packets. But there's one important thing to note: <u><i>ethernet frames traveling between cable/ADSL modem and PC don't reach the ISP</i></u>. And consequently they are not counted in rate calculations. PPPoE and  
+
 
PPTP headers, on the contrary <u><i>do reach the ISP</i></u>. Whether or not  
+
And consequently they are not counted in rate calculations. PPPoE and  
 +
PPTP headers, on the contrary <u>''do reach the ISP''</u>. Whether or not  
 
your particular provider includes them in rate calculations I obviously have  
 
your particular provider includes them in rate calculations I obviously have  
 
no idea about. For this reason I will exclude those headers from my calculations.  
 
no idea about. For this reason I will exclude those headers from my calculations.  
If you think that your ISP includes it, add 4 bytes to the size of each packet.<br>
+
 
 +
If you think that your ISP includes it, add 4 bytes to the size of each packet.
 
   
 
   
===Example:===
+
=== Example ===
Let's see how much network overhead we have on a typical network. Our connection  
+
Let's see how much network overhead we have on a typical network. Our connection is a cable modem connected via an ethernet link to a PC directly (no router between them).  
is a cable modem connected via an ethernet link to a PC directly (no router between them).  
+
 
In this setup we have IPv4 packets sent over ethernet. <br>
+
In this setup we have IPv4 packets sent over ethernet.  
Lets say we have 10 new connections opened each second, and all are being accepted
+
 
(successfully established TCP session). This alone sums up to (I'm counting data
+
Lets say we have 10 new connections opened each second, and all are being accepted (successfully established TCP session). This alone sums up to (I'm counting data going up - from my computer to the net):
going up - from my computer to the net):<br>
+
 
<br>
+
''10 connection * 2 packets * (20 bytes of TCP + 20 bytes of IPv4) = 800 bytes of overhead.''
<i>10 connection * 2 packets * (20 bytes of TCP + 20 bytes of IPv4) = 800 bytes of overhead. </i><br>
+
 
<br>
+
This means that we are starting with 1.16*8 Kbps of "''invisible"''
This means that we are starting with&nbsp; 1.16*8 Kbps of "<i>invisible"</i>
+
 
overhead caused by the very way the network works. Now, let's assume that
 
overhead caused by the very way the network works. Now, let's assume that
after each connection is established our amule sends something to the other side
+
after each connection is established our amule sends something to the other side and waits to receive an answer.
and waits to receive an answer.<br>
+
 
<br>
+
''Total of 800 bytes + 800 bytes = 1600 bytes per second = 6400 bps = 6.4 Kbps''
<i>10 connections * (1 packet of data + 1 ACK)*(20 bytes of TCP + 20 bytes of IPv4) = 800</i><i> bytes of overhead. <br>
+
 
<br>
+
Total of 800 bytes + 800 bytes = 1600 bytes per second = 6400 bps = 6.4 Kbps<br>
+
</i><br>
+
 
What we have here is 6.4 Kbps of network overhead alone. Taking into account  
 
What we have here is 6.4 Kbps of network overhead alone. Taking into account  
 
that amule has other data to send (uploads) and it is not the only network  
 
that amule has other data to send (uploads) and it is not the only network  
application running we will have the following picture: Most chances that your
+
application running we will have the following picture:  
link to provider is not that fast. &nbsp;Amule will <u><i>try</i></u> to open
+
 
10 connections per second and will <u><i>try</i></u> to upload on the specified  
+
Most likely the link to your provider is not that fast. aMule will <u>''try''</u> to open 10 connections per second and will <u>''try''</u> to upload on the specified speed.  
speed. Your operating system will share all available bandwidth between those and between amule and other network applications (browser for example). Actual results will vary depending on specific OS settings.<br>
+
 
+
Your operating system will share all available bandwidth between those and between amule and other network applications (browser for example). Actual results will vary depending on specific OS settings.
==ACK bottleneck==
+
 
 +
== ACK bottleneck ==
 
In all calculations above there was one assumption - zero download. But downloading is what amule was built for. So let's examine how the overhead  
 
In all calculations above there was one assumption - zero download. But downloading is what amule was built for. So let's examine how the overhead  
above affects your downloading speed. The answer is in TCP protocol. When TCP is sending  
+
above affects your downloading speed. The answer is in TCP protocol.  
data, it requires from the other side to acknowledge the reception. So if client  
+
 
A is sending data to client B by TCP, B has to send a special ACK packets to A which tells B "ok, I got it". If, however, A doesn't receive the ACK packets  
+
When TCP is sending data, it requires that the other side acknowledge the reception. So if client A is sending data to client B by TCP, B has to send a special ACK packets to A which tells B "ok, I got it". If, however, A doesn't receive the ACK packets in time, he will assume that either packet is lost.  
in time, he will assume that either packet is lost. So, without going deeply  
+
 
into TCP specification: <u><i>if B fails to send ACK to A, as a result A will
+
So, without going deeply into TCP specification: <u>''if B fails to send ACK to A, as a result A will transmit slower''</u>.
transmit slower</i></u>. <br>
+
 
Now let's see the situation in amule. We saw in the previous chapter, that the uplink  
+
Now let's see the situation in aMule. We saw in the previous chapter, that the uplink stream is congested by connection requests and uploads. As a result, there's a good chance that ACK packets for a file we are downloading <u>''will not be sent on time''</u>.
stream is congested by connection requests and uploads. As a result, there's a
+
 
good chance that ACK packets for a file we are downloading <u><i>will not be sent  
+
The remote party will notice this and slow down. This is one more reason why the upstream should better not be too congested.
on time</i></u>. The remote party will notice this and slow down. This is one  
+
more reason why the upstream should better not be too congested.<br>
+
 
   
 
   
==Is there something I can do ?==
+
== Is there anything I can do? ==
 
OK, now that you understood why your network is so slow while amule is  
 
OK, now that you understood why your network is so slow while amule is  
running you will maybe look for a way to fix this. The answer in 2 words: "rate limit".  
+
running you will maybe look for a way to fix this. The answer in 2 words: "rate limit".
 +
 
 
The first thing you should do is to assign realistic rate limits in amule  
 
The first thing you should do is to assign realistic rate limits in amule  
 
itself. If you have a uplink rate of 128 Kbps don't set amules upload limit to  
 
itself. If you have a uplink rate of 128 Kbps don't set amules upload limit to  
16 (kilobytes per second) just because 128/8=16.<br>
+
16 (kilobytes per second) just because 128/8 = 16.
A better, but far more complicated solution is to use the QoS and packet scheduling  
+
 
services of your OS. For example, you can give a higher priority to ACK packets  
+
A better, but far more complicated solution is to use the QoS and packet scheduling services of your OS. For example, you can give a higher priority to ACK packets to solve the above mentioned "ACK bottleneck" problem.  
to solve the above mentioned "ACK bottleneck" problem. The QoS topic, however, is beyond  
+
 
scope of this article.<br>
+
The QoS topic, however, is beyond scope of this article.
<br>
+
 
   
 
   
==Router (switch, home network):&nbsp; is there any difference ?==
+
 
 +
== Router (switch, home network): is there any difference? ==
 
When the cable coming from your ISP is connected to some switching or routing  
 
When the cable coming from your ISP is connected to some switching or routing  
 
device, which in turn is connected to several PC's, bandwidth is shared between  
 
device, which in turn is connected to several PC's, bandwidth is shared between  
them. So, having N computers connected, an ideal device would simply provide  
+
them.  
each one of them with 1/N of the total bandwidth. The situation may vary in real  
+
 
life, and your particular device may have different idea about fairness. Since
+
So, having N computers connected, an ideal device would simply provide  
you're not going to have the hardware specs of your router chipset the only
+
each one of them with 1/N of the total bandwidth. The situation may vary in real life, and your particular device may have different idea about fairness.  
advice here is "try and see yourself". <br>
+
 
 +
Since you're not going to have the hardware specs of your router chipset the only advice here is "try and see yourself".

Revision as of 17:36, 28 February 2005

Network speed: what you should know before asking questions

by Froenchenko Leonid, lfroen@gmail.com


Preface

The purpose of this document is to clarify different issues regarding network speed that pops up from time to time in amule forum. Generally speaking, there're several reasons for questions about "amule network":

  • Speed reported by amule doesn't match provider given rate
  • Poor performance of amule itself or another network application on the same computer
  • What are key factors influencing network performance while amule is running

Intended audience for this document are users who want to get better understanding of network functionality in general and in practical implication to amule functionality.

This page, however, is not to be seen as comprehensive general purpose "Network FAQ".

Network speed - how much is it?

While talking about network speed, people are using "bps" units, which mean "bits per second". The reason for bit rather that byte is pretty much historical, but also have engineering motivation behind.

This motivation comes from the fact, that not all networks in the world are transferring bytes.

There's also convention to use capital "B" in "Bps" when speed is marked in "bytes per second". However, this convention is not widely accepted. Particularly, organizations like IETF and IEEE are stick to original "bps".

Prefixes

Since their invention, networks made quite a progress, and now we have networks that transfers thousands and millions bits and more bits per second. For marking those speeds, prefixes "kilo", "mega", "giga", "tera" etc. are used.

It is a common mistake to think that values with those prefixes are the same as in computer science, i.e. powers of 2. The truth is that, for historical reasons, prefixes in networking have a decimal base, and not a binary one.

Prefix meaning in computers meaning in networks difference, %%
K (kilo) 2^10 = 1024 10^3 = 1000 2%
M (mega) 2^20 = 1,048,576 10^6 = 1,000,000 5%
G (giga) 2^30 = 1,073,741,624 10^9 = 1,000,000,000 7%
T (tera) 2^40 = 1,099,511,627,776 10^12 = 1,000,000,000,000 9%

As you can see from the table above the error in calculation is about 5% when the prefix is incorrectly interpreted. Please note that the speed your provider tells you is "speed in network", i.e. calculated on decimal base.

For example when your provider tells you that your link is "ADSL 256/128" you should understand that he means 256000/128000 bps. Which means, that the speed of your connection is 32000/16000 bps.

Protocol overhead - what is it about

When amule is running, it constantly "talks" with other clients and servers. This data exchange is needed to identify itself, request information about available sources and files, perform searches and so on.

Since this information has no use for the user itself, it's called "overhead" i.e. inevitable addition to the data you actually want to upload or download.

aMule calls this "connection overhead". However, the number amule presents, includes only the size of the actual data that amule itself is sending to the network stack. Later, this data is sent down to the net with more overhead - now of network protocols. How much is it - lets see that in the next section.

Network overhead

First of all - we're talking about IPv4 network. Once upon a time, there was only one type of IP network. Now there are two - IP version 4, the old we all know; and IP version 6 - the new protocol made to fix the limitations of IPv4.

ED2K protocol by design, is unable to talk over IPv6 network, so users who have it (in Japan and China for example) will not be able to connect "as is". Using IPv4 means, that each packet (TCP, UDP, ICMP) will have IPv4 header.

The minimum size of this header is 20 bytes. Header can have optional parts (each 4 bytes) and it's up to your provider - for example my adds 1 option dword. <-- WTF?

When talking to other thing on ed2k network, amule uses the widely known TCP protocol. UDP is also used, but on a much smaller scale. As the reader might know, TCP is a reliable protocol, i.e. it's guaranteed that data which sent from one side will arrive on the other or an error will be reported.

In order to achieve this, TCP send its own data in addition to the actual transfer. This data includes TCP client initial negotiation, checksums, sequence numbers and acknowledgments. All this is in the TCP header which is added to each packet sent. The size of this header is 20 bytes minimum.

While being small overhead for large bulk transfer, it can take significant part of bandwidth when small amounts of data are being exchanged. This is exactly what happens on source discovery part of amule.

Our client is trying to establish a connection and negotiate with a large number of other clients. Doing this, amule opens new TCP connections all the time. The amount of those connections is controlled by the "Maximum number of connections in 5 seconds" setting in the preferences.

A typical number is about 100. Each TCP connection results in at least 3 packets traveling the net - one is a SYN packet, i.e. connection request, and one an ACK or a RST when the connection is accepted or refused, and SYN+ACK to establish the session.

There's more overhead of DNS queries when an address is resolved, retries when a host doesn't reply and so on.

On low level

After passing TCP and IP layers packets go down to the network interface driver. The kind of this driver depends on the way your computer is connected to the internet. For simplicity sake we will assume that this computer is connected to the ISP directly, i.e. you have no LAN (or switch or router) between.

Common setups that I'm aware of:

  • Analog modem, connected to telephone line (ISDN modem falls in this category too)
  • Cable modem, connected through ethernet, ISP gives you an IP address through DHCP
  • Cable modem, connected through ethernet, ISP requires you to configure PPPoE or PPTP tunnel
  • ADSL modem, connected through ethernet. You must have a PPPoE or PPTP tunnel
  • Variation of above - modem connected to PC by USB.

In each of above setups there are different protocols in use, and different headers added to transmitted packets. But there's one important thing to note: ethernet frames traveling between cable/ADSL modem and PC, and don't reach the ISP.

And consequently they are not counted in rate calculations. PPPoE and PPTP headers, on the contrary do reach the ISP. Whether or not your particular provider includes them in rate calculations I obviously have no idea about. For this reason I will exclude those headers from my calculations.

If you think that your ISP includes it, add 4 bytes to the size of each packet.

Example

Let's see how much network overhead we have on a typical network. Our connection is a cable modem connected via an ethernet link to a PC directly (no router between them).

In this setup we have IPv4 packets sent over ethernet.

Lets say we have 10 new connections opened each second, and all are being accepted (successfully established TCP session). This alone sums up to (I'm counting data going up - from my computer to the net):

10 connection * 2 packets * (20 bytes of TCP + 20 bytes of IPv4) = 800 bytes of overhead.

This means that we are starting with 1.16*8 Kbps of "invisible" overhead caused by the very way the network works. Now, let's assume that after each connection is established our amule sends something to the other side and waits to receive an answer.

Total of 800 bytes + 800 bytes = 1600 bytes per second = 6400 bps = 6.4 Kbps

What we have here is 6.4 Kbps of network overhead alone. Taking into account that amule has other data to send (uploads) and it is not the only network application running we will have the following picture:

Most likely the link to your provider is not that fast. aMule will try to open 10 connections per second and will try to upload on the specified speed.

Your operating system will share all available bandwidth between those and between amule and other network applications (browser for example). Actual results will vary depending on specific OS settings.

ACK bottleneck

In all calculations above there was one assumption - zero download. But downloading is what amule was built for. So let's examine how the overhead above affects your downloading speed. The answer is in TCP protocol.

When TCP is sending data, it requires that the other side acknowledge the reception. So if client A is sending data to client B by TCP, B has to send a special ACK packets to A which tells B "ok, I got it". If, however, A doesn't receive the ACK packets in time, he will assume that either packet is lost.

So, without going deeply into TCP specification: if B fails to send ACK to A, as a result A will transmit slower.

Now let's see the situation in aMule. We saw in the previous chapter, that the uplink stream is congested by connection requests and uploads. As a result, there's a good chance that ACK packets for a file we are downloading will not be sent on time.

The remote party will notice this and slow down. This is one more reason why the upstream should better not be too congested.

Is there anything I can do?

OK, now that you understood why your network is so slow while amule is running you will maybe look for a way to fix this. The answer in 2 words: "rate limit".

The first thing you should do is to assign realistic rate limits in amule itself. If you have a uplink rate of 128 Kbps don't set amules upload limit to 16 (kilobytes per second) just because 128/8 = 16.

A better, but far more complicated solution is to use the QoS and packet scheduling services of your OS. For example, you can give a higher priority to ACK packets to solve the above mentioned "ACK bottleneck" problem.

The QoS topic, however, is beyond scope of this article.


Router (switch, home network): is there any difference?

When the cable coming from your ISP is connected to some switching or routing device, which in turn is connected to several PC's, bandwidth is shared between them.

So, having N computers connected, an ideal device would simply provide each one of them with 1/N of the total bandwidth. The situation may vary in real life, and your particular device may have different idea about fairness.

Since you're not going to have the hardware specs of your router chipset the only advice here is "try and see yourself".