2.8 KiB
Opened 20 months ago
Last modified 20 months ago
#2617newenhancement
Speedup outbound I2CP
Reported by:joggerOwned by:zzz Priority: major Milestone: undecided Component: router/general Version: 0.9.42 Keywords:
Cc:
Parent Tickets:
Sensitive: no
Description
While working on the UDP transport, I noticed that messages are trickling in slowly all the time, making the router work packet-at-a-time. For inbound this is unavoidable, given the speed of todays CPUs. However for Tunnel GW Pumper zzz claimed there was batching. Can´t work on inbound but reasonable for outbound.
Running with #2432 comment 11 I saw I2CP reader spending 40% more CPU creating a message than the pump() needed for it. Thus the pumper queue could never get loaded which would need at least 3 messages for batching to work.
One could put message creation into a thread pool to parallize (the use case being 16 consecutive messages for a bittorrent chunk). However there has been already a solution in ClientMessagePool?:
if (true) // blocks the I2CP reader for a nontrivial period of time
j.runJob();
else
_context.jobQueue().addJob(j);
Change that to false and we have a valid use case for multiple job queue runners. Checked that in my test bed and number of invocations for Tunnel GW Pumper went down. Further checked that those jobs ran short enough not to be preempted on 1.8 GHz ARM32 (in which case # of threads must be limited to # CPUs).
So I came up with 16 job queue runners for the above use case together with #2432 comment 11. Result in my test bed:
-
Tunnel GW Pumper runs 20-30% less frequently than I2CP Reader, so batching works
-
As message creation is distributed across several threads there is no more preemption which occurs frequently for I2CP Reader looping over input with current code.
To make our torrent friends really happy one could as a followup tweak the UDP transport with a minimum send window of 16*1033 bytes and MAX_ALLOCATE_SEND = 16.