[Ejack79]

Mountainer, on 29 February 2012 - 04:51 AM, said:

fox88, on 28 February 2012 - 06:24 PM, said:

Mountainer, on 28 February 2012 - 05:27 PM, said:

No you cannot. I have to reduce upload to 20 KB/s, or else it would open dozens on dozens worth of slots. At first, it may have slots larger then 3KB/s, few hour later, there are countless tiny 3KB slots, that slowly kills hard discs.

Let's make it clear: you have little idea how eMule works and how to set it up; 'killing hard disks' part makes me cry.
You should make a support request in proper subforum.

You are not being truthfull. I do know how to set it up, I can see how it works.
I set 20KB/s means 6 x 3KB/s slots
I set 40KB/s means 12 x 3BK/s slots
and so on
When some slots are slower then 3KB/s, emul will pick up the slack, yes it does. But even if the downloaders are calpable to download faster then 3KB/s, the amount of slots is not being reduced. Once emul open x amount of slots, it will not go down. Amount is there to stay, it does.
Too many slots = too many simultaneous reading from different sectors of the hard disc = unnecessary strain on the hard disc = reduced life span of the hard disc.
Six slots is about right. more then that is too much. Thats why I have to reduce upload, even if my connection can endure much more.

I don't think eMule does more disk access than anti-virus soft...
Besides, I think you should know sth. about the relationships between official and its mods. What you need is already done in many mods, while you still strongly requests it being added to official.

This post has been edited by Ejack79: 28 February 2012 - 11:00 PM

[fox88]

Mountainer, on 28 February 2012 - 11:51 PM, said:

I do know how to set it up, I can see how it works.

When you try to explain something, it becomes too clear how little you know. Unfortunately, you do not even try to learn.

Mountainer, on 28 February 2012 - 11:51 PM, said:

I set 40KB/s means 12 x 3BK/s slots

Integer part of 40/3 is 13. You've got troubles even with arithmetics.

Mountainer, on 28 February 2012 - 11:51 PM, said:

But even if the downloaders are calpable to download faster then 3KB/s, the amount of slots is not being reduced. Once emul open x amount of slots, it will not go down. Amount is there to stay, it does.

The logic is more complex; there are cases when eMule will open a slot and when it will not.
Once open, slot would not close until the transfer is complete. At 3KB/s it takes about 50 minutes to complete one part.

Mountainer, on 28 February 2012 - 11:51 PM, said:

Too many slots = too many simultaneous reading from different sectors of the hard disc = unnecessary strain on the hard disc = reduced life span of the hard disc.

Disconnect your HDD, never turn it on - it will last forever.
Only a noob could be serious about killing hard disks with data stream slightly above 20KB/s.
Strange, you never complained about download speed beeing too high for your poor disk.

Mountainer, on 28 February 2012 - 11:51 PM, said:

Six slots is about right. more then that is too much. Thats why I have to reduce upload, even if my connection can endure much more.

You failed to look smart here.

Ejack79, on 29 February 2012 - 01:52 AM, said:

What you need is already done in many mods, while you still strongly requests it being added to official.

This topic is typical example: people do not know how to use already existing features, but request more. As if more features makes it simpler or leaves less opportunities to misconfigure.

[xilolee]

fox88, on 29 February 2012 - 08:24 AM, said:

Strange, you never complained about download speed beeing too high for your poor disk.

How can you tell it???
I bet he put 20 in download limit.

This post has been edited by xilolee: 29 February 2012 - 08:38 AM

[Mountainer]

Why this collective attack on me?
What is the point to dissect my post like that?

fox88, on 29 February 2012 - 08:24 AM, said:

Mountainer, on 28 February 2012 - 11:51 PM, said:

I do know how to set it up, I can see how it works.

When you try to explain something, it becomes too clear how little you know. Unfortunately, you do not even try to learn.

Is there something more to it, then just being abusive?

fox88, on 29 February 2012 - 08:24 AM, said:

Mountainer, on 28 February 2012 - 11:51 PM, said:

I set 40KB/s means 12 x 3BK/s slots

Integer part of 40/3 is 13. You've got troubles even with arithmetics.

Shshsh... Of course, it was just approximation. In reality it is 3KB/s plus some decimals. And you do know it.

fox88, on 29 February 2012 - 08:24 AM, said:

Mountainer, on 28 February 2012 - 11:51 PM, said:

