{% extends "_layout.html" %} {% block title %}I2P Development Meeting 178{% endblock %} {% block content %}

I2P dev meeting, May 2, 2006

16:09 < jrandom> 0) hi

16:09 < jrandom> 1) Net status

16:09 < jrandom> 2) Syndie status

16:09 < jrandom> 3) ???

16:09 < jrandom> 0) hi

16:09 * jrandom waves

16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001285.html

16:11 < jrandom> ok, while y'all read through that exciting mail, lets jump on in to 1) Net status

16:13 < jrandom> so far, it seems the whole congestion collapse issue is fixed, yand tunnel creation rates are doing pretty well. still, there are issues left to be sorted out

16:14 < jrandom> the previously discussed cyclic behavior (often running on 10-12 minute intervals) is still in place,causing rejections inversely. there's a new fix to the code as of -1 that should get rid of that though

16:15 < jrandom> (namely, randomize the tunnel expirations /correctly/, unlike the broken randomization before)

16:16 < jrandom> that, plus the improved ssu and tunnel test scheduling should help, but to what dgree, i'm not entirely sure yet

16:17 < jrandom> ok, thats about all i have on that at the moment. anyone have any questions/comments/concerns on 1) Net status?

16:18 < green> humm, max bw limits are never reached and this is really far from previous

16:18 < green> like in 1é-7

16:18 < green> s/1é-7/.12-7

16:18 < jrandom> how is your bw share percentage set? thats now a very powerful control

16:19 < green> 80%

16:19 < green> but only about 40% of total bw is used

16:20 < green> this is just a "do nothing router" :P

16:20 < jrandom> hmm, how often does your bw spike up to 80%, and do you often reject tunnel requests (http://localhost:7657/oldstats.jsp#tunnel.reject.30 and tunnel.reject.*)

16:21 < jrandom> the periodicity seen in tunnel requests often causes people to detect overload when it isn't really there

16:21 < jrandom> (because routers have excess capacity at other times, just not when they're being spiked)

16:22 < green> tunnel.reject.30 is very flat like 1,00 over 14 025,00 events

16:22 < jrandom> oh, sorry, its the event count theselves for that stat thats key - you've rejected more than 14,000 tunnel requests due to bandwidth overload

16:23 < jrandom> (the "value" for that stat is how many tunnels were rejected at the event, and thats always 1, since an event is caused by a message)

16:27 < jrandom> ok, if there's nothing else on 1) Net status, lets slide on over to 2) Syndie status

16:27 < jrandom> I don't have much more to add to whats in the email regarding syndie, just wanted to give an update

16:28 < jrandom> ok, as such, unless there's something someone wants to bring up wrt syndie, lets jump on to ol' faithful, 3) ???

16:28 < jrandom> anyone have anything else they want to bring up for the meeting?

16:31 * tethra would like to say "thanks" (again) for .17, as it has been muchos improvement

16:33 < jrandom> glad to help, and there's more stuff on the way

16:33 < jrandom> ok, but if there's nothing else for toay's meeting...

16:33 * jrandom winds up

16:33 * jrandom *baf*s the meeting closed

{% endblock %}