From d2148516462ad36ea49571a5ccef90f6766fec4e Mon Sep 17 00:00:00 2001 From: jrandom Date: Mon, 19 Jul 2004 15:59:10 +0000 Subject: [PATCH] updated to include which tweaks were already implemented --- pages/performance.html | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/pages/performance.html b/pages/performance.html index f24c6624..008ae3d9 100644 --- a/pages/performance.html +++ b/pages/performance.html @@ -7,16 +7,16 @@ performance of I2P - some of the following are CPU related, others bandwidth related, and others still are protocol related. However, all of those dimensions affect the latency, throughput, and percieved performance of the network, as they reduce contention for scarce resources. This list is of course -not comprehensive, but it does cover the major ones that I see.

+not comprehensive, but it does cover the major ones that are seen.

-

Native math

+

Native math [implemented]

When I last profiled the I2P code, the vast majority of time was spent within one function: java.math.BigInteger's modPow. Rather than try to tune this method, we'll call out to GNU MP - an insanely fast math library (with tuned assembler for many architectures). (Editor: see -NativeBigInteger for faster public key cryptography)

+NativeBigInteger for faster public key cryptography)

ugha and duck are working on the C/JNI glue code, and the existing java code is already deployed with hooks for that whenever its ready. Preliminary results look fantastic - running the router with the native GMP modPow is providing over @@ -24,7 +24,7 @@ a 800% speedup in encryption performance, and the load was cut in half. This was just on one user's machine, and things are nowhere near ready for packaging and deployment, yet.

-

Garlic wrapping a "reply" LeaseSet

+

Garlic wrapping a "reply" LeaseSet [implemented]

This algorithm tweak will only be relevent for applications that want their peers to reply to them (though that includes everything that uses I2PTunnel or mihi's ministreaming lib):

@@ -91,7 +91,7 @@ doesn't pass our test within 60 seconds "dead"?

as tuneable parameters to allow for more appropriate tradeoffs between bandwidth, latency, and CPU usage.

-

More efficient TCP rejection

+

More efficient TCP rejection [implemented]

At the moment, all TCP connections do all of their peer validation after going through the full (expensive) Diffie-Hellman handshaking to negotiate a private session key. This means that if someone's clock is really wrong, or @@ -103,7 +103,7 @@ verification/validation within the encryption boundary, we'll want to update the protocol to do some of it first, so that we can reject them cleanly without wasting much CPU or other resources.

-

Adjust the tunnel testing

+

Adjust the tunnel testing [implemented]

Rather than going with the fairly random scheme we have now, we should use a more context aware algorithm for testing tunnels. e.g. if we already know its passing valid data correctly, there's no need to test it, while if we haven't @@ -111,7 +111,7 @@ seen any data through it recently, perhaps its worthwhile to throw some data its way. This will reduce the tunnel contetion due to excess messages, as well as improve the speed at which we detect - and address - failing tunnels.

-

Compress some data structures

+

Compress some data structures [implemented]

The I2NP messages and the data they contain is already defined in a fairly compact structure, though one attribute of the RouterInfo structure is not - "options" is a plain ASCII name = value mapping. Right now, we're filling it