[EvolutionCrazy]

while you wait longer from the releaser you can ask for a FULL CHUNK from another client... so you are in queue of 2 clients... with vanilla emule instead you have to wait only on the releaser becouse nobody will be able to get a full chunk in less then 52minutes... (9.28mb / 3kb/s )

with slotfocus instead uploding @60kb/s to 1 client a can create another client capable to accept users in queue for that new files within few minutes

[netfinity]

EvolutionCrazy, on Sep 3 2006, 04:26 PM, said:

while you wait longer from the releaser you can ask for a FULL CHUNK from another client... so you are in queue of 2 clients... with vanilla emule instead you have to wait only on the releaser becouse nobody will be able to get a full chunk in less then 52minutes... (9.28mb / 3kb/s )

with slotfocus instead uploding @60kb/s to 1 client a can create another client capable to accept users in queue for that new files within few minutes

That is ofcourse if you only share that one file or giving it extremly high priority, which might be true for a releaser but not for the average eMule'r.

[EvolutionCrazy]

yeah sure, that's only usefull when releasing... and maybe using powershare + slotfocus = the top

for the average user maybe the ability to increase the speed per slots just over those 3kb/s would be enough

and the argomentation that is preferable to have constant upload (download on the other hand) from everybody would be nice instead of having big "spikes" and others timeframe with 0 downloads

[white lightning]

and maybe using powershare + slotfocus + Hide OS + Share only the need...etc. = the top

Quote

and the argomentation that is preferable to have constant upload (download on the other hand) from everybody would be nice instead of having big "spikes" and others timeframe with 0 downloads

True .

[CiccioBastardo]

white lightning, on Sep 3 2006, 05:22 PM, said:

and maybe using powershare + slotfocus + Hide OS + Share only the need...etc. = the top

Of course not. Hacking the network status information is not good. That's why features like anti-hide-os are born. What is needed is a clever way for the downloader to choose the best chunk. This is a global rule that would be valid for all clients. I see lately some improvements have been done in that field.

About the application of slot focus, if you are the releaser the fact that you upload other files is of not disturbance to the way the chunks are distributed. They are only delayed, depending on the relative priority of the uplaoded files. Nevertheless, a complete chunk is created earlier with slotfocus, and while you can upload another different chunk (of whatever file) the new just upped chunk is available to be spread by another client.
Of course the average number of spread chunks is the same with or without SF, but what is important here is to create complete chucks as fast as possible for the particular file in release. SF + PS is the fastest method, beside the friend slot.
You can simply see this by thinking of uploading two chunks in parallel or serialized. Time to complete both is the same, however spreading time over the network for the first chunk would be shorter in the serialized mode (counting on the help of the "leechers", of course). This equal to upload to the fastest of the "leecher" in order to allow it to spread the new chunk. If you were going to upload to slow clients, even in parallel, the chunk distribution would be delayed a lot, even though the time for you to upload the chunk(s) would be the same. What you are losing while uploading (slowly) in parallel is the bandwidth of the downloaders that are uploading different chunks from those of the file you would like to release.
In the nomal every day usage for spreading common chunks SF has no real advantage (as said, the average throughput is the same).

SF has not teorical disavantages over the capped upload slot. The tricle slot has (should have) no impact as well (despite bugs in the official), unless you are uploading the last blocks of a chunk. Maybe it would be better to not upload to that client till a full speed slot can be granted to it (which means the upload slot for the client could be delayed a bit in order for it to accept the download from another client). Clients that do not send their file chunk status could have the trickle slot denied (and left in waitng queue with their score untouched).

I would like to say... slotfocus for the masses, not for the classes

[white lightning]

Quote

Of course not. Hacking the network status information is not good.

Well , if you talk about feature fairness , i have to agree but that does not change the fact that they are good features for a releaser .

[zz]

The purpose of both ZZ:SlotFocus and ZZ:ChunkChooser is to have either a complete chunk, or nothing at all.

Having one complete chunk instead of several unfinished chunks makes the network more stable, since if one source for that chunk disappears, there's a better chance of someone else having that chunk complete. (imagine lots of the other sources instead having many unfinished chunks instead of one finished chunk each, then they don't help with sources for that file). Finished chunks are also visible to the other clients, so they can avoid downloading a chunk that someone else has. That's not possible with unfinished chunks, unless you have a mod extension.

Having more useful sources lessens the risk of files becoming incomplete, which hopefully lessens the risk of people transferring parts of files and then cancelling them because they can't complete the files. And that saves bandwidth for the network.

So the key is to keep the window where there's transferred, but still useless, data, as short as possible. We want to make it useful (i.e. complete the chunk) as soon as we can. I believe that SlotFocus helps with that.

/zz

This post has been edited by zz: 04 September 2006 - 08:11 PM

[mkol]

zz, on Aug 10 2006, 03:16 PM, said:

The devs don't want SlotFocus in the official eMule, so it will probably never be included.

0.47b can request one chunk from multiple sources, that's already a big improvement (but it's incompatible with Tarod/Xtreme full chunk upload).
I don't see any reason why slotfocus can't be included. The only major change with slotfocus is friend slot datarate, but friendslots in the official client are already a bad feature.

This post has been edited by mkol: 16 September 2006 - 10:35 AM

[Anoxie]

What are exactly trickle slots ? Do they exist in the official eMule ?

Actually I was looking at the UL of the morph, is it the UL of Zzul (if maxdatarate per client is set to 0 kB/s) ? If yes i understand why official devs don't want SlotfFocus.

This post has been edited by Anoxie: 30 December 2006 - 09:24 PM

[MadlyMad]

