[Anoxie]

Hello,

I may have missed some posts, but why isn't there a slot focus on the official client whereas it seems to work pretty well on few mods ? First result is a higher average ULed per session (it helps UL full chunk).

[GilesBathgate]

I quote from ZZ (inventor of slotfocus AFAIK)

zz, on Mar 13 2004, 07:49 PM, said:

I'm not really sure about SlotFocus and official eMule. I can't really talk for the devs, so I think you will just have to continue to try to get an answer from them.

[gigatoaster]

It's sad that after all these years, slotfocus has not been implemented yet...More and more people are getting faster UL capacities, we should take advantage of it! I wonder if the devs have changed their mind...(at least a option to enable/disable it).

This post has been edited by gigatoaster: 07 June 2008 - 10:26 PM

[Tuxman]

I think ppl who want eMule + SF use the ZZUL mod...

[Anoxie]

Tuxman, on Jun 7 2008, 11:28 PM, said:

I think ppl who want eMule + SF use the ZZUL mod...

Sure, but this is to improve the average ULed per session over the whole network. Next step after try to UL full chunk.

[Stulle]

there is no real advantage in SF. it only looks faster but still the same amount of data is uploaded. the problem is that there already are so extremly many blocking clients we need to take care of. i am not saying it is impossible but probably it wouldn't be really good, either.

[Some Support]

Sf works. But it has no significant advantage over the current system. You do not upload more nor faster. If you upload to a good client a part may spread a bit faster for rare files, if you upload to a bad (/slow) client a bad may spread a bit slower. Tickle slots which are used in SF (iirc) are not good however, esp. since they interfere with proper finishing files and small downloads.
Also most users prefer a constant download over fast spikes and 0-downloads (even through it would be the same amount of data in the end). Those rather rare users who really have an advantage of SF may use a mod which suits there needs.
So no we won't implement SF. However as transferespeeds got faster in the last years its possible that we raise the average upload per slot a bit (in the magnitude of + 25%-75%) at some point.

[niclights]

Quote

However as transferespeeds got faster in the last years its possible that we raise the average upload per slot a bit (in the magnitude of + 25%-75%) at some point

Makes sense. Perhaps change the formula to continue above 193kB/s also? I don't fully understand why it stops there at 7.5kB/s although clearly you need significantly more bandwidth at this speed per slot before number of slots is an issue.

[Famerlor]

@niclights: Sounds good.....!

@SoSo: Perhaps you could make SF an "expert option", which can only be enabled by manually editing the prefs.ini ?

[gigatoaster]

Famerlor, on Jun 8 2008, 08:14 PM, said:

@SoSo: Perhaps you could make SF an "expert option", which can only be enabled by manually editing the prefs.ini ?

I understand the point of not implementing SF, what about the choice of enabling/disabling it?

[netfinity]

niclights, on Jun 8 2008, 05:09 PM, said:

Quote

However as transferespeeds got faster in the last years its possible that we raise the average upload per slot a bit (in the magnitude of + 25%-75%) at some point

Makes sense. Perhaps change the formula to continue above 193kB/s also? I don't fully understand why it stops there at 7.5kB/s although clearly you need significantly more bandwidth at this speed per slot before number of slots is an issue.

From my own experience I found out that making the slotspeed as the square root of the bandwidth works very well, althought it may still be too many for some computers with old harddisks. Their transferrate tends to drop when the upload slots count increases.

gigatoaster, on Jun 8 2008, 09:09 PM, said:

Famerlor, on Jun 8 2008, 08:14 PM, said:

@SoSo: Perhaps you could make SF an "expert option", which can only be enabled by manually editing the prefs.ini ?

I understand the point of not implementing SF, what about the choice of enabling/disabling it?

Maybe, if they ensure the trickle slots keep a slotspeed of atleast 1kB/s but preferably higher. SF is evil as it help to hide bad clients that use low upload speeds as a way to sabotage or as a way to get an advantage in the upload queues (LowID clients).

[GilesBathgate]

netfinity, on Jun 8 2008, 10:22 PM, said:

SF is evil as it help to hide bad clients that use low upload speeds as a way to sabotage or as a way to get an advantage in the upload queues (LowID clients).

I have never looked at someone uploading to me at 1B/s and thought "oooh thats a bad client because they are uploading slow to me". On some files I am just thankful that I get even that.

I think SF is a somewhat misunderstood. As "some support" points out SF neither makes uploads Faster nor do you upload more. I think this can be clarified by a simple example.

Suppose you have a 3 chunk file to upload to 3 people with a maximum upload bandwidth of 30kb/s. (assuming that everyone can also download at least at 30kb/s), With the official client each person gets 10kb/s and the whole transfer takes ~ 45mins . Lets assume person A got chunk 1 person B got chunk 2 and person C got chunk 3, the amount of time it would take for each person to get their own respective "first chunk" would be ~ 15mins. With SF however each person gets the full 30kb/s in series. So person A gets chunk 1 in 5mins, Person B after waiting 5mins gets chunk 2 in 5mins, and person C after waiting 10mins gets chunk 3 in 5mins. So all the people get their own respective "first chunk" after a total time of 15mins. So as you can see it makes no difference, However the time it takes for a chunk to become available to others to download in the official version is 15mins, whereas in SF the time it takes before a chunk becomes available is 5mins. This contributes to the overall download time since after 5mins Person B and C can be downloading chunk 1 from person A (rather than downloading from you) instead of waiting 5 or 10mins respectively. Therefore network "on the whole" benefits from SF since the whole transfer could take < 45mins.

