exact emule settings
Posted: Wed Mar 15, 2006 10:42 am
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
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