Feature: Zz Slotfocus
Faster completion of chunks during UL

ZZ SlotFocus: Focus the upload bandwidth to as few upload slots as possible!
(only one, if the top slot wants it all). Transfers files to fewer people at a time, but faster to each. Faster transfers makes chunks complete sooner, making it possible for other clients to share the chunks sooner. This gives more sources in shorter time, sharing the upload demands on several computers sooner. At 76 Kbytes/s ZZUL opens ca 6-10 slots, when official eMule opens 24 slots. ZZUL only opens new slots if necessary to use the configured bandwidth. Upload slot focusing version 2 is available in this patch. Version 1 is used in eMule Plus (and others?). You can see which upload that has the highest priority by checking the number in the "Slot #" column. Slot #1 get all bandwidth it can handle. Slot #2 gets any leftovers after slot #1 has taken what it wants, etc.

When you download a file, it is good for you to give all chunks you already have of that file to other clients as soon as possible. As soon as you have spread your chunks, the other clients will actually help you to download the chunks you are missing. Then you can get those chunks from them (and fast, since you now have good credits with them). It will also be easier for you to get the chunks from the original source, now that is no longer busy uploading chunks that you already have, to other clients. So set your upload speed as high as possible!

Hi zz,
Thanks for SlotFocus. It is a feature that can make the download speed of the whole emule network much faster. Its full advantage can be achieved only if it is operated in the whole network(in the official) and not in a mod.

Can you please answer what is the status of the SlotFocus feature in the official emule?
Is it being planned, or is somebody already working on it?
If developers don't want to include this feature, can you comment and say why?
Andu wrote in the above thread that it depends on the throttler, and that the throttler has to be stabilized before. Is this right?

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.

It is correct that SlotFocus is dependant on the Throttler. However the parts of the throttler that are the same in SlotFocus and official seems to work ok in official.

The throttler is made up of a few parts:
1. the integration in the rest of the main eMule code, where all sends are routed to the throttler for dispatching.
2. the part in the throttler which decides which packet should be sent first (packet scheduler)
3. the changes in the socket code to make them suitable for use with the throttler

1 and 3 is pretty much the same in official as in ZZUL. 2 (packet scheduler) is where the difference is. Official schedules packets to give equal bandwidth to all slots, but ZZUL tries to give all to first slot, any leftovers to second, anything still leftover to third slot, etc.

Also part of SlotFocus is changes in the logic that opens and closes upload slots. This is not in official at all yet.

Also part of SlotFocus is changes in the logic that opens and closes upload slots. This is not in official at all yet.

Is this necessary for the basic SlotFocus to operate, or just an improvement that can be added later to the official (and thus letting us test the basic SlotFocus in the meanwhile as an option in the official)?

Quote

2 (packet scheduler) is where the difference is. Official schedules packets to give equal bandwidth to all slots, but ZZUL tries to give all to first slot, any leftovers to second, anything still leftover to third slot, etc.

So, correct me if I am wrong:
This part is already in the official code, just not activated.
The situation is now that all the developers have to do is just add an option in the extended settings for example, to let people activate it and test it (In case the question above is answered that that the logic that opens and closes upload slots is not necessary for the basic SlotFocus to operate)?

To just focus on the oldest slots in official, check out UploadBandwidthThrottler.cpp in the main run method.

To get the logic to keep as few slots as possible you'd have to merge lots of stuff from UploadQueue.cpp. That's harder to do, since those changes are intertwined with powershare, friendslots and other stuff.

Something strange happened here after retesting the current version of the pure ZZUL client.

After starting and directly connecting to Kad and eD2K 4 upload slots were opened, but the trickling process didn't start at all, all 4 slots got the same amount of upload. And strangely the header of the upload part said: Uploads (5/4), which would mean that 5 of 4 upload slots are in "Transferring" mode.

I then waited until those first served 4 clients completed the upload process, but still no sign of trickling.

After a complete restart (and only connecting to Kad) everything working as expected so far.

5/4 just means that one part of ZZUL recommends that another slot is opened to fill bandwidth. The actual part that decides if a slot should be opened decides not to open it though, since it knows that that slot will just go immediately into trickle mode.

I think you just were unlucky and got 4 slow clients. As soon as one of those clients finishes its chunk, you might get a faster slot going.

hmm if it was sorted by upload speed in some way as well give full upload to each one at a time and work out witch ones cant take the upload and drop them to an 3k-5k slot (the ones who cant take the upload)

just so it keeps the slots ticking over

some sort of dynamic upload slot shaping (what whould be good if the clients posted there estmated download/upload speed (like BT)

thats what i want it to do but not make the slow downloaders get 0.1 more like 1k-2k
you could sort it by upload speed maybe

i currently do that (sort by speed, fastest gets slot 1) and have 1-2 k on my (not so-)trickle slots but i want to make that 0.2k - 0.5k

Quote

The current system is working logically. First come, first served. Why changing the order of the slots? What's the problem with slow clients staying "ahead" of faster downloading clients? Or do you want slow clients to be served first?

i want exactly the first two (or maybe only one if it hast the bandwidth) upload slots to be served first & as fast as possible.
the others shouldn't get more than necessary not to time out.

zz: lower slotnumbers (=higher entries in the list) get more speed - did i get this right?