But even if the downloaders are calpable to download faster then 3KB/s, the amount of slots is not being reduced. Once emul open x amount of slots, it will not go down. Amount is there to stay, it does.

The logic is more complex; there are cases when eMule will open a slot and when it will not.
Once open, slot would not close until the transfer is complete. At 3KB/s it takes about 50 minutes to complete one part.

Now, that is entire point! When the part is complete, the slot is not being closed (unless queue is empty), even if there are downloaders who could use more speed. Instead the slot is being offered to new downloader. Once slot is open, it will stay open untill queue is empty.

fox88, on 29 February 2012 - 08:24 AM, said:

Mountainer, on 28 February 2012 - 11:51 PM, said:

Too many slots = too many simultaneous reading from different sectors of the hard disc = unnecessary strain on the hard disc = reduced life span of the hard disc.

Disconnect your HDD, never turn it on - it will last forever.
Only a noob could be serious about killing hard disks with data stream slightly above 20KB/s.
Strange, you never complained about download speed beeing too high for your poor disk.

Stream is not the point. it is amount of slots.
And as I said, 20KB/s stream is OK. But 200KB/s gets way to many slots.
Yes, the expected lifespan of HDD is subjective matter. But hard discs are expensive and I am not very ritch. So better safe then sorry, I have think.

fox88, on 29 February 2012 - 08:24 AM, said:

Mountainer, on 28 February 2012 - 11:51 PM, said:

Six slots is about right. more then that is too much. Thats why I have to reduce upload, even if my connection can endure much more.

You failed to look smart here.

Not being trying smartness. I thinking it just common sense. Why so much abusiveness?

fox88, on 29 February 2012 - 08:24 AM, said:

Ejack79, on 29 February 2012 - 01:52 AM, said:

What you need is already done in many mods, while you still strongly requests it being added to official.

This topic is typical example: people do not know how to use already existing features, but request more. As if more features makes it simpler or leaves less opportunities to misconfigure.

Mods, it is hard to trust them. Some may contain keylogers, troyans and whatnot. I am not being programmer, have hard time telling good apple from rotten apple so, so I steer away from mods. Better safe then sorry I have think.

[hooligan3000]

Quote

Mods, it is hard to trust them. Some may contain keylogers, troyans and whatnot. I am not being programmer, have hard time telling good apple from rotten apple so, so I steer away from mods. Better safe then sorry I have think.

:-D i dont know what for crazy mods u know

i know a lot of good emule mods

[Link64]

Mountainer, on 29 February 2012 - 04:01 PM, said:

fox88, on 29 February 2012 - 08:24 AM, said:

Mountainer, on 28 February 2012 - 11:51 PM, said:

But even if the downloaders are calpable to download faster then 3KB/s, the amount of slots is not being reduced. Once emul open x amount of slots, it will not go down. Amount is there to stay, it does.

The logic is more complex; there are cases when eMule will open a slot and when it will not.
Once open, slot would not close until the transfer is complete. At 3KB/s it takes about 50 minutes to complete one part.

Now, that is entire point! When the part is complete, the slot is not being closed (unless queue is empty), even if there are downloaders who could use more speed. Instead the slot is being offered to new downloader. Once slot is open, it will stay open untill queue is empty.

That should usually not happen, at least not if you are uploading at 200KB/s and have already so many slots open, that they all get just 3KB/s. If it happens, than eMule is not able to upload to the connected clients as much as it would like to, i.e. more than those 3KB/s. Since with that many open slots it is highly unlikely, that no one of the connected clients can take more than 3KB/s, I'd assume the problem is somewhere at your end.

Mountainer, on 29 February 2012 - 04:01 PM, said:

Yes, the expected lifespan of HDD is subjective matter.

Did you bother to read the survey I posted? There's nothing subjective about it, the load isn't anything to care much about, at least not for drives, which reach the expected lifetime. And whatever your eMule does with your hard drive when having all that upload slots open, it's probably still in the low utilisation level of that survey anyway.

Mountainer, on 29 February 2012 - 04:01 PM, said:

Mods, it is hard to trust them. Some may contain keylogers, troyans and whatnot.

I think it should be safe as long as you use mods, which are supported here in forum or even have their own subforums.

This post has been edited by Link64: 29 February 2012 - 08:14 PM

[fox88]

Mountainer, on 29 February 2012 - 06:01 PM, said:

Why this collective attack on me?

