Difference between revisions of "AMule is slow"

Revision as of 08:22, 13 January 2005

aMule is slow

So aMule is slow? This can be due to:

• Your fault
• The network's fault

Your fault

This is a list of issues which can be the reason for slow download speeds:

• A low value in "Preferences"->"Download limit".
• A low value in "Preferences"->"Upload limit". Upload limits under 4 kbps limit your download speed to 3 times your upload speed. Upload limits under 10 kbps limit your download speed to 4 times your upload speed. Upload limits above or equal to 10 kbps give you unlimited download speed, limited only by the "Download limit" preference value (read this link to know more about it).
• Having Low ID.
• Some ISPs block or limit connections to the standard eD2k ports. Try changing the port in "Preferences"->"Connections" to some other values.

The network's fault

We're sorry to tell you that sometimes, the low speeds aren't due to a bad aMule code or a bad configuration, but due to other facts. This is a list:

• The eD2k is a slow network. In some other P2P networks you can easily download faster. The eD2k network is one of the fastest P2P networks existing, but its main goal is availability. While on other popular networks you'll be able to download very fast, you'll quickly find out that in the eD2k network there are millions of files you'll be unable to find in any other network.
• Credits. If you are running aMule for the first time or if you deleted some files in the ~/.aMule directory, you'll have no credits. Credits grant fast downloads. If you don't know what they are, read this.
• The file's availability. Rare files, old files, extremly new files... this kind of files have very few sources, so it takes quite some time for aMule to connect to some other client sharing it.
• According to research done by HopeSeekr of xMule, the ED2K network *still* follows the 80-20 rule that hinders all other Peer-to-Peer networks, in a novel way. With virtually all other p2p nets, 80% of the users leech off 20% of the uploaders. With ED2K the main manifestation of the 80-20 rule (which shows up in *many* other natural processes) is that roughly 80% of the "high-bandwidth" (30kb/sec and above) and "small waits" (less than 5 minutes in a queue) are provided by roughly 20% of the clients on the entire network. These are, in order of precendence (determined by HopeSeekr's httpd log mod for xMule):

 * eMule release mods (like ZZUL)
 * mlDonkey + EDonkey clients
 * Files running xMule's modified upload code (xMule 1.6.0+ and aMule)
 * eMule 0.30 and below
 * eMule 0.42 and above with few popular files

The devil's bargain is that eMule's credit-system, huge queues, source exchange, and lack of initial credit accreditation for clients with zero initial parts (e.g. first downloaders) forces the initial downloader to wait any where from 2 hours to 8 hours in a eMule-centric upload-source cluster. Typical eMule queues are measured in the thousands, the average upload segment is 9.28MB, making the average wait in any one particular queue approximately 6 hours. Shorter queues, critics complain, would simply cause the 80-20 rule to shift from bandwidth to file availability (something *I* thought BitTorrent radically disproves, but o well).

Additionally, due to the abnormally large partfile size (BitTorrent's partfile sizes are dynamic and are generally no more than 150 KB) and eMule's lack of sophistication in selectively uploading them (it uses a pseudo-random process) causes the problem, unique to the ED2K network, of "missing parts"...a syndrome in which many thousands of people may have any particular large file, but one or more 9.28 MB parts are missing, due to the fact that the releaser did not effectively spread them to enough downloaders.

All these problems have been fixed by a host of eMule mods, xMule, mlDonkey, and others, however due to the lack of a protocol consortium such as the Gnutella Group, largely prevents these ideas from entering the mainstream ed2k network. A huge road block to this is that despite the existence of many independent ed2k clients, eMule maintains an extensive monopoly in the realm of clients (90 - 95% of all clients), which if nothing else causes the major ed2k server software (also a monopoly) to only consider contacting eMule (and its chosen allies) about critical server protocol changes.

Such an event happened in October 03, when lugdunum 0.44 introduced compulsive zlib support for all clients, after only informing eMule to its existence or how to implement it. In the aftermath of this decision, xMule stayed uncompliant for ~4 months, and the vast majority of its userbase moved to aMule, as HopeSeekr had been incapacitated for several weeks since and could not make the changes.