Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[thomas001]

Hi,

first: my english is poor,but i try to do this in english to reach more people.

After some discussions on #amule there are some enhancements to the source dropping systems which would IMO improve amule. source dropping as it is now is useless, because dropped sources, because of high QR or Full Queue, will reappear as soon as they appear again,so it could happen that a client asks the same source 10 times and finds out 10 times that it should be dropped. This is not much more than waste of upstream bandwidth.

The idea is to maintain a hashtable of client IDs and timestamps. when a client is dropped its ID and the time, when it is dropped, will be inserted into the hashtable. When a client now reappears it's ID is looked up in the hashtable. If the ID is found and the current time minus the stored timestamp is smaller than some value (20 minutes?) it will not be asked again and will have no entry in a file's source list. If the time difference is greater than some value the client's ID is removed from the hashtable and the client is asked again. When you upload to some client the ID of the client is also removed from the hashtable, because your QR can decrease because of uploading. After some time the complete hashtable is greped for too old entries,which would be removed if the client would appear. This prevents the hashtable from growing too big, because of useless entries.

Perhaps this sounds slow, but i think it's quite fast. hash table lookups aren't much slower, than array accesses. You compute a hash of a client ID (perhaps by XORing it up to a 32bit value?) and lookup the hashtable at the computed hash. There's some small overhead if 2 IDs have the same hash. Many (every?) C++ compilers offers ready-for-use hash table classes. The hashtable would map a client ID to an integer value.  For every new source you whould to the following:

• Lookup the client's ID in the hashtable
• If it is found check the time difference
• drop the client (again) if time difference is small, remove from hashtable otherwise

IMO all 3 points don't consume much CPU power.

I hope all the others, who tought with me about this, will read this and add all the things i've forgotten. ;-)

[Xaignar]

Yes, something like this is definetly needed, however it has pretty low priority I'm afraid.
I need to fix the search dlg and the preferences first, then it's a possibility.
Would you mind adding a feature-request to the bug-tracker so I dont forget?

[Anne Onyme]

it has pretty low priority I'm afraid.

As my user point of view, this will be awsome !

If i have a correct understanding of the situation it will change the way i use amule.

Some explainations :

I run a pretty old computer, a Pentium II 266Mhz. Believe me : it's slow, but efficient.

Using amule with it is like pushing this software at it last capabilities. I noticed i've a limit of client in the queue. At 4000 clients (well, so so) in the queue (for upload), my CPU charge is 100%. So, if i have more than 4000 clients in the queue the upload slots becomes to vary : they're not stable anymore. The curve in the stat windows chows thats clearly.
See the attached image.


This situation (after 4000), can break the connection of new uploaders resulting of people unable to take datas from my client. And this problably affect my download too.

[Xaignar]

Well, you can do a simple test to see if you'd get any CPU % benefit from this. Just change the option "Sources with no needed file-parts." to "Keep sources" in the "Source Dropping" section of the preferences. This should use the least CPU.
But please note that it has nothing to do with the sources on your upload queue.