Feature: Zz Slotfocus Faster completion of chunks during UL
#101
Posted 03 September 2006 - 02:26 PM
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
#102
Posted 03 September 2006 - 02:42 PM
EvolutionCrazy, on Sep 3 2006, 04:26 PM, said:
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
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)
#103
Posted 03 September 2006 - 03:12 PM
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
#104
Posted 03 September 2006 - 03:22 PM
Quote
True .
#105
Posted 03 September 2006 - 07:10 PM
white lightning, on Sep 3 2006, 05:22 PM, said:
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
#106
Posted 04 September 2006 - 06:41 PM
Quote
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 .
#107
Posted 04 September 2006 - 08:09 PM
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
#108
Posted 16 September 2006 - 10:33 AM
zz, on Aug 10 2006, 03:16 PM, said:
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
#109
Posted 30 December 2006 - 09:12 PM
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
#110
Posted 31 December 2006 - 02:55 AM
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
The extreme limit of wisdom, that is what the public calls madness.
#111
Posted 31 December 2006 - 10:42 AM
MadlyMad, on Dec 31 2006, 03:55 AM, said:
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
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).
#112
Posted 01 January 2007 - 06:37 PM
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.
Aide officielle eMule Tutoriels, Aides diverses et liens utiles >>TADELU<<
Les règles du forum
Ce serait sympa de lire "A lire avant de poster" AVANT de poster, il sert à ça ce post
LENTEUR DES TELECHARGEMENTS : LES RAISONS
#113
Posted 01 January 2007 - 06:47 PM
#114
Posted 01 January 2007 - 07:20 PM
Xman1, on Jan 1 2007, 07:47 PM, said:
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.
#115
Posted 01 January 2007 - 10:17 PM
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
Aide officielle eMule Tutoriels, Aides diverses et liens utiles >>TADELU<<
Les règles du forum
Ce serait sympa de lire "A lire avant de poster" AVANT de poster, il sert à ça ce post
LENTEUR DES TELECHARGEMENTS : LES RAISONS
#116
Posted 02 January 2007 - 12:28 AM
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
#117
Posted 02 January 2007 - 09:46 AM
@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.
#118
Posted 02 January 2007 - 09:56 AM
Anoxie, on Dec 31 2006, 11:42 AM, said:
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.
Trouble connecting to a server? Use kad and /or refresh your server list
Strange search results? Check for fake servers! Or download morph, enable obfuscated server required, and far less fake server seen.
Looking for morphXT translators. If you want to translate the morph strings please come here (you only need to be able to write, no coding required. ) Covered now: cn,pt(br),it,es_t,fr.,pl Update needed:de,nl
-Morph FAQ [English wiki]--Het grote emule topic deel 13 [Nederlands]
if you want to send a message i will tell you to open op a topic in the forum. Other forum lurkers might be helped as well.
#119
Posted 12 February 2007 - 01:23 PM
And the stats :
- Zzul 20061022-1609 :
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 :
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
#120
Posted 12 February 2007 - 06:47 PM
This means that you can't compare the uploaded per session numbers 1-to-1 with the standard eMule client.
/zz