I2P dev meeting, May 16, 2006

Quick recap

  • Present:

bar, cervantes, Complication, Pi,

IRC 完整日志

< cervantes>  moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html
< cervantes>  0) hi
< cervantes>  1) jrandom's not here
< cervantes>  2) ???
< cervantes>  0) hi
< cervantes>  hi
< cervantes>  moving on to 1)
< cervantes>  jrandom isn't here today, but he'll give us a status update tomorrow
< cervantes>  2) ???
< cervantes>  does anyone have anything else to add to the meeting?
< bar>  i have a question
< cervantes>  in that case...
* cervantes winds up
* cervantes stops winding
< Complication>  Aha, a question...
< bar>  the PRNG fix in cvs, will that improve the general performace or is it related to something else?
< cervantes>  it's uncertain what consequences it might have in general
< Complication>  I'm personally not aware of its total impact, but it does involve at least two behaviours I'm aware of:
< cervantes>  but it specifically fixes a symptom with i2ptunnel
* cervantes lets complication decomplicate 
< Complication>  tunnel length randomization and IRC server choice (more generically, random selection from a list of I2PTunnel destinations)
< Complication>  Tunnel length randomization probably has a significant effect on overall network health, since it allows clients who are permitted to compromise on tunnel length to actually do that
< Complication>  So they won't be holding breath and building 2-hop tunnels, but also try some 1-hop tunnels
< Complication>  (which on hard times, are much easier to get)
< cervantes>  also irc connectivity might improve once it's  rolled out. Basically freshcoffee was never getting any client connections because it was second in the list - so with the next release the load should be evenly distributed between both servers
< bar>  so the bug made people always go for the longer tunnel lengths if available?
< Complication>  If I understood right, every randomization with smallish integers (e.g. pick 0 or 1) was affected
< Complication>  I *think* randomizations with bigger integers (e.g. pick an integer between 0 and 100) were less affected
< Complication>  if you're interested, you should probably ask jranom for details when he's back
< Complication>  I may get the details wrong.
< bar>  i see, thanks. good catch
< Complication>  well, cervantes came here and started complaining about not getting any overload ;P
< cervantes>  that was my understanding of it too
< cervantes>  see...you don't get anything in life if you don't grumble :)
< cervantes>  do any folk have other questions or topics for the meeting?
< fox>  < duck>  yes
< Pi>  a question about general net health : i see more and more clients get left behind i2p-version wise (2 still using and so on). won't these clients make monitoring effects of changes to the core more and more harder? (as "fewer" seem to want to update)
< fox>  * duck repeats above
* w423412323 suggests a topic change along that line. ;)
< fox>  < duck>  I was wondering, I have seen some funky tuning commits on the cvs mailinglist. are those more experiments? are they based on observations? are they premature?
< Complication>  Pi: as long as they aren't present in big numbers, they shouldn't make a big difference
< Pi>  70 of 300 clients using non- according to my netdb now 
< Complication>  It's a game of numbers and capacity - if either most routers, or additionally the highest-capacity routers are reasonably updated, some people forgetting that they installed I2P shouldn't matter :)
< cervantes>  Pi: if the older routers misbehave then the network _should_ adapt and reduce traffice being router via them
< cervantes>  *being routed
< cervantes>  Complication: did you see duck's question? 
< Pi>  and a question about a stat on the i2p-console which appeared some time ago : what does handle backlog mean?
< Complication>  duck: would you mean the tunnel throttle adjustments? They're tuning in the sense that they won't bring much inherently new, but they should be fairly well-tested now (e.g. they probably won't byte)
< Complication>  But they might byte a little, if you run an exotic setup which is completely outside the parameters I could think of
< fox>  < duck>  Complication: I was wondering if '2' instead of '3' thingies really mattered that much
< fox>  < duck>  but it seemed that the random problem might have been a big baddy
< fox>  < duck>  (though the relative impact of that towards network unhealth depends on when it was introduced)
< cervantes>  Pi: handle backlog is the number of pending inbound tunnel join requests (quoted from the changelog)
< Complication>  If you mean the random nextInteger() problem, and effect on tunnel length randomization, I feel it would have significant effect
< Complication>  The cost difference of building a 1-hop and 2-hop tunnel is pretty significant
< Pi>  thx, cervantes :)
< fox>  < duck>  when was it introduced?
< Complication>  duck: I think it was introduced with some switchovers to the Fortuna generator, or some modification therein
< fox>  < duck>  ok; thanks a lot for your input
< Complication>  Let me check the cvsweb for more detail...
< cervantes>  Pi: I believe there's code in place now that drops inbound tunnel requests if the queue fills up (to help reduce cpu load)
< Complication>  Pi: yes, that should be the visible indicator of another parameter used for deciding "do we have enough capacity to participate in another tunnel?"
< cervantes>  duck: I certainly experience a large change in router behaviour since the fix was introduced. - not all good I have to say :)
< Complication>  big handle backlog == congestion, no point in trying to join other people's tunnels
< cervantes>  had a load average of 14 and 12000 participating tunnels the other day
< Complication>  Handle backlog seems important particularly on high-capacity routers (referring to what cervantes saw)
< Complication>  Low capacity routers generally throttle their tunnel acceptance for bandwidth reasons
< Complication>  (or tunnel test time reasons, to be correct)
< Complication>  (or at least, to try that)
< cervantes>  wow we've managed half an hour....
< Complication>  Indeed :D
< cervantes>  anyone want to bring anything else to the table?
< cervantes>  in that case...
* cervantes winds up
* cervantes *baffs* the meeting closed
< fox>  < duck>  thx for taking care of the meeting
< cervantes>  heh I was expecting to baf it closed before anything said anything....but bar ruined that plan :)