mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mldonkey-users] Source management


From: Goswin Brederlow
Subject: Re: [Mldonkey-users] Source management
Date: 22 Jan 2003 02:48:47 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Military Intelligence)

Taros666 <address@hidden> writes:

> Hello,
> 
> I tried to read some of the source code and have some questions and
> suggentions...
> 
> 
> If I read the code right we see differences between sources that have
> chunks we don't have and sources with chunks we already have. I'd like
> an option to ignore and dump sources than have no needed chunks. This
> should only be done if enough sources are available to not loose
> sources for rare files. But files with lots of sources already have so
> many sources, that we can discard them without a problem. I don't want
> them marked as bad sources...really kick these sources. We would use
> less mem and have better chance to ask all remaining sources in a
> given time.

- You ask the server for sources (or you get source propagation).
- You find a new source.
- You connect to the source and find it has no new chunks.
- You kill the source.
- You ask the next server for more source.
- You get the same old not having any chunks source again.
- Hey look, a new source I haven't seen before.
...

No, dropping them creates all sorts of problems. Put them in a extra
list with minimal information. The clients id and timestamp of the last
connect should be enough. Then when you have nothing to do (e.g. if
you only download rare files this might happen) retry them after a few
hours.

> It was already discussed to remove sources with big queues. I think
> that would improve things, too. But can we already see the queues of
> emules? I couldn't find something in the source-code...
> 
> It would be fine to have a value for that (only queue sources that
> have a queue < SOMEVALUE).
> 
> 
> If this things would be implemented (drop sources with no needed
> chunks/drop sources with big queues) this could improve mem usage,CPU
> usage, max-sources, reask cycles and finaly DL...

Dropping a source is only helpfull if it frees a slot for a better
source. Generate a score for each source, in which the queue length
could and should be a factor, and sort by that. Then when its drop
sources time, drop the worst scored sources.

If its a rare file I don't care if I'm in queue position 900. Better
to get the file after 1 week waiting then never. But for rare files
there hardly will be enough sources to trigger source cleaning.

MfG
        Goswin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]