Higher CPU usage.BT related?Is this normal?

[fabtar]

Here is my current network section/options:
(Bt is curently disabled for safe ed2k usage)

[bokismoki]

Hello,

I've found the same problem on my mldonkey! And strangely enough, downloading the same torrent (FC6). I'm currently downloading anther torrent, which works fine, but as soon as I activated FC6 download, mlnet started leaking memory. When RAM ran out, my linux (FC2) started swapping, and mldonkey just stopped responding.

Looking at "top", VIRT memory for mlnet went up and over 250 Megs, and I noticed over 90% CPU usage in colon "wa" (waiting for disk?). The whole linux box became very slow until I killed mlnet.

What was different between the two torrents was the number of chunks. FC6 torrent had an unusually high number of chunks (over 2000 when I downloaded around 600 Megs), so it may be BT plugin has a problem handling torrents with very small chunks.

Cheers!

[fabtar]

Hi .... I'm going to recompile anew CVS core tomorrow and retry the same torrent..just for curiosity.Let you informaed

[Smither]

I just compiled from CVS. Same problem.

I also downloaded the FC6 dvd, but it has continued since it.

[fabtar]

&Smither and Co

I have compiled a new CVS on a Kubuntu.
The kubuntu is running on an emulated machine in windows host machine.
I have tested the core by launching few torrents (cause I have encountered the same cpu issue with other torrents not only fc6 I have chosen a bunch of other ones) of about 300 megs cause virtual pc doesn't have a lot of free space.

The mlnet binary have worked flawless, the cpu has been bounded between 0 and 2% with rare peaks over 30% (very rare).
This has confermed that mldonkey works well per-se and that the BT problem is our local problem.

The differences between my kubuntu and the my debian enviroment is in the connection topology: (UDP cannot pass the user-mode firewall of the emulated virtual network for the QEMU -pc... explaining better, only TCP traffic was granted from mldokey to the outside world) and the downloaded files are littler then the old ones.
Another difference is that I have used a completely new config file from scratch.

Thoughts:
By excluding UDP or size related issues, I fear the issue could be triggerd by unlucky library version in my debian/compilation enviroment or by broken cionfig files (perhaps version update is not always transparent or other unlucky situations could have broken the configs in subtle way)

Proposal:
I think that you guys could try re-launching the same self-compiled cores on a fresh account and directory by reconfiguring from scratch a test-mldonkey with new config files and re-trying the fc6 downloads.
It could be useful to track if this thing is config-related.

Do you agree? I'll do the same thing shortly on monday.

If FC6 torrent keeps working bad, I suppose the problem could be tracked in the unlucky-quantum-ufo-debian-guy enviroment.
IMHO

Cheers

[spiralvoice]

Translation from the german forum
http://www.mldonkey.org/forum/viewtopic.php?p=42096#42096

[spiralvoice]

[fabtar]

Done it!!
I have copied the same core in my debian server on another user in a clean directory with no previous settings( no .mldoneky).
I have re-configured anew, I have started 2 ed2k downloads , and 2 downlaods FC6 and another with 400 sources.
The CPU concuption is very fair something around 2-4-6% with very rare peaks of 30% ... and I have very hight download rates around 150Kbytes/sec with BT plugin.
It's the proof the problem is config-file-realted, something was proably wrong in my config or in your configs.

By reconfiguring the new core I have not shared all the directories of the other one in order to createa simpler enviromet, but I have noted that in my past configuration I have done a little (perhaps ) mistake.
I have nested a incoming_direcory of "incoming directories"' type below the main "incoming directory" (which has the files type).
Danno now if this is the problem, but I'll re-write configs from scratch avoiding this situation.

So... guys.. let's try with fresh configs (delete or backup old .mldonkey settings directory, let's save only MD4 and Secure ID signatures!!, let's pay particular atention to the share settings!!).

Please give your feedback about sucess in order to collect more infos in this thread.
Hope useful
Cheers

[spiralvoice]

@fabtar: It would be a good idea to compare your old ini files with the new ones, especially downloads.ini and bittorrent.ini
_________________
Link overview and precompiled cores here: http://mldonkey.sourceforge.net/DownloadLinks

[fabtar]

Ok, I 'll backup the old configs, than I 'll reconfigure anew the main mldonkey in order to obtain all the features and intended behaviours.
After verified a correct behaviour (BT) of the new core, I'll compare the old and new configs.
If you like I'll send my full configs (old and new) to you directly via email as far as the new configuration is done.

[spiralvoice]

[fabtar]

OK

[fabtar]

Step 2, I have teste with new configs and mldonkey runs perfectly!! there is no CPU-problem!

Tomorrow I'll inspect old and new configs looking for differences, and I'll look for the bug-trigger

[spiralvoice]

[fabtar]

Pong, excuse me for the delay.
I have too much at job in these days, this evening I'll compare and inspect the settings.
I'll try to do this this eaving.