Who are you to deserve a collective attack? Everyone expressed his own point of view.

Mountainer, on 29 February 2012 - 06:01 PM, said:

What is the point to dissect my post like that?

To let you know where you made a mistake; and mistakes are everywhere.

Mountainer, on 29 February 2012 - 06:01 PM, said:

Shshsh... Of course, it was just approximation. In reality it is 3KB/s plus some decimals. And you do know it.

I do know slightly more: there is KB and KiB. But even if you take 40000/3072, it is still over 13.

Mountainer, on 29 February 2012 - 06:01 PM, said:

When the part is complete, the slot is not being closed

I can repeat: improper configuration. Though there is enough information in Support forums; and you could ask there.
PS. Playing with font size does not make you right.

Mountainer, on 29 February 2012 - 06:01 PM, said:

And as I said, 20KB/s stream is OK. But 200KB/s gets way to many slots.
Yes, the expected lifespan of HDD is subjective matter.

You can care about your HDD in any way you prefer, but please leave alone technical aspects.
Complaining about 20KB/s, when HDD are capable of giving 20MB/s and more, is like claiming a pencil is way too heavy for you.

[Some Support]

While it really doesn't matters too much as long as the total upload stays the same, 3KB/s is indeed a bit out of date with the connectionspeeds common today. I suppose it would make sense to raise it to an average of 10KB/s per Slot at least.
Also as mentioned elsewhere there will be some fixes for faster uploading (meaning > 1-2Mbit) in the next version.

[sonoro]

@ Some Support

why not add slotfocus?

More speed to all you people want!

[ducho]

In my opinion, it would make sense to raise upload rate per slot, but never let the user choose how many slots or upload rate per slot. We don't need to add complex options.
It would be easy for an average user choose a good value? How to measure support issues? aka more forums topics, revised tutorials etc

And if we provide a good default value then there is no problem at all.

This post has been edited by ducho: 03 March 2012 - 03:02 AM

[Meuh6879]

ducho, on 03 March 2012 - 03:54 AM, said:

We don't need to add complex options.

so, don't cross the case "view advanced setting" in advanced options ...
other users want this (like me).

i use a mod for this slotfocus and slotlimiter ... cumulate with USS ping feature, it's a good for 6 slots max for 100ko/s line - 1MBit/s UP.

This post has been edited by Meuh6879: 03 March 2012 - 11:47 AM

[DatHebIkWeer]

Ejack79, on 28 February 2012 - 11:52 PM, said:

I don't think eMule does more disk access than anti-virus soft...
Besides, I think you should know sth. about the relationships between official and its mods. What you need is already done in many mods, while you still strongly requests it being added to official.

So now it is time to make it general policy. Of course many mods changed this because it desperately needs change.

In my opinion the whole idea of having many uploads simultaneously is not right. If you have 60 kB/s upload for instance and 20 downloaders using 3kB/s each simultaneously who do you benefit?
It means that they all need about an hour to download a 9MB chunk. All that time something can go wrong. For instance if I decide to close the program all downloads will just be partial. It makes much more sense to give the 1st downloader 60kB/s so he can do the download in 3 minutes, then give #2 60kB/s and so on. In that case all will have their chunk sooner and more reliable. The downside just being that the download starts a few minutes later, which is more than offset by the fact that it finishes much sooner. Of course if the downloader cannot handle 60 kB/s the rest can be given to #2 then to #3 and so on as needed. So I would suggest dropping the "number of slots" thing altogether and just focus on the upload speed and allocating that as efficiently as possible to as little as possible simultaneous slots (with regard to the queue and protection of the rights of the small bandwidthed).

Of course if I decide to close down after a half hour 10 of the 20 downloaders won’t get a chunk of me. But if everything is right 10 will have their chunk downloaded and available now so they can turn to those for solace. And so we will all benefit.

Another advantage of sequential download rather then simultaneous is of course that chunk selection can take into account the already downloaded chunks of others. This is of great importance because the stability of the availability of files in KAD requires that the rarest chunks are always distributed first. But I will discuss that further in threads concerning that topic.

[Link64]

DatHebIkWeer, on 07 July 2012 - 11:59 AM, said:

It makes much more sense to give the 1st downloader 60kB/s so he can do the download in 3 minutes, then give #2 60kB/s and so on. In that case all will have their chunk sooner and more reliable. The downside just being that the download starts a few minutes later, which is more than offset by the fact that it finishes much sooner.