these are the slots to complete the total upload limit, not to lose bandwidth for the network
they are just waiting to have a better slot, to have more bandwidth available

and, you cannot set an upload rate limit per client in zzul (don't know for morph...) so this is not the reason why official devs don't want to implement
they just think it's more fair to upload approximately at the same speed to everybody, for standard users

This post has been edited by MadlyMad: 31 December 2006 - 02:58 AM

[Anoxie]

MadlyMad, on Dec 31 2006, 03:55 AM, said:

so this is not the reason why official devs don't want to implement they just think it's more fair to upload approximately at the same speed to everybody, for standard users

I was thinking of the quality and reliability of the UL (cf this uot;117905"]topic on the morph's UL) not of the upload rate limit.

Quote

At 76 Kbytes/s ZZUL opens ca 6-10 slots, when official eMule opens 24 slots.

Things may have changed, because at 80 kB/s official eMule opens 16 slots (sometimes more for a short time = 17 slots ponderated by time) :



I'll try Zzul's UL but I think leuk_he told me it was the same (if you set maxdatarate per client @ 0).

[gigatoaster]

Hi!

For ZZUL, try the former version because the very last one opened me 50 slots. Now back on vanillia, only 20 opened slots You can have a look to Neomule, it seems to better handle slot management (don't know if it uses zz code) however I had a huge amount of OH.

[Xman1]

the problem is: you can never do an objective comparsion which mod opens less slots.. but you to study the uploadbehaviour over a longer time. reason: if you are found by many slow clients after starting the mod, it must open more slots. Next time the situation can be different and you find only fast clients -> less open slots are needed.

[Anoxie]

Xman1, on Jan 1 2007, 07:47 PM, said:

the problem is: you can never do an objective comparsion which mod opens less slots..

As you said I think you can if you run long sessions. Share the same files, use the same settings, change the mod every 24 hours for two weeks. You'll have a pretty good idea how to compare both mods...

At first sight the morph's UL seems to be different from zzul's.

[gigatoaster]

@Xman1 : I am sorry but after long run session, I realized that I opened less slots with Neomule than in other mods. Morph is good but after 4 hours, the thing is messed-up (90 slots). With Xtreme, I had around 50 slots too, so far I stay on official clients because Neomule generates too much OH.

I pretty sure that mod comparison is efficient, but I know that this must be qualified. By the way, it would be great to have a stat about opened slots, such as the average opened slots.

This post has been edited by gigatoaster: 01 January 2007 - 10:18 PM

[zz]

I didn't check carefully, but it looked to me like Neo mod sorts the slots so the fastest downloaders end up in the slots with lower numbers (i.e. the most focused slots) on the expense of the slower downloaders. This is a behaviour I don't agree with, since it will starve slower clients and might prevent them from getting as much as the faster clients.

ZZUL uses a first-come-first-served strategy, which means that even if a downloader is slower than the others, it can still occupy the first slot. If you have many slow downloaders, you will get a lot of upload slots to use up all your bandwidth. If I read the code right, Neo would move up the fastest client (possibly giving it all the bandwidth, and then the other downloaders wouldn't get any).

As I said, I just glanced at the Neo code a while back, so I might have read the code wrong. I hope someone will correct me if that is the case.

/zz

[Xman1]

.. and xtreme focus to the slowest slot.. btw. sorts the list in an order, that the slots which didn´t get a packet for the longest time is the first one.

@gigatoaster
you can also set a very low number of slots with xtreme by increasing the slotspeed and disable "open more slots". But then you don´t have any guarantee that your bandwidth is fully used.

[leuk_he]

Anoxie, on Dec 31 2006, 11:42 AM, said:

I'll try Zzul's UL but I think leuk_he told me it was the same (if you set maxdatarate per client @ 0).

The idea/concept is the same and morph code is based on ZZ upload, but the code is different, has other optimizations, so things can be different.

[Anoxie]

I've found old screenshots :



And the stats :

• Zzul 20061022-1609 :

Runtime : 1d45min
UL sessions : 1456
Successfull UL sessions : 1219 (83,72%)
Failed UL sessions : 237 (16,28%)
Average Uploaded per session : 5,64 MB
Average UL time : 14'05"

• eMule v0.47c :

Runtime : 13h48min
UL sessions : 789
Successfull UL sessions : 697 (88,34%)
Failed UL sessions : 92 (11,66%)
Average Uploaded per session : 5,50 MB
Average UL time : 18'40"

Given that the Average Uploaded per session drops in the afternoon :

Average Uploaded per session over an hour:
7h-8h : 5.09
8h-9h : 7.10
9h-10h : 5.07
10h-11h : 5.07
11h-12h : 5.65
12h-13h : 4.36
13h-14h : 4.17
14h-15h : 3.16
15h-16h : 3.01
16h-17h : 3.02
17h-18h : 2.78
18h-19h : 2.50
[edit]Actually, I noted this evolution on the MoprhXT and StulleMule. Zzul and standard version seem to be less sensible to time of day.[/edit]

And that I launched the eMule v0.47c session at night, there might be a significant difference of the average uploaded per session. I'll run tests to explore this potential effect of Zzul.

BTW I can't save logs on disk with zzul despite the same settings :
I've got to run 24 h sessions or sessions at the same time every day... not very convenient :/

This post has been edited by Anoxie: 16 February 2007 - 11:44 AM

[zz]

Please note that when ZZUL closes a slot due to prio, too many slots, etc, the kicked out client keeps its session data (which includes its waiting time), and when it's allowed in again it's counted as the same session in the stats.

This means that you can't compare the uploaded per session numbers 1-to-1 with the standard eMule client.

/zz