patchmldonkey, a multi-networks file-sharing client - Patches: patch #4374, fix "max_hard_download_rate...

 
 

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

patch #4374: fix "max_hard_download_rate has to be doubled"

Submitted by:  spiralvoice <spiralvoice>
Submitted on:  Mon 29 Aug 2005 09:56:50 PM UTC  
 
Category:  Bug fixes Priority:  5 - Normal
Status:  Done Assigned to:  spiralvoice <spiralvoice>
Open/Closed:  Closed

( Jump to the original submission)

Wed 14 Sep 2005 02:36:25 PM UTC, comment #15: 

The bug I reported in comment #11 is fixed with the new version of this patch.
Applied to CVS 2005/09/14

spiralvoice <spiralvoice>
Project AdministratorIn charge of this item.
Wed 31 Aug 2005 10:58:42 PM UTC, comment #14: 

After reading bandwidth controlers code, I suspect that lines 1701 and 1702 or tcpBufferedSocket.ml:

                     );
-                    bc.remaining_bytes <- bc.remaining_bytes -
-                    t.nread + old_nread;
                     bc.nconnections <- bc.nconnections - t.read_power

Are no longer needed, because can_read_handler already updates remaining_bytes counters.

Maybe b8_bavard or Simon, that know that code better than me, could confirm ?

(New -only slightly tested- patch attached.)

pango <mlpango>
Project Member
Tue 30 Aug 2005 08:08:04 PM UTC, comment #13: 

Ok, so I probably fixed a bug, but not that bug...

pango <mlpango>
Project Member
Tue 30 Aug 2005 06:27:42 PM UTC, comment #12: 

The "network_must_update" calls must come after count_download / upload to update to the new stats.  This patch currently breaks this.

z <zet>
Project Member
Tue 30 Aug 2005 06:15:07 PM UTC, comment #11: 

Just tried a local BT download with MLDonkey from Azureus.
MLDonkey compiled with CVS 2005/08/29 + this patch.

But it seems not to work properly:

max_download_rate - real_download_rate

50 - 32
80 - 47
100 - 54
150 - 80

real_download_rate was reported by Sancho, MLDonkey HTML and Azureus.

spiralvoice <spiralvoice>
Project AdministratorIn charge of this item.
Mon 29 Aug 2005 09:56:50 PM UTC, comment #10: 

This item has been reassigned from the project mldonkey, a multi-networks file-sharing client bugs tracker to your tracker.

The original report is still available at bugs #10062

Following are the information included in the original report:

[field #0]                  Item ID: 10062
[field #1]                 Group ID: 1409
[field #2]              Open/Closed: Open
[field #3]                 Severity: 3 - Normal
[field #4]                  Privacy: Public
[field #5]                 Category: Core
[field #6]             Submitted by: spiralvoice
[field #7]              Assigned to: spiralvoice
[field #8]             Submitted on: jeu 19.08.2004 à 12:49
[field #9]                  Summary: max_hard_download_rate has to be doubled
[field #10]      Original Submission: This bug is still there:
"2004/05/05: Fabrice (version 2.5.21 = 2.6pre3, tag release-2-5-21)
   - For some reason, download seems to be limited to max_hard_download_rate/2.
       Try to increase this option until a fix is found. "
http://mldonkey.berlios.de/modules.php?name=Forums&file=viewtopic&p=14447#14447
[field #11]                Closed on: lun 29.08.2005 à 02:47
[field #12]               Item Group: Program malfunction
[field #13]                   Status: Ready For Test
[field #14]        Component Version: None
[field #15]         Platform Version: None
[field #16]          Reproducibility: None
[field #17]               Size (loc): None
[field #18]            Fixed Release: None
[field #19]          Planned Release: None
[field #20]                   Effort: 0.00
[field #24]                 Priority: 5 - Normal
[field #27]         Percent Complete: 0%
[field #29]                  Release: 2.6.3
[field #54]          Binaries Origin: CVS / Self compiled
[field #55]                 CPU type: None
[field #56]                      CPU: None
[field #57]     Custom Select Box #4: None
[field #58]     Custom Select Box #5: None
[field #59]     Custom Select Box #6: None
[field #60]     Custom Select Box #7: None
[field #61]     Custom Select Box #8: None
[field #62]     Custom Select Box #9: None
[field #63]    Custom Select Box #10: None

pango <mlpango>
Project Member
Mon 29 Aug 2005 09:44:09 PM UTC, comment #9: 

Changed bug status.

pango <mlpango>
Project Member
Mon 29 Aug 2005 12:47:51 AM UTC, comment #8: 

Updated patch for Bittorrent upload.

pango <mlpango>
Project Member
Mon 29 Aug 2005 12:37:29 AM UTC, comment #7: 

Bittorrent upload probably has exactly the same bug
(in BTClients.iter_upload, client_uploaded is incremented, then count_upload is called that also increments client_uploaded)...

pango <mlpango>
Project Member
Mon 29 Aug 2005 12:09:02 AM UTC, comment #6: 

I think I've found the bug.

Code was added to donkey and bittorrent supports to increment client_downloaded fields using Swarmer transfer accounting.

Problem is, count_download already updates client_downloaded, so transfers end up being counted twice.

(Untested) patch attached.

pango <mlpango>
Project Member
Fri 10 Jun 2005 12:31:43 AM UTC, comment #5: 

According to https://savannah.nongnu.org/patch/?func=detailitem&item_id=4046#comment1
it works now. As it is fixed I will close this bug.
In the code I left a "TODO" note for later work, no need to have
an open bug report for it now.

spiralvoice <spiralvoice>
Project AdministratorIn charge of this item.
Thu 26 May 2005 10:28:06 AM UTC, comment #4: 
spiralvoice <spiralvoice>
Project AdministratorIn charge of this item.
Wed 04 May 2005 07:01:09 AM UTC, comment #3: 

a small comment from the 2.5.30-15 version, seen on the donkey network:
when a source is uploading us data for a file, the downloaded part from the source is the double of the downloaded part of the file.
You can observe that from the GTK2 GUI:
- add a new file
- expand the file in the GUI to see the sources
- wait for the first source to upload to us
- watch carefully the 'Downloaded' column. The file downloaded size is exactly half of the data downloaded from the source.

su_blanc <su_blanc>
Project Member
Wed 13 Apr 2005 09:10:36 AM UTC, comment #2: 

that patch doesnt actually fix the bug it just hides it

Anonymous
Tue 12 Apr 2005 11:12:03 AM UTC, comment #1: 

Please try the attached patch.

spiralvoice <spiralvoice>
Project AdministratorIn charge of this item.
Mon 29 Aug 2005 09:56:50 PM UTC, original submission:  

This bug is still there:
"2004/05/05: Fabrice (version 2.5.21 = 2.6pre3, tag release-2-5-21)
   - For some reason, download seems to be limited to max_hard_download_rate/2.
       Try to increase this option until a fix is found. "
http://mldonkey.berlios.de/modules.php?name=Forums&file=viewtopic&p=14447#14447

spiralvoice <spiralvoice>
Project AdministratorIn charge of this item.

 

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

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

Only logged-in users can vote.

 

 

 

Follow 10 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-09-14 spiralvoice StatusPostponed => Done
    Open/ClosedOpen => Closed
2005-09-14 spiralvoice Attached File#5108 => Removed
2005-08-31 mlpango Attached File- => Added fix_doubled_download_rates.patch, #5119
2005-08-30 mlpango StatusReady For Test => Postponed
2005-08-30 spiralvoice SummaryReassigned item: max_hard_download_rate has to be doubled => fix "max_hard_download_rate has to be doubled"
2005-08-30 mlpango CategoryNone => Bug fixes
    StatusNone => Ready For Test
    Assigned toNone => spiralvoice
2005-08-29 mlpango Reassign itemFrom group mldonkey, a multi-networks file-sharing client, bugs tracker => To group mldonkey, a multi-networks file-sharing client, patch tracker

Back to the top


Powered by Savane 3.5