78 lines
6.4 KiB
HTML
78 lines
6.4 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Development Meeting 171{% endblock %}
|
|
{% block content %}<h3>I2P dev meeting, March 7, 2006</h3>
|
|
<div class="irclog">
|
|
<p>15:08 < jrandom> 0) hi</p>
|
|
<p>15:08 < jrandom> 1) Net status</p>
|
|
<p>15:08 < jrandom> 2) ???</p>
|
|
<p>15:08 < jrandom> 0) hi</p>
|
|
<p>15:08 * jrandom waves</p>
|
|
<p>15:08 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001267.html</p>
|
|
<p>15:09 * jrandom gives y'all hours to read through that huge tome of notes</p>
|
|
<p>15:10 * Complication pretends not having noticed yet ;)</p>
|
|
<p>15:11 <+Complication> Hi :)</p>
|
|
<p>15:11 <+susi23> hi :)</p>
|
|
<p>15:12 < jrandom> well, might as well dig on in to 1) net status</p>
|
|
<p>15:12 < jrandom> The mail gives my general view of whats going on. how does that line up with what y'all are seeing?</p>
|
|
<p>15:13 <+Complication> Throttling fixes seem to have increased reliability, but really suppressed bandwidth</p>
|
|
<p>15:13 <+Complication> Just a second, digging for the graph</p>
|
|
<p>15:14 <+Complication> http://complication.i2p/files/bw-week.png</p>
|
|
<p>15:14 <+Complication> High stretches are on non-latest, low stretches on latest</p>
|
|
<p>15:15 <+Complication> Same limiter settings, possibly more lax on stricter (latest) versions</p>
|
|
<p>15:16 <+Complication> But it's not much of a problem, since it does transfer</p>
|
|
<p>15:16 < jrandom> cool, reduced bandwidth usage is appropriate as you approach your actual bandwidth limit</p>
|
|
<p>15:17 <+Complication> Most of time, it seems to bounce back before the "sustained bandwidth" limit</p>
|
|
<p>15:17 <+Complication> Never touches the burst limit</p>
|
|
<p>15:18 <+Complication> (which, in itself, is sensible - it's the bouncing back before the sustained limit which concerns me)</p>
|
|
<p>15:19 < bar> i'm seeing pretty much what Complication is seeing. my total bw consumption is just 50% of my max settings. it used to be ~80% pre 0.6.1.11</p>
|
|
<p>15:19 < jrandom> is 200kbps your limiter rate, w/ 300kbps burst?</p>
|
|
<p>15:20 < jrandom> (just wondering how much time it used to spend in the burst)</p>
|
|
<p>15:20 < jrandom> reduced bandwidth usage though is one of the aims of the recent changes</p>
|
|
<p>15:21 <+Complication> ~225 sustained, ~325 burst</p>
|
|
<p>15:21 <+Complication> Hey, I could have...</p>
|
|
<p>15:22 <+Complication> Have I *interpreted* it wrong?</p>
|
|
<p>15:23 <+Complication> Forget it, I'm a fool... did the math wrong, it's not nearly as bad :O</p>
|
|
<p>15:23 < jrandom> insufficient data :) it might be indicitive of a problem, but what you've described so far suggests things are behaving as desired</p>
|
|
<p>15:23 <+Complication> It's a bit on the conservative side, but not nearly as bad as I thought</p>
|
|
<p>15:24 <+Complication> According the Router Console (which measures in the same unit as the limiter) outbound total average is 2/3 of the sustained limit, and 1/2 of the burst limit</p>
|
|
<p>15:25 <+Complication> But inbound total average, I have to say, is only slightly above 1/3 sustained limit, and 1/4 burst limit</p>
|
|
<p>15:26 <+Complication> for example, assuming a sustained limit of 30, and a burst limit of 40, outbound would be 20 and inbound just above 10 (mostly due to lack of load)</p>
|
|
<p>15:26 < jrandom> cool</p>
|
|
<p>15:26 <+Complication> But the graph I misinterpreted, due to Kb/KB issues :O</p>
|
|
<p>15:27 * Complication wipes the graph from history</p>
|
|
<p>15:28 < jrandom> good eye though, definitely lemmie know when things sound funky</p>
|
|
<p>15:28 < jrandom> ok, anything else on 1) Net status?</p>
|
|
<p>15:28 < jrandom> if not, lets shimmy on over to 2) ???</p>
|
|
<p>15:28 < jrandom> anyone have anything else to discuss?</p>
|
|
<p>15:30 <+Complication> Well, there's been some jbigi testing, and apparently, someone got results which suggested the 64-bit version for Linux being slowish</p>
|
|
<p>15:31 <+Complication> They had it slower than pure Java, not sure if a measurement glitch or not :O</p>
|
|
<p>15:32 <+Complication> I couldn't repeat it</p>
|
|
<p>15:32 < jrandom> yeah, i wasn't sure exactly what .so they were using for the platform</p>
|
|
<p>15:32 <+Complication> Over here, it was about twice faster than pure Java</p>
|
|
<p>15:32 <+dust> my experiments with html as an additional message format in syndie is starting to work. my local 'sucker' can now retrieve web pages (with images) and store them as syndie posts</p>
|
|
<p>15:33 < jrandom> ah wikked dust </p>
|
|
<p>15:33 <+dust> no css tho</p>
|
|
<p>15:33 <+Complication> But people on 32-bit spoke of it being *way* faster then pure Java (like 10x or similar)</p>
|
|
<p>15:35 < bar> hmm.. Complication, could it be that the current amd64 .so is for 32-bit systems only, and he tested it on a 64-bit OS?</p>
|
|
<p>15:36 <+Complication> bar: could be, since I tested it too on a 64-bit OS :O</p>
|
|
<p>15:36 < jrandom> iirc the amd64 was built to work on pure64 debian</p>
|
|
<p>15:37 <+Complication> Either way, some people suggested that importing a fresher gmp might help</p>
|
|
<p>15:37 < bar> just a stab in the dark, i'm no wiz at these things</p>
|
|
<p>15:37 < jrandom> eh, we use 4.1.4</p>
|
|
<p>15:37 <+Complication> Especially after they've done their soon-to-come version jump</p>
|
|
<p>15:38 <+Complication> Since I'm no gmp specialist, I couldn't tell much about it</p>
|
|
<p>15:38 < jrandom> (and the upcoming optimizations in gmp aren't likely to have substantial improvement)</p>
|
|
<p>15:38 <+Complication> Aside from "perhaps indeed"</p>
|
|
<p>15:38 < jrandom> improvements come from per-arch builds</p>
|
|
<p>15:40 <+Complication> In my test, provoked by their test, however the 64-bit athlon lib on a 64-bit Sempron, on a 64-bit Mandriva, however... does seem only marginally quicker than pure Java</p>
|
|
<p>15:40 <+Complication> (oh, and a 64-bit VM)</p>
|
|
<p>15:41 <+Complication> (marginally being twice)</p>
|
|
<p>15:41 < jrandom> hmm 'k</p>
|
|
<p>15:42 <+Complication> I'll try testing on more platform combinations, and tell if I find anything which seems worth relaying</p>
|
|
<p>15:43 < jrandom> cool, thanks</p>
|
|
<p>15:43 < jrandom> ok, anyone have anything else for the meeting?</p>
|
|
<p>15:46 < jrandom> if not...</p>
|
|
<p>15:46 * jrandom winds up</p>
|
|
<p>15:47 * jrandom *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |