111 lines
5.2 KiB
HTML
111 lines
5.2 KiB
HTML
<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 "cheating" 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>
|