And you are apparently one more of those, who think so. NOTHING except for the first few uploads at the beginning of the eMule session of the uploader will finish sooner. So in case of your 60KB/s the first 15* or so downloaders will get the requested data sooner, after that it doesn't matter. It will start later, run at higher speed and finish at the same time, as it would if it has started earlier and run at slower speed.

*) properly configured eMule should not open more slots than (about) that at 60KB/s, I have 12-14 at 50KB/s.

DatHebIkWeer, on 07 July 2012 - 11:59 AM, said:

Of course if I decide to close down after a half hour 10 of the 20 downloaders won’t get a chunk of me. But if everything is right 10 will have their chunk downloaded and available now so they can turn to those for solace. And so we will all benefit.

I'm not sure, where the assumption, that most downloaders need complete chunks before they can share them, comes from. From watching my uploads I'd say, uploading a complete chunk from the beginning to the end is not that common (<50% of my uploads), at least on larger files with many sources the upload starts just somewhere and switches eventually to another chunk later, quite often I'm even not alone uploading that chunk to that downloader.

Don't get me wrong, I'm not against such change, the current slot speeds are indeed not what they should be for todays internet connection speeds, but nothing is going to finish faster because of that. The actuall benefit I see (considering the crappy routers people get from their ISPs) is going to be the decreased amount of open connections, which eMule can use for something else, if it needs to (less "too many connections" for example).

And SomeSupport said in #28, the amout of slots is going to be decreased.

[DatHebIkWeer]

Link64, on 07 July 2012 - 01:08 PM, said:

And you are apparently one more of those, who think so. NOTHING except for the first few uploads at the beginning of the eMule session of the uploader will finish sooner. So in case of your 60KB/s the first 15* or so downloaders will get the requested data sooner, after that it doesn't matter. It will start later, run at higher speed and finish at the same time, as it would if it has started earlier and run at slower speed.

*) properly configured eMule should not open more slots than (about) that at 60KB/s, I have 12-14 at 50KB/s.

I disagree to that. But of course it doesn't really matter because in most cases it will only be partial downloads. The waiting times are usually much longer than the download times anyway. If either one of us is right the difference will only be like an hour or so. That is nothing compared to the month I have to wait for some files to download.

Of course sequential download will benefit the first in line most. If you have on average 15 simultaneous downloads then #1 in line will be done the fastest where #15 will have no gain but also no loss. But after that when the next 15 downloaders get their turn the thing starts at 0. So #16 gets it sooner and #30 won't have any gain. By the time #30 starts he will have 29 chunks extra available to request from other users. So, will he need me? Or kindly leave my bandwidt to #31?

