i2p.www/www.i2p2/pages/status-2006-01-03.html

{% extends "_layout.html" %}
{% block title %}I2P Status Notes for 2006-01-03{% endblock %}
{% block content %}<h3>I2P Status Notes for 2006-01-03</h3>
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi y'all, happy new year!  Lets jump back into our weekly status
notes after a week without them -

* Index
1) Net status and 0.6.1.8
2) Load testing results and peer profiling
3) 2005 review / 2006 preview / ???

* 1) Net status and 0.6.1.8

The other week we pushed out 0.6.1.8 and reports from the field are
that zzz's modifications have helped out a bunch, and things seem
fairly stable on the net, even with the substantially increased
network traffic as of late (the mean seems to have doubled in the
last month, according to stats.i2p).  I2PSnark seems to be working
out fairly well too - while we've run into a few snags, we've
tracked down and fixed most of them in subsequent builds.  There
hasn't been much feedback regarding Syndie's new blog interface, but
there has been a bit of an increase in Syndie traffic (partly due to
protocol's discovery of dust's rss/atom importer :)

* 2) Load testing results and peer profiling

For the past few weeks, I've been trying to pigeonhole our
throughput bottleneck.  The different software components are all
capable of pushing data at much higher rates than we typically see
for end to end comm over I2P, so I've been benchmarking them on the
live net with custom code to stress test them.  The first set of
tests, building one hop inbound tunnels through all routers in the
network and transmitting data through that tunnel ASAP showed quite
promising results, with routers handling rates that were in the
ballpark of what one would expect them to be capable of (e.g. most
only handling a lifetime average 4-16KBps, but others pushing 
20-120KBps through a single tunnel).  This test was a good baseline
for further exploration and showed that the tunnel processing itself
is capable of pushing much more than we typically see.

Attempts to replicate those results through live tunnels were not as
successful.  Or, perhaps you could say they were more successful,
since they showed throughput similar to what we currently see, which
meant that we were on to something.  Going back to the 1hop test
results, I modified the code to select peers that I manually
identified as fast and reran the load tests through live tunnels
with this &quot;cheating&quot; peer selection, and while it did not get up to
the 120KBps mark, it did show a reasonable improvement.

Unfortunately, asking people to manually select their peers has
serious problems for both anonymity and, well, usability, but armed
with the load test data, there seems to be a way out.  For the last
few days I've been testing out a new method of profiling peers for
their speed - essentially monitoring their peak sustained
throughput, rather than their recent latency.  Naive implementations
have been quite successful, and while it hasn't picked exactly the
peers I would have manually, its done a pretty good job.  There are
still some kinks to work out with it though, such as making sure we
are able to promote exploratory tunnels to the fast tier, but I'm
trying out some experiments on that front currently.

Overall, I think we're approaching the end of this throughput
excursion, as we're squeezing against the smallest bottleneck and
making it wider.  I'm sure we'll run into the next soon enough, and
this is definitely not going to get us regular internet speeds, but
it should help.

* 3) 2005 review / 2006 preview / ???

Saying 2005 broke a lot of ground is a bit of an understatement -
we've improved I2P numerous ways in the 25 releases last year,
grew the network 5-fold, deployed several new client applications
(Syndie, I2Phex, I2PSnark, I2PRufus), migrated to postman's and
cervantes' new irc2p IRC network, and saw some useful eepsites
bloom (such as zzz's stats.i2p, orion's orion.i2p, and tino's proxy
and monitoring services, just to name a few).  The community has
also matured a bit more, in no small part thanks to the support
efforts of Complication and others on the forum and in the channels,
and the quality and diversity of bug reports from all sectors have
improved substantially.  The continued financial support of those
within the community has been impressive, and while it isn't yet at
the level necessary for entirely sustainable development, we do have
a buffer that can keep me fed through the winter.

To all who have been involved in this past year, either technically,
socially, or financially, thanks for your help!

2006 is going to be a big year for us, with 0.6.2 coming this
winter, slating our 1.0 release sometime in the spring or summer,
with 2.0 in the fall, if not earlier.  This is the year that we'll
see what we can do, and work in the application layer will be even
more critical than before.  So if you've got some ideas, now is the
time to get cracking :)

Anyway, our weekly status meeting is coming up in a few minutes, so
if there's something you want to discuss further, swing on by #i2p
in the usual locations [1] and say hey!

=jr
[1] <a  rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=952">http://forum.i2p.net/viewtopic.php?t=952</a>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDutNSWYfZ3rPnHH0RAmRfAKCGo583h3DD2Cfw2J+1ueooDSrVmACeJuNh
PEKzFOKsWV54No3PoPYsd2c=
=iME3
-----END PGP SIGNATURE-----


</pre>
{% endblock %}