bugmldonkey, a multi-networks file-sharing client - Bugs: bug #14468, max_hard_upload_rate erratic...

 
 

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

bug #14468: max_hard_upload_rate erratic behavior (load sensitive)

Submitter:  Jonathan Thibault <finboyslick>
Submitted:  Thu 08 Sep 2005 05:05:14 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Program malfunction Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  2.6.3 Release: 
Operating System:  Linux Binaries Origin:  CVS / Self compiled
CPU type:  Intel x86

Jump to the original submission

Fri 23 Jun 2006 07:24:47 PM UTC, comment #8: 

Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project: http://download.berlios.de/pub/mldonkey/spiralvoice/

spiralvoice <spiralvoice>
Group administrator
Mon 23 Jan 2006 12:26:21 AM UTC, comment #7: 

Fixed by patch #4581, applied 2005/10/31?

spiralvoice <spiralvoice>
Group administrator
Tue 13 Sep 2005 12:43:04 AM UTC, comment #6: 

Ok, I think I've found a bug in bittorrent upload handler (I don't use bittorrent, so I missed it before).
Since this support tries to send data in bigger chunks than what the upload scheduler usually allows in one turn, it maintains its own credit accumulators internally (one per connection).
However, main credits are decremented twice, once when they're transfered to private accumulators, and once when data is sent.

The quick fix is to remove the call to consume_bandwidth when data is sent.

That's only a quick fix however. Keeping a private accumulator per client means that the bittorrent support can generate big overshots. And with a single accumulator, it will be difficult to be fair within clients of the same network, since the upload scheduler forces a client rotation before each call. Maybe each network support should have its own Fifo of upload slots... (?)

pango <mlpango>
Group Member
Sun 11 Sep 2005 01:11:12 AM UTC, comment #5: 

And very closely to half the value, so it could be related to bug fixed by patch #4374, but I'm not sure.
Also, "I get exactly the requested upload rate", so the reason is probably among the differences I already mentionned.

pango <mlpango>
Group Member
Sat 10 Sep 2005 08:26:34 PM UTC, comment #4: 

My problem isn't that it goes over the rate though, it is that it never reaches it.  It typically sticks to about half.

Jonathan Thibault <finboyslick>
Sat 10 Sep 2005 07:07:15 AM UTC, comment #3: 

Strange, I get exactly the requested upload rate, and it behave much better under load (rewriting bandwidth controlers to use the same kind of enhancements could help further). By design it can temporarily go over requested rate if it couldn't previously reach it, but it shouldn't last 1 minute like on your graph, more like a few seconds.

  • Same kind of CPU power (PIII 500)
  • slower link (512/128 ADSL => 16 kB/s upload)
  • No bittorrent traffic, only donkey/Overnet/Kad
  • Linux kernel 2.6.10 with preemption enabled
  • I also use other patches like patch #4374, but the upload scheduler should also work with just the spiralvoice's current workaround.


pango <mlpango>
Group Member
Fri 09 Sep 2005 06:17:51 PM UTC, comment #2: 

I am testing it right now.  Under no load, it is actually worse than 'unpatched' 2.6.4, my average up rate being 25-30k/sec.  Under load, it still drops to 5-10k/sec.  The main difference I noticed is that if I 'reset' max_hard_upload_rate (0, then 60), I will no longer get the nice flat 'normal behavior.  Instead, it climbs up to saturate my link (while at 0) and then drops back down to about half of the setting (30k/s while set at 60).  I guess we fixed a bit of the mystery: I don't get a 'normal' state that mysteriously disappears now, it's 'misbehaving' all the way ;)

I included a screenshot that shows bandwidth useage after startup, then under load (the pit), when max_hard_upload_rate=0 (the peak), then when it is set back to 60.

Jonathan Thibault <finboyslick>
Fri 09 Sep 2005 08:56:09 AM UTC, comment #1: 

Have you tried patch #4337 ?

pango <mlpango>
Group Member
Thu 08 Sep 2005 05:05:14 AM UTC, original submission:  

As discussed in the #mldonkey channel, mlnet seems to have a flaw with upload bandwidth throttling.  I've experimented and tested a lot and found out a few things:

It seems to be CPU related.  Though a bit underpowered (pIII 550), the box I use for mldonkey is almost exclusively dedicated to it.  If I reset the max_hard_upload_rate value, I will get 'normal' behavior for a while.  That is an upload rate that keeps very close to its limit.  How long normal behavior lasts seems to be closely related to the load on the machine.  If I start a compile job or anything processor intensive, the upload rate will significantly drop (from 60k/sec to as low as 5k/sec).

Even if I leave the box alone, upload rate will only remain stable (mosly flat graph) for so long, longer on more powerful machines (I tested an Athlon XP 1.7, it took about 30 minutes).  Once the upload rate starts behaving like that (spikey graph), it will not return to a stable rate until it is reset.  That is, max_hard_uload_rate = 0, then max_hard_upload_rate = 60.

From earlier discussions in #mldonley with Amorphous, it would appear that the behavior can be reproduced.  It would also confirm that the stronger the box, the longer it takes for the problem to manifest.

I've included a sancho screenshot of what happens when the only thing loading the box is mlnet itself.  (no GUI, etc.)

Jonathan Thibault <finboyslick>

 

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

Attached Files
file #3281:  example4.png added by finboyslick (70KiB - image/png - New behavior)
file #3464:  example3.png added by finboyslick (199KiB - image/png - Sancho stats screenshot.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-07-20 spiralvoice StatusNone Fixed
    Open/ClosedOpen Closed
2005-09-09 finboyslick Attached File- Added example4.png, #2940
2005-09-08 finboyslick Attached File- Added example3.png, #2931

Back to the top

Powered by Savane 3.13-4448.
Corresponding source code