exact emule settings

[gambit3]

i'm writing this because i've been experimenting with emule settings. i've been having trouble collecting some of the less popular 33 bases, so i've been sharing mine with other than default settings, and gambit has been almost constantly uploading at 100kB/s since the changes:

as far as optimum upload:download ratio, it seems that emule performs best (given that more people per definition will want to download than upload) if your upload limit is set at 85% and download limit set at ~80% of advertised capability of your connection. this also allows for peaking during filesearches and such, as well as allowing some bandwidth for other activites.

this is nothing new to most people i would imagine. my second discovery, though, has had already seemingly wide-ranging implications regarding the availability of files.

i was looking through my file list a couple of hours ago, and noticed that almost every single one of my tables (the only things i share through emule are tables and related xref info such as tbs files and md5 checksums) is set auto[hi] for uploading. this seems to be default, but there were a few that were incomplete that had auto[no] next to them. this in effect means they will never be uploaded! after changing the entire shared collection (including those in the emule incoming and temporary directories) to normal priority, the uploading has been both a lot more smooth and a lot more even, to the point that these incomplete files are now in progress for downloading as well as the parts i have having been uploaded (at least) 3 times each.

whether this is a reflection on actual availability or just recent downloads, i am not sure, but whatever the case, the change away from teh default priority system has resulted in a much more emule-favourable upload:download ratio, having gone from 1:3.2 across 15G (uploaded) to 2.5:1 across now 48G (uploaded). quite a change from a week ago.

also among the possible changes is the queueing system. the credit system seems a good idea, so i may submit an emule with a slightly revised credit system... that remains to be seen though, as improvements in theory aren't always improvements in practice, so i'll test a few things (up:down ratio rewards, such as people go top of queue if upload ratio is higher regardless of connection speed, is one of the first things i want to test, but this may unfairly benefit people who have the credit system turned off on their emule) and make any submissions to sourceforge that i think are useful.

the projected benefits of these changes will not be seen until a week or so from now though, when the people who aren't serious about sharing have taken all the files they want (there are at least 3 of you that i have seen that fit this category, with one alone having taken over 6G from me already in a little over a week) and either leave the system or have more uploading going on. when they do come, the benefits will be that people can concentrate more on getting the bases that they want and the sharing base will expand quite quickly at that time.

at this point, though, there are still 6 files that have never been seen complete. i think this is more to do with the priority system than that they aren't out there, as i searched for one of the files i knew i had while it was on auto[no] priority, and the search didn't return my own file, while it did for one on auto[hi] priority

due to these results, i think emule settings for tables should be addressed in order to achieve maximum ''shareability''

happy collecting!

gambit

[Kirill Kryukov]

Hmm.. Interesting post. Yes, eMule upload priorities are a very powerful mechanism. Here I set it to "Release" for all EGTB files that I share, including the incomplete ones (those that are still not downloaded completely).

i'm writing this because i've been experimenting with emule settings. i've been having trouble collecting some of the less popular 33 bases, so i've been sharing mine with other than default settings, and gambit has been almost constantly uploading at 100kB/s since the changes:

I am sharing all 33 pawnless bases at "Kirr" machine, so you should be able to see them. If you mean pawnless of course. (Those with pawns we more often call 33p or 33+p, or something with "p" anyway). BTW, 100 KB/s upload is very good contribution to the project!

i was looking through my file list a couple of hours ago, and noticed that almost every single one of my tables (the only things i share through emule are tables and related xref info such as tbs files and md5 checksums) is set auto[hi] for uploading. this seems to be default, but there were a few that were incomplete that had auto[no] next to them. this in effect means they will never be uploaded!

No, it does not mean they will never be uploaded! It just means they will be uploaded much less than with higher priority. In eMule the upload priority affects only one thing - how fast the person who requested the file will progress in your queue. Person who requested a file with "Release" priority will move in the queue very fast. In that sense eMule queue is not a "first in first out" type. If the file was not uploaded at all it probably means it was never requested..

after changing the entire shared collection (including those in the emule incoming and temporary directories) to normal priority, the uploading has been both a lot more smooth and a lot more even, to the point that these incomplete files are now in progress for downloading as well as the parts i have having been uploaded (at least) 3 times each.

