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

Submitted by:  None
Submitted on:  Mon 26 May 2003 08:07:27 PM UTC  
 
Category: Fasttrack-PluginSeverity: 1 - Wish
Item Group: Memory leakStatus: Fixed
Assigned to: NoneOpen/Closed: Closed
Release: release-2-5Release: 2.5.3
Operating System: LinuxBinaries 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>
Project 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>
Project 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

 

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 7 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 30 Oct 2004 11:15:37 AM UTCspiralvoiceStatusNone=>Fixed
  Open/ClosedOpen=>Closed
Tue 10 Aug 2004 06:42:47 PM UTCspiralvoiceSeverity4 - Important=>1 - Wish
Tue 16 Mar 2004 12:27:28 AM UTCspiralvoiceDependencies-=>bugs # is dependent
Tue 02 Mar 2004 08:25:47 PM UTCspiralvoiceCategoryCore=>Fasttrack-Plugin
  ReleaseNone=>2.5.3
Tue 02 Dec 2003 09:01:55 PM UTCspiralvoiceSeverity3 - Normal=>4 - Important

Back to the top


Powered by Savane 3.1-cleanup1