If people did not start at the same time but at a 3 minute interval at 3 kB/s things would be different. If that pace is broken and new additions are halted at time 0 till everybody is finished, people who are finishing their downloads will have that done sooner. The average total remaining chunks of the 30 requested at time 0 will be 15. If one user finishes it the other users will get his bandwidth so the 15 chunks will all be done in 30 minutes.
User #1 will be the one who in the old situation was due for upload at time 0. He would have had 3 kB/s so he would have finished at time 1:00 hour.
Now he has to wait till everybody is finished and get 60 kB/s so user #1 will start at 0:30 and end at 0:33. He will gain 27 minutes.
User # 2 would have finished at 1:03, but now starts at 0:33 and ends at 0:36. He will gain 27 minutes
User # 3 would have finished at 1:06, but now starts at 0:36 and ends at 0:39. He will gain 27 minutes
User # 4 would have finished at 1:09, but now starts at 0:39 and ends at 0:42. He will gain 27 minutes
User # 5 would have finished at 1:10, but now starts at 0:42 and ends at 0:45. He will gain 27 minutes
User # 6 would have finished at 1:15, but now starts at 0:45 and ends at 0:48. He will gain 27 minutes
User # 7 would have finished at 1:18, but now starts at 0:48 and ends at 0:51. He will gain 27 minutes
User # 8 would have finished at 1:21, but now starts at 0:51 and ends at 0:54. He will gain 27 minutes
User # 9 would have finished at 1:24, but now starts at 0:54 and ends at 0:57. He will gain 27 minutes
User # 10 would have finished at 1:27, but now starts at 0:57 and ends at 1:00. He will gain 27 minutes
User # 11 would have finished at 1:30, but now starts at 1:00 and ends at 1:03. He will gain 27 minutes
User # 12 would have finished at 1:33, but now starts at 1:03 and ends at 1:06. He will gain 27 minutes
User # 13 would have finished at 1:36, but now starts at 1:06 and ends at 1:09. He will gain 27 minutes
User # 14 would have finished at 1:39, but now starts at 1:09 and ends at 1:12. He will gain 27 minutes
User # 15 would have finished at 1:42, but now starts at 1:12 and ends at 1:15. He will gain 27 minutes
User # 16 would have finished at 1:45, but now starts at 1:15 and ends at 1:18. He will gain 27 minutes
User # 17 would have finished at 1:48, but now starts at 1:18 and ends at 1:21. He will gain 27 minutes
User # 18 would have finished at 1:51, but now starts at 1:21 and ends at 1:24. He will gain 27 minutes
User # 19 would have finished at 1:54, but now starts at 1:24 and ends at 1:27. He will gain 27 minutes
User # 20 would have finished at 1:57, but now starts at 1:27 and ends at 1:30. He will gain 27 minutes
User # 21 would have finished at 2:00, but now starts at 1:30 and ends at 1:33. He will gain 27 minutes
User # 22 would have finished at 2:03, but now starts at 1:33 and ends at 1:36. He will gain 27 minutes
User # 23 would have finished at 2:06, but now starts at 1:36 and ends at 1:39. He will gain 27 minutes
User # 24 would have finished at 2:09, but now starts at 1:39 and ends at 1:42. He will gain 27 minutes
User # 25 would have finished at 2:10, but now starts at 1:42 and ends at 1:45. He will gain 27 minutes
User # 26 would have finished at 2:15, but now starts at 1:45 and ends at 1:48. He will gain 27 minutes
User # 27 would have finished at 2:18, but now starts at 1:48 and ends at 1:51. He will gain 27 minutes
User # 28 would have finished at 2:21, but now starts at 1:51 and ends at 1:54. He will gain 27 minutes
User # 29 would have finished at 2:24, but now starts at 1:54 and ends at 1:57. He will gain 27 minutes
User # 30 would have finished at 2:27, but now starts at 1:57 and ends at 1:00. He will gain 27 minutes
I am not a mathematician so the actual gain may be 30 minutes. Not sure.

That was a lot of copy/pasting to bring home a simple point:
If you upload sequentially the downloaders have to wait only for the people in the queue before them.
If you upload simultaneously they also have to wait for the people in the queue behind them.
Hence the extra delay of simultaneous slots.

I am new on this site so I have a limited number of posts per day at my disposal. I will have to be careful not to discuss to wildly or I will spend them all too fast.
Sorry for that

[Link64]

DatHebIkWeer, on 07 July 2012 - 03:10 PM, said:

Of course sequential download will benefit the first in line most. If you have on average 15 simultaneous downloads then #1 in line will be done the fastest where #15 will have no gain but also no loss. But after that when the next 15 downloaders get their turn the thing starts at 0. So #16 gets it sooner and #30 won't have any gain.

In an idealized world, where everyone gets a full chunk and can take the full 60KB/s at any time, it might be like that, but in real world it really doesn't matter, at the end of the day you have uploaded about 5GB at 60 KB/s. We are talking here about also about minutes, while download of a file takes days or even weeks.

DatHebIkWeer, on 07 July 2012 - 03:10 PM, said:

By the time #30 starts he will have 29 chunks extra available to request from other users. So, will he need me? Or kindly leave my bandwidt to #31?

Again, in an idealized world and in case of just one shared file... in real world #30 might be the first, who requests just this file and even if we assume, that all 29 before him requested the file he needs and only chunks he does not have yet, it's very unlikely that he finds out, that they have those chunks, gets thru their queues and downloads them before he gets it from me. Again, the eventually gained minutes does not matter in real world.

DatHebIkWeer, on 07 July 2012 - 03:10 PM, said:

If people did not start at the same time but at a 3 minute interval at 3 kB/s things would be different. If that pace is broken and new additions are halted at time 0 till everybody is finished, people who are finishing their downloads will have that done sooner. The average total remaining chunks of the 30 requested at time 0 will be 15. If one user finishes it the other users will get his bandwidth so the 15 chunks will all be done in 30 minutes.

Why would that happen? eMule will not suddenly change the slot opening strategy... I actually don't get, what your idea here is...