Yeah I also have uniform upload priority ("Release") for all tablebase files.

whether this is a reflection on actual availability or just recent downloads, i am not sure, but whatever the case, the change away from teh default priority system has resulted in a much more emule-favourable upload:download ratio, having gone from 1:3.2 across 15G (uploaded) to 2.5:1 across now 48G (uploaded). quite a change from a week ago.

also among the possible changes is the queueing system. the credit system seems a good idea, so i may submit an emule with a slightly revised credit system... that remains to be seen though, as improvements in theory aren't always improvements in practice, so i'll test a few things (up:down ratio rewards, such as people go top of queue if upload ratio is higher regardless of connection speed, is one of the first things i want to test, but this may unfairly benefit people who have the credit system turned off on their emule) and make any submissions to sourceforge that i think are useful.

Do you mean you will submit some changes to the eMule source code? I have to just warn you that about every week a new person comes to eMule forums with some suggestions for improving the credit system. (I don't know if it's still like this, I did not visit there for a while now). So if you are serious about this you better have a really convincing argument why your new credit system is better than the existing one.

Actually there is a number of eMule mods (modifications) - projects that extend and modify the eMule code keeping the compatibility with the network. You can check some of them, there is a chance that some may have features you are missing. I use original eMule now, but I used eMule Plus for some while and it's very good.

the projected benefits of these changes will not be seen until a week or so from now though, when the people who aren't serious about sharing have taken all the files they want (there are at least 3 of you that i have seen that fit this category, with one alone having taken over 6G from me already in a little over a week) and either leave the system or have more uploading going on. when they do come, the benefits will be that people can concentrate more on getting the bases that they want and the sharing base will expand quite quickly at that time.

There will be always new people joining the project, including those who are not serious about uploading.

One feature about this project is that it kind of sucks you in. Someone comes and tries to download something, and it works, but it takes time. So he stays connected. Then he stays longer, because he wants more and more files.. In the meantime he also shares what he got, so more people is good for this project, even if they are not too serious.

at this point, though, there are still 6 files that have never been seen complete. i think this is more to do with the priority system than that they aren't out there, as i searched for one of the files i knew i had while it was on auto[no] priority, and the search didn't return my own file, while it did for one on auto[hi] priority

Hmm. What files are they? If some file disappeared from the network we should ask all the members to share it again if they have it.

I think priority system should not influence your ability to find files. One more probable reason is that you are either not connected to KAD, or that you may be using an incomplete server list. You can update server list from here: http://ed2k.2x4u.de/index.html

[gambit3]

I am sharing all 33 pawnless bases at "Kirr" machine, so you should be able to see them.

...

No, it does not mean they will never be uploaded! It just means they will be uploaded much less than with higher priority.

...

Yeah I also have uniform upload priority ("Release") for all tablebase files.

the source can be found here. i suggest you have another look at it.

release priority takes file out of credit system, so then priority doesn't count for that file. effect is similar to, but not the same as a uniforma normal ( or high or low, but not auto) priority.

your interpretation of the priority system is logically flawed, but that is off topic, and long to explain accurately. again, see source, taking note of priority order high,auto[hi],normal,auto[med],low,auto[lo],paused,auto[no] for both queueing and download purposes. if you ever get off the queue, your download speed is [paused] if you download an auto[no] file. i have already banned one host for only responding with auto[no] priority answers.

i did indeed mean pawnless, and am aware of the terminology of the majority[v|-|{space}]minority[[+]p] format. i was not implying that these files that have never been seen complete by gambit have disappeared from the network, rather that they need to see some priority adjustment. i have experienced that there have been other files that weren't seen complete until i had already obtained over half of them, so this barely deserved mentioning. it was mentioned more to attempt to make the point of something needing to be done by sharers of tables about their priority systems than as a request for any one of them, which would be both off-topic and covered elsewhere in this forum. :>

here's some food for though (not an isolated, or even uncommon, occurrance):

