bugmldonkey, a multi-networks file-sharing client - Bugs: bug #3761, FT not respecting max sources per...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #3761: FT not respecting max sources per file settings

Submitter:  None
Submitted:  Mon 26 May 2003 08:07:27 PM UTC
   
 
Category:  Fasttrack-Plugin Severity:  1 - Wish
Item Group:  Memory leak Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  2.5.3 Release:  release-2-5
Operating System:  Linux Binaries Origin:  CVS / Self compiled
CPU type:  None

Tue 10 Aug 2004 06:42:47 PM UTC, comment #4: 

Changing severity to 1 because this bug might be solved in current CVS release.

spiralvoice <spiralvoice>
Group administrator
Tue 10 Aug 2004 02:53:10 PM UTC, comment #3: 

Please try CVS 2-5-27 and report if the bugs is solved

spiralvoice <spiralvoice>
Group administrator
Sat 23 Aug 2003 12:28:27 PM UTC, comment #2: 

on further inspection max_sources_per_file is a donkey option not involved in the FT code - but we do need an option for max sources per file on all networks. The FT code does limit the number of active sources to nranges - but nranges may be VERY large, and there is no maximum!

Anonymous
Sat 23 Aug 2003 12:04:05 PM UTC, comment #1: 

I am seeing this same thing. For a time I thought it might be sources not stopping the download when they get to the end of a range, but it goes back to more overhead than download too fast for that.
I'm running 2.5-3 stable.

Anonymous
Mon 26 May 2003 08:07:27 PM UTC, original submission:  

Since yesterday, when I first tried 2-5 I suffer from mlnet taking large amounts of ram, often more than 450 MB (on a 368 MB ram machine) and I tried to track it down.

I guess now I accidently found whats causing the problem.
I added 7 FT files to my DL queue and each of the Files at least takes 900 sources (some about 3600 sources each) and my max_sources_per_file is set to 100 (which is respected by edonkey/overnet files).

With about 8000 sources for just 3 files 2 thinks are explained to me.
a) the high memusage
b) the large overhead I see atm after a few minutes of mlnet runningtime (line loaded with 85KB/s downtraffic while only 15kb are actually for the downloads), at mlnet starts its more like 40kb for dl, 5kb overhead.

But if mlnet really tries to connect that many sources periodically it surely will generate large overhead.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 7 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-10-30 spiralvoice StatusNone Fixed
    Open/ClosedOpen Closed
2004-08-10 spiralvoice Severity4 - Important 1 - Wish
2004-03-16 spiralvoice Dependencies- bugs # is dependent
2004-03-02 spiralvoice CategoryCore Fasttrack-Plugin
    ReleaseNone 2.5.3
2003-12-02 spiralvoice Severity3 - Normal 4 - Important

Back to the top

Powered by Savane 3.13-4b48.
Corresponding source code