The principle of the Xtreme-upload
As everybody knows, it's on principle recommended to set the uploadlimit up to about 80% of your upload-capacity. Some people even set it much lower, so that the download won't be disturbed. Some leechermods offer the possibility of 0 upload to enable a much better download.
Is it right that the upload disturbs download and why is it often recommended to set the uploadlimit only up to 80% of the upload-capacity?
The official eMule version only distinguishes between upload (dataupload: image item1) and overhead (image item2). As overhead the official version counts the net-size of a control-packet. With that it is not considered that the operating-system always adds a header to every packet (TCP-header, UDP-header). Concerning very small packets it is possible that the header is bigger than the actual packet itself. Especially if you have many connections at the same time, many control-packets are sent, which enlarges the TCP/UDP-header-overhead additionally. The third area, marked in the lower image, illustrates this overhead.
In addition to this overhead, an acknowledgement-packet (ACK-packet) has to be sent in return for every received packet. The official version doesn't count these packets, too. The fourth area in the image illustrates the additional amount of overhead, which is caused by those ACK-packets at a high download. If you have reached the limit of the upload-capacity, ACK-packets cannot be sent as fast as necessary and download as well as upload can break in.
To aviod these problems it is recommended to set the upload up to only 80% of the capacity.
The fifth area illustrates another additional overhead, namely the one of the network adaptor. Actually, a quite large number of bytes of upload are transferred , more than first expected. "Retransmissions" (failed transmissions, which have to be done one more time by Windows), ping-signals, which need to be answered, or the upload of other programs (e.g. browser) are added to the previous overhead.
The Xtreme mod works differently.
He tries to calculate the resulting overhead including TCP/UDP-header and ACK-packets as far as possible. Consequently, the uploadlimit, adjusted at the Xtreme, includes data, control-packets and their header, and the ACK-packets. Image item2 shows the total amount of overhead. The data-upload itself (image item1) is set lower, to keep the white line as stable as possible. By using this system, you are able to set the uploadlimit much higher and use the whole bandwidth more effectively. Download will never be disturbed by upload and the network-traffic (image item3) can be left out of consideration.
What is "NAFC"?
The "Network Adaptor Feedback Control" orientates the eMule upload to the total upload of all applications, taken from the network adaptor. So the upload limit, adjusted in eMule, considers not only the data of eMule, but also every upload-packet of any application (webbrowser, onlinegames, FTP-upload, and so on).
For instance: if you set your upload up to 15 kbs and your internet-telephony uses 5 kbs, eMule will send only 10kbs to data. Using this method, a much lower number of ping signals is guaranteed and your upload-capacity is used most effectively. If you use NAFC, you are able to adjust the upload-limit very close to the upload-capacity. The third image shows once again how the sum of upload data (1) + overhead + the rest of the networktraffic (3) result in the value adjusted at NAFC.
To avoid any abuse of this feature, eMule checks if the measured data are data of eMule or of other applications. Are the sent data of eMule (data + overhead) smaller than 11 kbs, a download-limit will be switched on dynamically.
NAFC doesn't work if you use a home network and go to the internet together with another computer per router.
Little comment in passing:
These images are no screenshots. They have been produced by Paint. They are only supposed to illustrate the principle in general, not to show the real values. Depending on windows-settings, latency periods and the network card, the graphs can look more or less jaggedly.
Normal screenshots can look like this:
This screenshot represents an optimum, because the white and the yellow line are situated very close together. (NAFC switched off)
But also the following screenshot illustrates normal values (NAFC switched off):
Explanation to the high values at circle 1 and 2:
Circle 1 could possibly be caused by the typical traffic of the browser ,e.g. loading a website.
Circle 2 shows a typical, brief complete occupation of eMule. This can be the result of a number of reasons:
- another process stole the necessary CPU-time
- the CD/DVD-burner blocked the IO-bus (happens often on writing the lead-in)
- another program (e.g. the explorer) carried out a write-/read-process at the harddisk, while eMule wanted to read or write data at the harddisk, too.
To mention first: the adjusted slotspeed doesn't represent an exact value, but eMule will try to open as many slots as needed to get the real slotspeed as similar as the desired one. The adjusted slotspeed has got a tolerance of about 25%. There are several reasons why the slotspeed hasn't been programmed exactly:
1. For example if you have an uploadlimit of 11 and a slotspeed of 4, it is mathematically not possible to give every slot 4 kbs.
2. The eMule overhead is not a constant value. It rises and falls and with that the dataupload you have at disposal rises and falls, too.
3. Caused by the network, the upload you have to a certain client can drop. This will be compensated by other slots.
The adjustable slotspeed depends on the uploadlimit. The higher it is, the higher you can adjust the slotspeed. The highest possible value is 15 kbs.
How does the slotspeed work and at what time will new slots be opened?
The fundamental principle says: there is a certain minimum and maximum of numbers of uploadslots. The minimum of numbers is: uploadlimit / slotspeed, rounded off. For instance: 17/4 -> 5. The maximum of numbers of uploadslots is calculated in a very complicated way.
Every uploadslot can have two different stages: Trickle or Full. A Trickle-slot gets 0.5 kbs uploadspeed and is illustrated grey. A Full-slot gets full speed and is illustrated black. The Xtreme tries to share out the whole uploadspeed among the Full-slots. If these aren't able to take the whole speed, the rest will be shared among the Trickle-slots. But there are always 0.5 kbs guaranteed for the Trickles.
After starting eMule, a minimum of numbers of slots will be opened. At first, all except one are Trickle-slots. The upload is now focused on this one Full-slot and so it will possibly be over the desired slotspeed. If a Full-slot is 25% higher than the slotspeed, the next Trickle becomes a Full-slot. This check happens every five seconds untill none of the Full-slots lies more than 25% over the wanted slotspeed.
The Xtreme mod always opens either the number of slots according to the minimum or he makes sure that at least one Trickle exists. Because in practice the following happens:
One or several clients aren't able to take the needed slotspeed. The upload is shared among all slots and so other slots get more speed. If the real slotspeed exceeds the desired one by more than 25%, the next Trickle becomes a Full-slot. If there aren't Trickles anymore a new slot will be opened. This procedure happens as long untill the upload is stable and either one Trickle exists or the maximum is reached.
If a new slot has to be opened because of missing Trickles, this slot has got six seconds time to set up a connection. If the slot is not able to do so, the next slot is opened. Normally it won't need six seconds time to set up a connection, but using this algorithm it is possible that more than one Trickle is opened. (For example: after seven seconds a new slot is opened, which answers immediately. But the other one, which hasn't answered untill then, suddenly sets up a connection after 15 seconds).
It is important to know that the highest principle of the Xtreme mod is to keep the upload stable, not to have as less slots as possible.
Especially bigger slotspeeds (> 4 or 5 kbs) can lead to a number of problems at some systems. Many clients cannot take a higher slotspeed. A bad connection to the internet, the own ISP, the ISP of a client, the drivers of your own network card or the ones of another client and many other factors are to blame for this. The Xtreme tries to open many slots to guarantee a stable upload. If he opens a large number of slots, so that the average slotspeed sinks to a certain value under the wanted one, it is a sign that a higher slotspeed is not possible. In this case it is advisable to set the wanted slotspeed down, because the algorithm of the Xtreme can work properly, if the wanted slotspeed is really reachable.
The automatic procedure to open new slots can be deactivated at the settings under "Xtreme -> Open more slots if needed". If it's deactivated, the number of opened slots will always be similar to the minimum of numbers of slots.
Blocking-ratio and upload-health
At the Xtreme options I you can activate the displaying of the blocking-ratio. If you do so, two values will be shown at the upload-toolbar of the transfer-window. The first value illustrates the upload-health and should always come to 100%. The second one shows the average blocking-ratio for the last 20 seconds of all upload slots. Furthermore you'll find the blocking-ratio of the last 20 seconds for each single upload slot, too. This value reflects how often an upload-socket blocked an attempt to send data. 95% for instance would mean that only 5% of all attempts have been successful.