73 lines
5.4 KiB
Plaintext
73 lines
5.4 KiB
Plaintext
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
|