15:08 < jrandom> 0) hi
15:08 < jrandom> 1) Net status
15:08 < jrandom> 2) ???
15:08 < jrandom> 0) hi
15:08 * jrandom waves
15:08 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001267.html
15:09 * jrandom gives y'all hours to read through that huge tome of notes
15:10 * Complication pretends not having noticed yet ;)
15:11 <+Complication> Hi :)
15:11 <+susi23> hi :)
15:12 < jrandom> well, might as well dig on in to 1) net status
15:12 < jrandom> The mail gives my general view of whats going on. how does that line up with what y'all are seeing?
15:13 <+Complication> Throttling fixes seem to have increased reliability, but really suppressed bandwidth
15:13 <+Complication> Just a second, digging for the graph
15:14 <+Complication> http://complication.i2p/files/bw-week.png
15:14 <+Complication> High stretches are on non-latest, low stretches on latest
15:15 <+Complication> Same limiter settings, possibly more lax on stricter (latest) versions
15:16 <+Complication> But it's not much of a problem, since it does transfer
15:16 < jrandom> cool, reduced bandwidth usage is appropriate as you approach your actual bandwidth limit
15:17 <+Complication> Most of time, it seems to bounce back before the "sustained bandwidth" limit
15:17 <+Complication> Never touches the burst limit
15:18 <+Complication> (which, in itself, is sensible - it's the bouncing back before the sustained limit which concerns me)
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
15:19 < jrandom> is 200kbps your limiter rate, w/ 300kbps burst?
15:20 < jrandom> (just wondering how much time it used to spend in the burst)
15:20 < jrandom> reduced bandwidth usage though is one of the aims of the recent changes
15:21 <+Complication> ~225 sustained, ~325 burst
15:21 <+Complication> Hey, I could have...
15:22 <+Complication> Have I *interpreted* it wrong?
15:23 <+Complication> Forget it, I'm a fool... did the math wrong, it's not nearly as bad :O
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
15:23 <+Complication> It's a bit on the conservative side, but not nearly as bad as I thought
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
15:25 <+Complication> But inbound total average, I have to say, is only slightly above 1/3 sustained limit, and 1/4 burst limit
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)
15:26 < jrandom> cool
15:26 <+Complication> But the graph I misinterpreted, due to Kb/KB issues :O
15:27 * Complication wipes the graph from history
15:28 < jrandom> good eye though, definitely lemmie know when things sound funky
15:28 < jrandom> ok, anything else on 1) Net status?
15:28 < jrandom> if not, lets shimmy on over to 2) ???
15:28 < jrandom> anyone have anything else to discuss?
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
15:31 <+Complication> They had it slower than pure Java, not sure if a measurement glitch or not :O
15:32 <+Complication> I couldn't repeat it
15:32 < jrandom> yeah, i wasn't sure exactly what .so they were using for the platform
15:32 <+Complication> Over here, it was about twice faster than pure Java
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
15:33 < jrandom> ah wikked dust
15:33 <+dust> no css tho
15:33 <+Complication> But people on 32-bit spoke of it being *way* faster then pure Java (like 10x or similar)
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?
15:36 <+Complication> bar: could be, since I tested it too on a 64-bit OS :O
15:36 < jrandom> iirc the amd64 was built to work on pure64 debian
15:37 <+Complication> Either way, some people suggested that importing a fresher gmp might help
15:37 < bar> just a stab in the dark, i'm no wiz at these things
15:37 < jrandom> eh, we use 4.1.4
15:37 <+Complication> Especially after they've done their soon-to-come version jump
15:38 <+Complication> Since I'm no gmp specialist, I couldn't tell much about it
15:38 < jrandom> (and the upcoming optimizations in gmp aren't likely to have substantial improvement)
15:38 <+Complication> Aside from "perhaps indeed"
15:38 < jrandom> improvements come from per-arch builds
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
15:40 <+Complication> (oh, and a 64-bit VM)
15:41 <+Complication> (marginally being twice)
15:41 < jrandom> hmm 'k
15:42 <+Complication> I'll try testing on more platform combinations, and tell if I find anything which seems worth relaying
15:43 < jrandom> cool, thanks
15:43 < jrandom> ok, anyone have anything else for the meeting?
15:46 < jrandom> if not...
15:46 * jrandom winds up
15:47 * jrandom *baf*s the meeting closed