MLDonkey’s settings

saltisol has toyed with his MLDonkey’s setting files to resolve the /dev/ram0 maxed out issue. Besides toying with his download settings he decided to remove unnecessary files like those used for IP Blocking, server.met, …

According to several users, the /dev/ram0 maxing out problem is solved. Kudos to the community!

Sample downloads.ini file: Download file

How to replace your downloads.ini

Step 1
extract the contents of the archive to /mnt/HD_a2 and hence the path to the file should be /mnt/HD_a2

Step 2
telnet to your DNS-323 and ensure that your mlnet is not running

Step 3
Issue the following commands

/ # cd /mnt/HD_a2
/mnt/HD_a2 # mv ./mldonkey/downloads.ini ./mldonkey/downloads.bak
/mnt/HD_a2 # mv downloads.ini ./mldonkey/downloads.ini

Step 4
Start the mlnet core (/mnt/HD_a2/ and run through your settings (if needed) and see if you can complete your torrent this time.


Treat shadowandy!

If these step-by-step guides have been very helpful to you and saved you a lot of time, please consider treating shadowandy to a cup of Starbucks.  

  • Jj

    Are these settings good for edonkey use, bittorrent use or both? 3 upload_slots sounds a bit small number for bittorrent use…

    i managed to complete one 98% stuck torrent by

    mkdir /mnt/HD_a2/tmp
    cp /tmp/* /mnt/HD_a2/tmp/
    mv /tmp /tmp-bak
    ln -s /mnt/HD_a2/tmp /tmp

    so anyways, by creating the tmp directory to the hard disk and symlinking tmp from root.

    Do you have any comments for this approach? I’m not sure if this was the thing that helped me to complete a big torrent, since have tried to tinker the settings everyday anyway…

    Also i would appreciate some DNS-323 specific help for setting mldonkey just right for bittorrent use. i don’t know what kind of load averages or memory usage i should try to reach so that samba would be still completely usable… now i have 128 max uploads and it still seems to work, but mldonkey stalls to 10kb/sec when i use samba over gigabit lan. I prefer it this way however, i prefer samba working, bittorrent can wait 😉

    Also some links to config info specifically tuned for DNS-323 would be nice…. Also andy, i found that some of your sample configs were contradicting with 2.9.0, the general upload_slots tune down the bigger numbers in bittorrent settings when mldonkey is started… so should i use the bittorrent number 96 (or wat was it) as general number, or is the 5 about right? Actually i have no idea what eg. Azureus is using… sources per chunk.. very confusing settings mldonkey has.

  • shadowandy

    Jj: I thought of using symlinks as well but because it is located on / mount, I did not touch it as I am not sure if during the process of symlinking it would it have any undesirable effects.

    The settings I have used for my bittorrent was ported from my utorrent settings.

    I had:
    – max global connection of 304
    – max of 3 downloading torrents
    – 96 connections per torrent
    – 4 ports opened per second (as DNS-323 is a small device)

    Perhaps I would upload my bittorrent setting file.

  • torrent stuck at 99%

    Do you have the problem of torrent stuck at 98% for MLDonkey on DNS-323? Or you are facing a problem that is more head banging, instead of the torrent stuck at 98% you have the torrent stuck at 99% for…

  • MLDonkey for DNS-323

    Sample setting file(s) Sample downloads.ini file: Download file guide Various compiled versions 2.8.5: download 2.8.7: download blog entry 2.8.7 (new): download blog entry 2.8.7 (lite): download blog entry 2.8.7 (new+gd): download blog entry 2.8.7 (li…

  • Jj

    I tried to read trough your latest download.ini but I failed to see the changed parts affecting for my problem. My torrents are usually several gigabytes so I don’t know if that’s the case… My settings are now considerably lower than yours with

    max_opened_connections 192
    max_indirect_connections 30
    max_upload_slots 3
    max_release_slots 20
    max_connections_per_second 4

    also tried to play around with buffers etc, but to no effect, the checksum calculation is failing due to not enough space.

    In normal condition and mldonkey running my /ram0 73% in use, 2.5MB available however… it doesn’t seem to change when calculating the checksum, or maybe i haven’t been fast enought to type df -h 😉

    So far, the only solution for me has been symlinking the tmp to the hard-drive… which has worked for me perfect… i’m now in the process of adding the symlinkg to the fun_plug, so we’ll see if it’s ok..

    I was also hoping for later to maybe chrooting debian and maybe have all the extras installed to a usb-key so that my both hard-drives could sleep while accessing for example my ssh, but i found out that if i have twonkey-media server on and it does it’s refresh hourly, during that refresh the usb-storage.ko module dies and attached drive is “dead” to the kernel…

    Found this out when i was trying to move my data over external usb-enclosure, and the transfer stopped always after one hour. after killing twonkey, all worked…

    I think i have to use the symlinking method for now, since I don’t yet know what parameters are crucial… of course i could just drop the download.ini directly to my box and try that, but i prefer tweaking the settings by hand… the problem is, that i don’t fully understand the mlnet parameters, and specifically what is causing this problem… i think i have all the settings now at a lower level than your samples, if i haven’t missed anything…

    Is there any specific values i should check, which might influence to the computation error? However, i have only 73% in use all the time anyway, and still the computation error… maybe in multi-gigabyte transfers the chunk sizes are so big that the tmp-data does not fit into 2.5MB?

  • Jj

    btw: checked the /tmp and only things touched lately were fan_status, web_chk and samba/browse.dat… and as im doing it now

    rm -rf /mnt/HD_a2/tmp/*
    cp -a /tmp/* /mnt/HD_a2/tmp/*
    mv /tmp /tmp-bak
    ln -s /mnt/HD_a2/tmp /tmp

    in the fun_plug, i think a minimal damage is done since the swap is taking a very short time when done in a script. also the content of the original tmp is copied to the linked tmp, so any process needing the info gets it from the new place..

    I don’t know why my system needs this, but it works. Otherwise everything is stuck to 99%…

    I can see that there could be some danger if some process tried to write to tmp at the time i’m copying and moving the folder, but haven’t had any problems yet… *fingers crossed*…

  • Jj

    oh, and one another thing. symlinking the tmp, seems to need the restart of samba (i’m not using upnp server, ftp, or anything else)

    so adding smb restart after the linking and everything works just fine.

    btw. i’m running the linking as the first thing in the fun_plug, so dropbear ssh and all the other fun_plug stuff from fonz gets started to the new tmp-directory…

  • shadowandy

    Jj: Instead of symbolic linking the /tmp directory, perhaps you wish to try this.

    Edit and add the following line under the current export statement in the shell script
    export TMPDIR=”/mnt/HD_a2/mldonkey/temp”

    Do let me know if it works

  • Jj

    I have yet tried only to do a manual Verify Chuncks-option, and the Error message changes from:

    [cF] Checksum computation failed: Exception: write failed: No space left on device


    [cF] Checksum computation failed: Exception: lseek failed: Invalid argument

    but this “invalid argument” message i get even if I use the symlinking the temp method, so it seems now at least that the exporting the TMPDIR variable is doing the same thing that my symlinking is, as to comparing the error messages…

    I have to monitor this a bit closely if the TMPDIR-variable is enabling me to complete my torrents also, i’m hopeful that it will, so i’ll get back to you when i have completed some torrents 😉

  • shadowandy

    Jj: I think the lseek command is due to the compilation problem or because lseek is implemented differently on my compiling machine (compared to DNS-323).

    Yeap, do let me know if the TMPDIR variable fixes torrenting problems.

    Thanks for testing. 🙂