Official eMule-Board: Why So Many 'on Queue'? - Official eMule-Board

When I use eMule, I always find the status of a huge amount of peers are 'On Queue'. Most of the time, if I have 30~40 peers, there will be more than 20 'On Queue' while only 2 or 3 of the peers is transfering.

Why? Is this because a peer shares many files at the same time so a lot of requests go to it and finally full its queue? Generally speaking, how large is normal peers queue? Sometimes I just find my proority is QR:4651. Well. this is really a large number which means a long long time I should wait beore I could download from this peer.

Is this also the reason that why BitTorrent is much faster than eMule for some popular files?If it is so, why not the developers let eMule contain BT's fast download property while keep the its own advantages like large number of files? Then eMule will be perfect, right?

Wait for your ideas:)

In official Emule client queue size is definable in options (within a range).

Time spent in queue depends on that size, number actually on queue (dependant on number and popularity of users shares), the size of the files, their upload bandwidth and any credits you may have gained with that source.

However, the QR is not strictly a queue position, but a 'queue ranking' and it is not always correct to assume a long wait. See the manual for more information on how this is calculated and how credits work.

Ultimately torrents require high availability just as ed2k does for speed. Emule specialises in its field. It will never incorporate torrent (see Feature Request FAQ's) Each has their own advantage and disadvantage. For torrent advantage might be speed but disadvantage is file diversity. In contrast Emule might be generally slower but the file diversity is unrivaled. You could even consider the two points are not unrelated

Regardless, watching your mule too much is bad for you. Concentrating on download speed is a bad habit. Discussions about speed and torrents have been done to death - please seek these topics out. Let's not have yet another one!

Hey niclights, thank u for reply~~~~

Well actually I do not focus on the speed because right now, insteading of downloading, I am trying to know the design details about eMule, just for learning and I find this interesting.

What interested me a lot and also is the reason why I compare eMule with BT is, given a popular file, both eMule and BT could help the user find 30 up other peers/sources while the downloading speed is totally different~~~~!!

Well, I respect eMule's diversity of file and this is really adorable. But, in my opinion, the diversity of file can not be a reason or excuse for the low speed. For a P2P file sharing system, no matter BT, eMule and so many others, after the software introduces the peers in same session (downloading/holding the same file) to each other, the downloading speed is totally decided by how these peers exchange their complete/uncompelete files. The difference of downloading speed between eMule and BT just put me to the way to think that maybe eMule's source exchange mechanism has some 'disadvantages' (no offence here at all:) ).
One possible reason came into my mind is that, due to the diversity of file, a normal peer need to upload many files at the same time which makes many other request waiting in its queue, hence lower the downloading speed.
But I am not quite sure about this, therefore I set this thread to discuss and hope anyone could help to verify/judge/extend my idea

Adele0307, on May 21 2008, 02:46 PM, said:

You found the answer yourself:

Quote

That's the reason for a lower speed per file with emule. In BitTorrent many users just download and upload a fistful of files so a peer can concentrate the upload on users that only wants those few files.
With emule you usually have dozens or hundreds of files in your shared folders so if someone wants a file from you he/she has to wait among plenty of other peers wanting other files.
You can't combine Bittorrent's speed with emule's file diversity. This is no disadvantage (also it has nothing to do with source exchange), it's another concept.
Also note that it's the speed per file. The overall speed in emule is not different from Bittorrent, you usually download more files at once in emule.

Quote

Thank u for reply:)

Actually as a researcher/developer, we could be rational to not combine these two popular P2P file sharing system. But USERS always want them both, diversity of file and speed, right? Well , right now both eMule and BT have done a good job in their areas respectively. But I wonder if the eMule developers have already begun to think about improving the speed before BT starts to extend the dicersiy of their files.

I don't completely agree that eMule is that much "slower"..

If I queue up some popular brand new files, there are usually tons of people like me just starting those downloads.. This means there are a lot of people uploading and downloading those files which is the key. All these downloaders begin to push each others rank up which causes a "torrent" like situation.. I usually get about 50-100K/s (Basically, I usually max out my line.) download per file in those situations..

It's the rare files that you will see the major slow down.. In these cases, most of the sharers already have the full file, so it's impossible for you to push your rank up on those sources.. So you go through their queues a little slower.. These are the files you most likely will not even find in a torrent.


Of course, you then have them files that in the gray area between those two situations..

The major difference is that eMule is a network.. Everyone is connected allowing anyone to find content from anyone else.. This does cause a bit of extra overhead, but is the main reason why content can survive in the network for years on end.. Kad brings this concept to the extreme.

Quote

This suggestion comes up in almost every torrent/speed discussion. Yet both clients have co-existed for a long time now & the situation remains the same throughout.

Adele0307, on May 21 2008, 07:39 PM, said:

Yes, that would be a rational, albeit misguided, request. I don't suppose you happen to understand the undelying network mechanics behind each network that necessitates the trade-off between speed and diversity, do you? Yes, the developers have had years to ponder this dilemma and there really can't be a happy-medium in a completely distributed network like ours until someone invents a breakthrough in secure, efficient, and global reputation system (which just so happens to be the intense study of cutting-edge computer science research these days).

This post has been edited by PacoBell: 22 May 2008 - 11:42 AM

Adele0307, on May 22 2008, 05:39 AM, said:

Regardless what users want: The more files a user shares, the bigger will be his upload queue, the more he has to spread his upload speed among the requesters, thus the less the single requester will get from the uploader.
When everyone reduces their number of shared files this will increase the speed per file, basically that means the users need to download less files at the same time to achieve the same download speed.
But then the file diversity would be worse.
So what do you suggest then to improve the speed?
Vice versa, when Bittorrent starts to increase file diversity, it does only work when also the userbase increases. Otherwise, the speed per file would decrease here, too.
And as Unkown1 pointed out, emule is a whole network, whereas Bittorrent builds a small network for each file. Remember, you cannot search for files in BT itself, which is also against file diversity.

BTW: Nice to hear from the unknown one again

Hey thank u all for reply~~~~

Well maybe I should think more about this but anyway it is really interesting

BTW: I am not the 'unknown one'~~~~~You see my name 'Adele'

and I have a small question, are most of the people in this forum from eMule develop group?

No. Very few. And only one regularly posting in currently active official team. But you have been granted the presence of one of the devs from the past - the 'unknown1'