Speedup UDP packet pusher

[jogger]

Since last year this thread consumes most CPU. Maxes out a single core on 8 core ARM. It turns out that it runs a tight loop getNextVolley() where it loops over three other loops like finishMessage().

Much CPU is spent in a ridiculous debug function timestamp() that calls now() for a function result that is discarded when not debugging. I suggest pulling the log check out of this function like everywhere else in i2p, if it is at all needed anymore.

I classify this one as a defect because it is a clear coding error.

Threw out timestamp() and went downtown to get some icecream. Got back and what? UDP packet pusher maxing out again. Fired up iptraf: >1.6MBps UDP at 70% CPU single core. I don´t have older figures but that´s near 100% improvement. Built 2000 tunnels within 100 minutes. WOW!

So it is then well worth doing the following:

• TODO combine finishMessages(), allocateSend(), and getNextDelay() so we don't iterate 3 times.

[Zlatin Balevsky]

Are you running latest from monotone? We removed a now() in a tight loop over all UDP peers times all pending messages just a few days ago.

Out of curiosity what is your SSU peer limit?

[Zlatin Balevsky]

I found it, you're talking about OutNetMessage::timestamp . Yeah that's a no-brainer.

[jogger]

Yeah that´s a nice one. No SSU peer limits. Did not yet install monotone. So I guess your other fix will be in 0.9.38. If it also affects UDP packet pusher, it should really fly.

[Zlatin Balevsky]

Yes that fix will be in 0.9.38. If you don't want to install monotone, we have a mirror on github here ​https://github.com/i2p/i2p.i2p which is updated about every 30 minutes.

[zzz]

The change from comment 1 is a70923b917f355b3d6bd0a3e398a3cbdfcaf51a7 and will be in 0.9.38.
The timestamp change from comment 2 we can do for 0.9.39.
The TODO from the OP isn't easy or we would have done it already, but we can take a look during the 0.9.39 cycle.

[jogger]

Checked 0.9.38: Together with zab´s patch comment 2 is good for 1MBps UDP in and out each on ARM32 when running without the clock improvement patch.

[zzz]

Comment 2, which is the first part of the OP, in 314e17ccdebe2a1349e0ce205526f4d0698f29c9 to be 0.9.37-7.
Leaving ticket open for investigating the last part of the OP.