[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...

[0x00]

I have set a 2.2MB/s eMule upload on a 20Mbit upload connection. Upload of 40+ 1GB+ files is really killing my HDD performance! A music video playback in the background becomes jittery, while the antivirus is crazy with scanning all those big files.

I'm sorry, but I have to DECREASE my upload, because my computer becomes UNUSABLE if eMule is running in the background.

Furthermore, a max 1.5MB file buffer size if a joke! On my connection, it's good for 0.7s (yes, 700ms).

I'd like to be able to limit my uploads to 20 files, with a 50MB buffer per file.

Sorry, I'm not sharing my full connection, because eMule is outdated. Make eMule settings optimized out the box and get a list of servers and connect to ed2k & Kad automatically. I really like the sharing network (as opposed to torrent leeching), but an update is badly needed.

This post has been edited by : 02 June 2013 - 04:42 PM

[fox88]

0x00, on 02 June 2013 - 07:38 PM, said:

I have set a 2.2MB/s eMule upload on a 20Mbit upload connection.

If you had any idea of what you're doing, you would never set 2.2MB/s limit with 20Mbit upload.
For 20Mbit/s it should be like 1.95MB/s or less. Otherwise you'll flood the connection.

0x00, on 02 June 2013 - 07:38 PM, said:

the antivirus is crazy with scanning all those big files.

I guess you never thought about excluding already downloaded shared files from scanning.

0x00, on 02 June 2013 - 07:38 PM, said:

Furthermore, a max 1.5MB file buffer size if a joke! On my connection, it's good for 0.7s (yes, 700ms).

This buffer is for download, not for upload.
Do you understand that OS caches disk I/O?

[0x00]

Fox, I do not like your tone.

Now, to the topic:

fox88, on 02 June 2013 - 06:20 PM, said:

0x00, on 02 June 2013 - 07:38 PM, said:

I have set a 2.2MB/s eMule upload on a 20Mbit upload connection.

If you had any idea of what you're doing, you would never set 2.2MB/s limit with 20Mbit upload.
For 20Mbit/s it should be like 1.95MB/s or less. Otherwise you'll flood the connection.

If I set my upload to 2200KB/s, it stays at 2200KB/s. Ping to my country ISP servers is still <6 ms.
A 20Mbit/s connection is good for about 2500KB/s, so there is still about 300KB/s of headroom

fox88, on 02 June 2013 - 06:20 PM, said:

0x00, on 02 June 2013 - 07:38 PM, said:

the antivirus is crazy with scanning all those big files.

I guess you never thought about excluding already downloaded shared files from scanning.

Well, what are virus definition updates for? A new definition might recognize something that it previously didn't. But yes, I did copy video files to another folder and excluded it from scanning. But 95% of other people wouldn't and they would just decrease the upload or stop using emule at all. Do you really want the design of emule to encourage that?

fox88, on 02 June 2013 - 06:20 PM, said:

0x00, on 02 June 2013 - 07:38 PM, said:

Furthermore, a max 1.5MB file buffer size if a joke! On my connection, it's good for 0.7s (yes, 700ms).

This buffer is for download, not for upload.
Do you understand that OS caches disk I/O?

Valid point. However, nowhere it states that it is for downloads only. And still, a default setting should be higher than it was 10 years ago - today 4GB RAM is the bare minimum.

I'm just saying that the default emule settings are no good for today's fiber connections. Yes, I do have a SSD, but I have Windows 8 on it, which I don't like. So I'm still running Windows 7 off a HDD...

Proposed solution:
1. Let emule have a buffer for 60s of uploading a certain file at the current speed (15s moving average speed)
2. Let the default memory usage be 15% of free RAM.
3. Let the number of upload slots be calculated from that. But having more than 40 slots is really not good, because you'll get too much random seeks. A HDD tops at couple of MB/s then reading this, instead of having a 30MB/s transfer rate.

A note: almost everyone of the 40+ uploaded 1GB+ files was different. Do a simulation yourself, what it does to performance...

[fox88]

0x00, on 03 June 2013 - 09:35 AM, said:

I do not like your tone.

Sorry; I did not like yours either.

0x00, on 03 June 2013 - 09:35 AM, said:

A 20Mbit/s connection is good for about 2500KB/s, so there is still about 300KB/s of headroom

I could suggest you to stick to the rule "do not go above 80%", but - it's your system.

0x00, on 03 June 2013 - 09:35 AM, said:

Do you really want the design of emule to encourage that?

No design would counter your wish to recheck files on every access and on every antivirus update.

0x00, on 03 June 2013 - 09:35 AM, said:

However, nowhere it states that it is for downloads only.

Please tell where it was said to be a read or even read ahead buffer.

0x00, on 03 June 2013 - 09:35 AM, said:

And still, a default setting should be higher than it was 10 years ago - today 4GB RAM is the bare minimum.

Keeping unsaved data in memory is the right way to lose all that data in case of trouble.
Besides, 'today' a few people use less than 4GB RAM.

0x00, on 03 June 2013 - 09:35 AM, said:

1. Let emule have a buffer for 60s of uploading a certain file at the current speed (15s moving average speed)

Why 60s and how could you predit what data would be requested?

0x00, on 03 June 2013 - 09:35 AM, said:

2. Let the default memory usage be 15% of free RAM.

Yet another random number, which suits your current personal tastes.

0x00, on 03 June 2013 - 09:35 AM, said:

3. Let the number of upload slots be calculated from that. But having more than 40 slots is really not good, because you'll get too much random seeks.

In other topic someone told that with 100 slots limit he could not fill all of the bandwidth.

[0x00]

Fox, I didn't expect such a hostile attitude.

I'm just saying that current emule settings cause my system to slow down and keep HDD constantly seeking.

More performance tuning is needed. Vuze for example doesn't slow my system at 2.2MB/s upload, but eMule does. Implementing a more fine grained settings system (have a look at Vuze advanced settings) should be No1 priority for the next eMule update.

I won't go line by line what you said. According to performance, eMule developers could devise 15 different profiles and the algorithm should select one, best suited to the machine, according to its: RAM, SSD vs HDD, upload/download bandwidth, while at the same time setting IO priority at below normal as opposed to user processes etc.

This post has been edited by : 03 June 2013 - 07:35 PM