(admittedly the example is very theoretical, and make some assumptions)

So to summarize, With SF Uploads are not faster nor do you upload more, the only thing which is less is the time to which the full chunk becomes available to other people.

This post has been edited by GilesBathgate: 09 June 2008 - 11:18 AM

[netfinity]

GilesBathgate, on Jun 9 2008, 12:58 PM, said:

netfinity, on Jun 8 2008, 10:22 PM, said:

SF is evil as it help to hide bad clients that use low upload speeds as a way to sabotage or as a way to get an advantage in the upload queues (LowID clients).

Firstly I think trickle slots are a feature of the official client, so it doesn't hide anything. Secondly I have never looked at someone uploading to me at 1B/s and thought "oooh thats a bad client because they are uploading slow to me". On some files I am just thankful that I get even that.

It is quite common for attackers that upload junk (corrupt) data to upload at a slow speed so that it takes very long time for the part to complete and the corruption to be detected. That is why the official client sometimes can take upto an hour to download a small file as an mp3, while the same file with a mod that drop slow downloads complete the file in 5 minutes.

[GilesBathgate]

netfinity, on Jun 9 2008, 12:24 PM, said:

That is why the official client sometimes can take upto an hour to download a small file as an mp3, while the same file with a mod that drop slow downloads complete the file in 5 minutes.

That doesn't make sense to me. Why would dropping sources decrease file download time, has this something to do with max connections?

EDIT: Yes I meant decrease or prehaps I was thinking 'Increase speed'

This post has been edited by GilesBathgate: 09 June 2008 - 02:02 PM

[netfinity]

GilesBathgate, on Jun 9 2008, 03:29 PM, said:

netfinity, on Jun 9 2008, 12:24 PM, said:

That is why the official client sometimes can take upto an hour to download a small file as an mp3, while the same file with a mod that drop slow downloads complete the file in 5 minutes.

That doesn't make sense to me. Why would dropping sources increase file download time, has this something to do with max connections?

Not increase, decrease! The download time decreases when dropping slow and possibly corrupt sources as it will allow for other faster sources to complete the file. A slow source can block file completion for quite a long time as a block that has been requested from one source cant be assigned to another until that source has been dropped. Since blocks are normally requested in multiples of 180kB it means that a source uploading to you at 100b/s would be able to block the completion a a part or your entire file for atleast 30 minutes.

[GilesBathgate]

netfinity, on Jun 9 2008, 02:47 PM, said:

Not increase, decrease! The download time decreases when dropping slow and possibly corrupt sources as it will allow for other faster sources to complete the file. A slow source can block file completion for quite a long time as a block that has been requested from one source cant be assigned to another until that source has been dropped. Since blocks are normally requested in multiples of 180kB it means that a source uploading to you at 100b/s would be able to block the completion a a part or your entire file for atleast 30 minutes.

Ah, (and now I will show off my lack of knowledge) and why can't you request the same block from two sources and choose the faster one?


BTW: I think Crumbs is a much better idea than SF and achieves the same goal of faster time to availability.

[PacoBell]

GilesBathgate, on Jun 9 2008, 06:15 AM, said:

why can't you request the same block from two sources and choose the faster one?

Because "fast" is a temporal concept. What may be a slow source one second may increase dramatically the next. Case in point, are you aware that the first few seconds of every eMule transaction is placed in what is known as a "trickle slot" where the upload slot may only see maybe a few hundred bytes/second.

[Stulle]

more importantly, we might end up wasting network traffic which should never be done!

[fox88]

GilesBathgate, on Jun 9 2008, 02:58 PM, said:

SF neither makes uploads Faster nor do you upload more. I think this can be clarified by a simple example.

No example is needed as upload limit should not be broken in any case.
For downloader if a part is received quickly means 1) another source for that part appear faster and 2) faster return to waiting queue.
For uploader big slots can lead to a certain loss of traffic as it takes time to achieve maximum speed.

Stulle, on Jun 9 2008, 10:05 PM, said:

more importantly, we might end up wasting network traffic which should never be done!

Was it about this thread?

[leuk_he]

Some Support, on Jun 8 2008, 03:35 PM, said:

Tickle slots which are used in SF (iirc) are not good however, esp. since they interfere with proper finishing files and small downloads.

FYI,

To reduce tricle slots in morph there is the option "remove spare trickle slots". They are put back back in the same place in the waiting queue. If you disable that option Slot focus is disabled.

Since it is easy to set slotfocus up wrongly, causing a lot of small slots, for the average user maybe it is too hard.