file 1 downloads at 167 B/s
file 2 downloads at 43665 B/s
server same
request time same (delta time taken to send freq)
file order for freq 1 then 2.
filesizes 576M,917M respectively.
remaining to download 2.7M,78.9M respectively.
upload priority setting on host (right click on host name in upload info box on bottom half of split transfer screen and you can look at host's shared files if host is connected to both donkey and kad networks) auto[no],auto[hi] respectively.
host load same, file 2 begins immediately file 1 ends.
TTC 9d10h, 1:38h respectively.

you would imagine that something has to be done about the priority system form this picture. you would be right from the source...

mean you will submit some changes to the eMule source code? I have to just warn you that about every week a new person comes to eMule forums with some suggestions for improving the credit system. (I don't know if it's still like this, I did not visit there for a while now). So if you are serious about this you better have a really convincing argument why your new credit system is better than the existing one.

i gathered that, hence doing LOTS of testing before even submitting it. i am not a fly-by-nighter: if i don't think it is good enough, i won't waste the author's time submitting it.
that said, there is also nothing to say that emule is good enough for my programming. they have access issues that look like just irresponsible and/or weak and/or inexperienced programming. needing to alter a network address translation (NAT) device (router, hub, hardware firewall, or gateway) in order to get a better connection is a sure sign of someone who is doing something as simply as possible rather than right. (the single flaw in the open source and sourceforge projects.) right would mean slightly longer pings, with no loss in transfer rates, rather than what we have here with emule. since emule is not a time-critical application, right should be used, not quick. the more i go into it, the more i think i'll just leave it as it stands because it looks like most of the essentials are working more by old methods and luck (that the windows apis haven't changed yet) than good programming. enough (and maybe too much) said.

as for convincing argument as to why new credit system would be better, how's this for a start: the idea is to share informatics, be they film, music, text, document, or chess related materials such as tables or opening books (sorry, you don't get mine). as such, new information should have priority, thus turning the credit system OFF should already me made impossible, credits should be entered in register for windows and kernel initialised to be in environment in *ix. credit system should be dual layered: one layer for client-client direct (for instance gambit-kirr) and the other layer for in general (for instance gambit-*). the stat which is more favourable should be used always, both in determining whether to respond and how fast (relatively), meaning if you upload lots relatively, you will be able to download lots, but not only from the sources you uploaded to. the general stat should be housed on a central computer for every nick and high 16bit of ip combination (this allows for dynamic ips for modem or adsl connections).
as for being anonymous, tat is one thing, illegal is something else. i do nothing illegal, so i have nothing to hide.

[Wilfried Eberl]

your interpretation of the priority system is logically flawed, but that is off topic, and long to explain accurately. again, see source, taking note of priority order high,auto[hi],normal,auto[med],low,auto[lo],paused,auto[no] for both queueing and download purposes. if you ever get off the queue, your download speed is [paused] if you download an auto[no] file. i have already banned one host for only responding with auto[no] priority answers.

Guess, you got something wrong?
As a native german speaking, my eMule works in german, of course. But i do know the english eMule-GUI as well. So let me try to explain where you seem to be wrong:

You can set the upload priority either manually or automatically. The highest priority you can manually set is "release". If you are going to set the priority automatically (auto), the system decides whether an upload is set to high (hi), normal (no) or low (lo).

If someone let the system decide, some of his uploads will be set to "auto(hi)", some others to "auto(no) and one or the other will even be set to "auto(lo)". You may understand now, "auto(no)" doesn't mean that someone's system will never upload the requested file. eMule simply doesn't got a feature to reject an upload, unless you move a file out of the shared folder(s). As far as the priority setting "auto" is the standard setting after a standard installation of eMule, noone is doing wrong by not changing the priority manually. Especially newcomers without experiences within eMule will not change anything. But they do share their files as well as you and me. I do not see any reason for a ban - especially not in case of your "auto(no)" problem.

BTW: If you are getting off the queue, the download is always paused - not only when downloading "auto(no)" files. Either the help-file of your eMule is corrupt, or you simply missunderstood the content. If you are off the queue, you are just off the queue - there is nothing to download in those cases!

Kind regards,
Wilfried

[gambit3]

three words, wilfried: read the source.