patchmldonkey, a multi-networks file-sharing client - Patches: patch #4417, BT: Improve BT upload speed

 
 

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

patch #4417: BT: Improve BT upload speed

Submitter:  spiralvoice <spiralvoice>
Submitted:  Wed 14 Sep 2005 03:12:17 PM UTC
   
 
Category:  Bug fixes Priority:  9 - Immediate
Status:  Done Assigned to:  None
Open/Closed:  Closed

Wed 14 Sep 2005 08:02:43 PM UTC, comment #2: 

Applied 2005/09/14

spiralvoice <spiralvoice>
Group administrator
Wed 14 Sep 2005 03:40:08 PM UTC, comment #1: 

Since BT support needs to write packets much bigger than what the upload scheduler usually allows in one turn, it uses private accumulators to gather "upload credits".
The problem probably comes from the fact that private accumulators are not bounded, and increased unconditionally.
Maybe they should be checked against the available buffer space:
(untested)

--- src/networks/bittorrent/bTClients.ml        8 Sep 2005 12:26:01 -0000      1.50
+++ src/networks/bittorrent/bTClients.ml        14 Sep 2005 15:31:24 -0000
@@ -1501,9 +1492,12 @@
       match c.client_upload_requests with
         [] -> ()
       | _ :: tail ->
-          CommonUploads.consume_bandwidth allowed;
-          c.client_allowed_to_write <-
-            c.client_allowed_to_write ++ (Int64.of_int allowed);
+         let new_allowed_to_write =
+           c.client_allowed_to_write ++ (Int64.of_int allowed) in
+         if allowed > 0 && CommonUploads.can_write_len sock (Int64.to_int new_allowed_to_write) then begin
+            CommonUploads.consume_bandwidth allowed;
+            c.client_allowed_to_write <- new_allowed_to_write;
+         end;
           iter_upload sock c
   )

pango <mlpango>
Group Member
Wed 14 Sep 2005 03:12:17 PM UTC, original submission:  

Changing max_hard_upload_rate to 0 produces this:
[TCP_BS]: BUFFER OVERFLOW 985393+16397> 1000000 MESSAGE: [(0)(0)(64)(9)(7)(0)(0)(0)(62)(0)(3)(192)(0)(226)(21)(182)(82)(23)(76)(90)...]
[TCP_BS]: BUFFER OVERFLOW 985393+16397> 1000000 MESSAGE: [(0)(0)(64)(9)(7)(0)(0)(0)(40)(0)(0)(0)(0)(221)(244)(92)(59)(86)(129)(43)...]

and upload drops to zero. Raising client_buffer_size from
500000
to
5000000 solves this.

Also apply one line of code from pangos patch #4337
https://savannah.nongnu.org/patch/index.php?func=detailitem&item_id=4337#comment4

spiralvoice <spiralvoice>
Group administrator

 

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

Attached Files
file #9289:  4417.patch added by spiralvoice (1KiB - application/octet-stream - updated patch with pangos proposal)
file #9288:  bt_upload.patch added by spiralvoice (1KiB - application/octet-stream)

 

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
2005-09-14 spiralvoice StatusNone Done
    Open/ClosedOpen Closed
2005-09-14 spiralvoice Attached File- Added 4417.patch, #5173
2005-09-14 spiralvoice Attached File- Added bt_upload.patch, #5172

Back to the top

Powered by Savane 3.13-4b48.
Corresponding source code