Timestamps are in GMT/BST.
[0:10] <KenMan> oh yeah. Sealab rocks.
[0:12] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) has joined #Freenet
[0:18] <KenMan> the 'universal remonster'
[0:26] <KenMan> was tonight's 2nd ATHF episode
[0:27] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) Quit (Read error: 60 (Operation timed out))
[0:33] * KenMan has 9 of 15 blocks for gnu.ogg
[0:33] <wind789> cool
[0:34] <Ash-Fox> http://www.penny-arcade.com/images/2002/20020722l.gif
[0:34] <Ash-Fox> Some how I find that realistic...
[0:35] <thelema> Ash-Fox: heh.
[0:40] <KenMan> okay, so if a CHK can represent a splitfile, are there more CHKs that hold the pieces, and the main CHK is just a list of the pieces ? or what ?
[0:41] <thelema> yes.
[0:41] * salahx changes topic to 'yesFreenet: Taming the World's Largest Tamagotchi | Upgrade to 5087 | Unstable: Upgrade to 60172 | Logs: http://newton.matcmp.ncc.edu/~lockej/freenet/chanlog/'
[0:41] <salahx> the fist CHK containts the emtadata which has MORE CHK's
[0:41] <thelema> unless one of the pieces is the listing of CHKs of pieces. But that's hard to do.
[0:41] <KenMan> cool...
[0:43] <wind789> I'm off to bed night all
[0:44] <KenMan> night wind... come back soon
[0:44] <wind789> will do, good luck on that download
[0:54] * thelema is now known as thelema|away
[0:54] * Tailchaser (~tailchase@pool-68-162-16-41.nwrk.east.verizon.net) Quit (Remote closed the connection)
[0:58] * KenMan got gnu.ogg with many retries-per-block - this 'broadcasts' his activities, but it worked for him..
[0:59] <salahx> that's not that promosing
[0:59] <salahx> becasue that effective amounts to a brute-force search
[0:59] <KenMan> well, that it worked at all, is something...
[1:00] <salahx> Around here anyrthing resembling success is a reason to party...
[1:00] <KenMan> yup , for sure. Now I'm back to having more incomings than outgoings. Oh yeah, toad thinks that is just bad accounting. Good.
[1:02] <KenMan> time to release a 5088, with lastGoodBuild set to 5088. Otherwise, everything can still be dragged down by the sickness.
[1:02] <salahx> he should work for Enron or authur anderson :)
[1:02] <KenMan> who should ?
[1:02] <salahx> when 5088 is release lastKnownGood will probably be 5087
[1:02] <salahx> toad
[1:03] <KenMan> that would be unfortunate. 5087 is still vulnerable to badness... and it has a transitory effect...
[1:03] <salahx> <KenMan> ...Oh yeah, toad thinks that is just bad accounting. Good.
[1:03] <KenMan> ah, i get you now.
[1:03] <salahx> ther has rto a lest 1 version otherwise people won;t get see the new node version
[1:04] <KenMan> yeah, but ...
[1:05] <KenMan> i can't wait to see at what Totally Random point in time toad decides to reset stable with new protocol version.
[1:05] <salahx> itsn to totally random
[1:05] <salahx> usually only he implements a disprive feature
[1:06] <KenMan> heh - he tends to get urges and act on them rather quickly. Apparently this MRI thing should have deserved a protocol upping anyway.
[1:07] <KenMan> nevertheless, I am amazed at how much he manages to carry around in his head !!
[1:13] <KenMan> i just realized, i managed to fetch that ogg with less than 40 peers available. Not bad.
[1:17] <KenMan> when searching splitfiles, it would not be so bad to stagger the individual requests , such that they are masked by the through-flow of requests...
[1:19] <salahx> that's really a client issue though
[1:19] <KenMan> yes and no. It should be fred's responsibility to balance the two sources of requests... it's the only way it can be right.
[1:20] <KenMan> *be done right
[1:20] <salahx> How does Fred know which ekys are part of a splitfile ?
[1:20] <salahx> PRfoxy and the FCP client withing Freenet might, but Fred doesn'rt
[1:20] <KenMan> fred knows which requests come in via FNP, and which ones come in via FCP. Hopefully some day he will make an effort to disguise the FCP ones.
[1:21] <KenMan> blah, same thing :)
[1:25] <salahx> FCP is stateless though
[1:25] <salahx> FCP migth get 40 requests but how does it know all 40 are from teh sam e splitfile ?
[1:33] <KenMan> it doesn't. I am only differentiating on local versus remote queries. When you ask for 200 keys, and you issue the requests all at the same time, you blot out the others (not to mention creating backoff). Then I can tell which requests are yours, and which ones aren't. Even if I don't get to see each one of them, I know which category you are asking for.
[1:33] <KenMan> The pattern currently created with the MRI system has a telltale signature, which is a shame.
[1:33] <KenMan> I can finger frost users with very little error.
[1:34] <salahx> I figure the mRI woudl tend to spreat thenm out
[1:34] <KenMan> no, the MRI's that YOU issue go to the ceiling, because you can't handle your sudden local pressure, let alone any external requests.
[1:35] <salahx> hmmm
[1:35] <KenMan> I've plotted individual incoming MRIs and tracked which hosts they come from. Just in the global plot, your eye can easily spot the MRIs that are suddenly going to the roof. Then I ran frost locally to ensure that the pattern was highly distinguishable.
[1:35] <KenMan> it is.
[1:36] <salahx> that's a problem
[1:36] <KenMan> which is too bad, but it is now an identified problem to be solved :)
[1:36] <salahx> well theren' there 2 options then:
[1:37] <KenMan> I've kept my mouth shut because we can only do so much development per week/month/whatever. And toad already must have a todo list a mile long :(
[1:37] <salahx> 1 send an (enforced) option telling it how long it shoudl it shoudl issue another insert/request....
[1:37] <salahx> or 2) Queue the question consits with the other traffic
[1:38] <KenMan> queueing is the only solution. Ideally we would want a queue that could be inspected via fproxy, in case we jam it up with 1000 requests...
[1:38] <KenMan> :)
[1:38] <salahx> yeah but the Fred has to carry even MORE state
[1:38] <KenMan> that's life.
[1:38] <salahx> with #1 we can ptu teh burden on the client. Altohguh for an "open" FCP port, it might be an issue
[1:39] <KenMan> and it's not that bad. Unless the user (or frost) goes crazy with 1000 requests/minute...
[1:39] <KenMan> i see what you are saying, but in either case it is a form of queueing.
[1:39] <salahx> tihnk of it as an mRI for FCP
[1:39] <salahx> yeah, but gtthis way, we push it off to teh client adn changes to Fred are minimal
[1:39] <KenMan> yeah. I see what you mean, and it would be a sufficient solution to the problem.
[1:40] <KenMan> so long as fred can balance multiple clients (or we tell users to only use a single client).
[1:40] <KenMan> rate control extends its wonderous form into yet another API :)
[1:41] <KenMan> we still don't have the basic MRI algorithm for FNP even close to acceptable yet :(
[1:41] <KenMan> anyway, good stuff for another day - YAWN !!
[1:42] <salahx> ok
[1:42] * KenMan needs some zzz's
[1:42] <KenMan> night !
[1:43] <salahx> ok!
[1:43] <KenMan> crap, I haven't seen kevloral around for a while either... i'm sure he will be back though.
[1:44] <salahx> ok
[1:46] <Iakin> [21:46] <Iakin> Well, sure.. but how would they be distributed? what would choose the correct version?
[1:46] <Iakin> [21:46] <hirvox> the user?
[1:46] <Iakin> Pah!.. dont let users choose
[1:46] <Iakin> Will _always_ cause support questions
[1:47] <Iakin> [21:50] <salahx> is;nt there any way in Java got the architiure of the machine its running on witout have to resort to JNI?
[1:47] <Iakin> The architechture, yes.. I use it...
[1:48] <Iakin> The code will only run the cpu detection code (which is x86 code) if it is an x86 machine
[1:48] <salahx> ohhh ok
[1:48] <salahx> it ca'nt get that info from though, can it ?
[1:50] <salahx> Or at least, i can't get that info from Java in a JVM-independent manner
[1:50] <salahx> ?
[2:10] * sanity (~r00t@81-178-66-53.dsl.pipex.com) Quit ("Leaving")
[2:12] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) has joined #Freenet
[2:27] * BlackyVIP (~VIP@rsteam.org) has joined #freenet
[2:28] * BlackyVIP (~VIP@rsteam.org) has left #freenet
[2:40] * salahx (salahx@sc1-24.217.174.147.charter-stl.com) Quit ()
[2:41] * shendaras (~shendaras@ip68-97-113-208.ok.ok.cox.net) has joined #freenet
[2:47] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) Quit (Read error: 110 (Connection timed out))
[3:22] * srob99__ (~srob99@203-59-112-222.dyn.iinet.net.au) has joined #freenet
[3:39] * srob99_ (~srob99@203-59-108-109.dyn.iinet.net.au) Quit (Read error: 110 (Connection timed out))
[4:13] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) has joined #Freenet
[4:44] <iip_i2p> <Newsbyte> toad!!! You there?
[4:56] <iip_i2p> <Newsbyte> toooooooaaaaaaddddd
[4:58] * pwk_ (~phweak@dsl-62-3-71-168.zen.co.uk) Quit (Read error: 104 (Connection reset by peer))
[5:05] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) Quit (Read error: 110 (Connection timed out))
[5:06] <iip_i2p> <Newsbyte> hi there
[5:49] * Hory (~Miranda@81.196.25.110) has joined #FreeNet
[5:52] <iip_i2p> <Newsbyte> hi horny
[5:52] <iip_i2p> <Newsbyte> ermm, hory
[5:55] * guido^pe (~unknown@dsl-213-023-243-072.arcor-ip.net) has joined #freenet
[5:57] * guido^pe (~unknown@dsl-213-023-243-072.arcor-ip.net) Quit (Remote closed the connection)
[5:58] * Pascal (Pascal@c-24-13-17-191.client.comcast.net) Quit (Read error: 54 (Connection reset by peer))
[5:59] * tyesinclair (~tyesincla@170.252.64.1) has joined #freenet
[5:59] * tyesinclair (~tyesincla@170.252.64.1) has left #freenet
[5:59] * Janete (~jano@155.210.155.101) has joined #freenet
[6:10] * robilad[afk] is now known as robilad
[6:12] * shendaras (~shendaras@ip68-97-113-208.ok.ok.cox.net) has left #freenet
[6:14] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) has joined #Freenet
[6:46] * Pascal (Pascal@c-24-13-17-191.client.comcast.net) has joined #Freenet
[6:54] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) Quit (Read error: 60 (Operation timed out))
[7:53] -NickServ- This nickname is owned by someone else
[7:53] -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password>
[8:07] * tyesinclair (~tyesincla@170.252.64.1) has joined #freenet
[8:08] * tyesinclair (~tyesincla@170.252.64.1) has left #freenet
[8:11] * Lux (~Lux@82-37-17-24.cable.ubr03.wolv.blueyonder.co.uk) has joined #freenet
[8:12] <Lux> heh im trying to set up freenet so my laptop runs it but so i can access it from my desktop, but it seems i can only access it from 127.0.0.1 ie the laptop, anyone?
[8:14] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) has joined #Freenet
[8:15] <Lux> heh im trying to set up freenet so my laptop runs it but so i can access it from my desktop, but it seems i can only access it from 127.0.0.1 ie the laptop, anyone?
[8:15] <Janete> review your freenet.conf, i think you can specify there the IPs to allow access
[8:15] <Lux> i put some in fcpHosts
[8:15] <Lux> but it still only seems accessible via 127.0.0.1
[8:15] <iip_i2p> <Sonax> lyx: Look for a "mainport.allowedHosts=" in freenet.conf (or freenet.ini)
[8:16] <Lux> kk
[8:17] <iip_i2p> <Sonax> lyx: fcpHosts are clients (fiw, fuqid, frost etc), mainport is the web thing
[8:17] <Janete> and don'te forget to remove the % at the beginning of the line
[8:17] <Lux> it works :D
[8:17] <Lux> thanks guys
[8:18] * Lux (~Lux@82-37-17-24.cable.ubr03.wolv.blueyonder.co.uk) Quit ("Leaving")
[9:37] * greycat (~wooledg@192.35.79.70) has joined #freenet
[9:38] <mikeDOTd> the connections stuff still isn't working. my 5087 node has been up for 13 hours, and only has 67 open connections
[9:38] * Lux (~Lux@82-37-17-24.cable.ubr03.wolv.blueyonder.co.uk) has joined #freenet
[9:41] <Iakin> [03:45] <greycat> Why did they stuff a whole GPL'ed or LGPL'ed source tarball in the CVS?
[9:42] <Iakin> Because the build script extracts it and then knows where to look for the files.. Because of the the compiling user wont have to configure any paths...
[9:42] <greycat> The irony is that I didn't even want to build in Contrib, but "ant clean" from the freenet directory bitched about stuff missing under Contrib.
[9:42] <Iakin> [03:46] <KenMan> Iakin is my guess
[9:42] <Iakin> Goos guess
[9:42] <Iakin> s/Goos/Good
[9:43] <Lux> any ideas on a usenet posting service from freenet?
[9:44] <greycat> Lux: someone would have to suck files from Freenet and then post them to Usenet.
[9:45] <Lux> kk
[9:55] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) Quit (Read error: 110 (Connection timed out))
[10:06] * Hory (~Miranda@81.196.25.110) Quit (Connection timed out)
[10:08] * Lux (~Lux@82-37-17-24.cable.ubr03.wolv.blueyonder.co.uk) has left #freenet
[10:10] <Iakin> [08:06] <salahx> Or at least, i can't get that info from Java in a JVM-independent manner
[10:10] <Iakin> Nope, none as I know
[10:18] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) has joined #Freenet
[10:37] * toad_ (toad@82-32-16-91.cable.ubr03.azte.blueyonder.co.uk) has joined #freenet
[10:41] <KenMan> ribbit .
[10:43] <KenMan> ( he /seems/ to understand when I speak frog... )
[10:44] * srob99_ (~srob99@203-59-107-156.dyn.iinet.net.au) has joined #freenet
[10:45] * TheSeeker (~Fridlekh@cpe-65-28-158-211.socal.rr.com) Quit (Read error: 60 (Operation timed out))
[10:46] <KenMan> toad_ : time to do a network reset in stable. 5087 is unable to communicate MRI values to 5084, this is partly why everything fell apart.
[10:47] <KenMan> setting lastGoodBuild=5087 brought things back under control
[10:48] <Janete> scary
[10:49] * KenMan is now known as FrogMan
[10:52] <toad_> KenMan: it is?
[10:55] * srob99__ (~srob99@203-59-112-222.dyn.iinet.net.au) Quit (Read error: 110 (Connection timed out))
[10:55] <toad_> <KenMan> toad_ : time to do a network reset in stable. 5087 is unable to communicate MRI values to 5084, this is partly why everything fell apart.
[10:55] * lolo-laptop (~lostlogic@68.251.84.226) has joined #freenet
[10:55] <toad_> why do you say that?
[10:55] <toad_> I was pretty careful with the back compatibility code
[10:55] <toad_> and everyone tells me that resetting stable would be a crime against sentience
[10:56] * srob99__ (~srob99@203-59-253-156.dyn.iinet.net.au) has joined #freenet
[10:57] <hirvox> ...
[10:58] * iip_i2p (~changate@host.teitel.net) Quit (Read error: 113 (No route to host))
[11:03] * srob99_ (~srob99@203-59-107-156.dyn.iinet.net.au) Quit (Read error: 110 (Connection timed out))
[11:05] <FrogMan> toad_ we grepped our logs for 'mri violated' and 100% came up for 5084 nodes. The MRI charts supported that as well.
[11:06] <FrogMan> well, at least release a 5088 with lgb=5087
[11:08] * srob99_ (~srob99@203-59-44-168.dyn.iinet.net.au) has joined #freenet
[11:09] * Hory (~Miranda@81.196.25.110) has joined #FreeNet
[11:11] * Hory (~Miranda@81.196.25.110) Quit (Client Quit)
[11:13] <Janete> a reset in stable and people will demand toad's head ;)
[11:14] * i2p_iip (~changate@host.teitel.net) has joined #freenet
[11:14] <toad_> Janete: why?
[11:14] <toad_> what else am i supposed to do?
[11:14] <toad_> everything i do demands my head
[11:14] <Janete> i don'te mind, personally
[11:14] <toad_> i'm unable to please anyone
[11:14] <toad_> so i just get on with it
[11:14] <Janete> hehe
[11:15] <Janete> just do what you think is better
[11:15] <Janete> as you say, there's always someone who complains
[11:15] <FrogMan> yes... that's never stopped you before :)
[11:15] <Janete> but there's something i don'te get from the logs
[11:15] * srob99__ (~srob99@203-59-253-156.dyn.iinet.net.au) Quit (Read error: 113 (No route to host))
[11:15] <Janete> who wants the reset, toad or kenman
[11:16] <FrogMan> kenman, if the protocol has changed (re: MRI)
[11:16] <Janete> so, there's not going to be a reset?
[11:17] <FrogMan> all that matters right now is that we repair the widespread break, however we do it.
[11:17] <FrogMan> I'm not sure if I have convinced toad that there even IS a problem :(
[11:18] <Janete> yep, my node isn'te doing so bad
[11:18] <FrogMan> if he is running a stable node, then somebody tell him to count the number of "interval violated" messages in his log.
[11:18] <FrogMan> Janete - what OS are you under
[11:18] <Janete> linux 2.6
[11:19] <FrogMan> okay, do grep "violated" | wc -l and share it with us
[11:19] <FrogMan> grep "violated" freenet.log | wc -l
[11:19] <greycat> YM grep violated freenet.log | wc -l
[11:19] <greycat> ah.
[11:19] * greycat is slow today
[11:19] * FrogMan is slow everyday
[11:19] <Janete> ok, let's see...
[11:20] <Janete> do you mean
[11:21] <Janete> cat freenet.log | grep violated | wc -l
[11:21] <FrogMan> sure
[11:21] <Janete> 0
[11:21] <FrogMan> that is good !!
[11:22] <Janete> i have the level set to error
[11:22] <FrogMan> If EVERYONE on stable has already moved past 5084, then we don't have this problem. Maybe they all upgraded already ...
[11:23] <greycat> Fred,0.5,STABLE-1.50,5084 133
[11:23] <greycat> Fred,0.5,STABLE-1.50,5085 34
[11:23] <greycat> Fred,0.5,STABLE-1.50,5086 98
[11:23] <greycat> Fred,0.5,STABLE-1.50,5087 130
[11:23] <toad_> well yeah but if you read the lists you'll know that 5087 sucks worse even than 5086 and 5085
[11:23] <Janete> I'll check my routing table numbers
[11:23] <toad_> 5084 rulez, except for that Magic Build back in the depths of time that was even better
[11:23] <FrogMan> 5028 - toad, I loved that build !!
[11:23] <toad_> in fact, if you go back to freenet 0.1... my involvement with freenet 0.1 in code terms was nil...
[11:23] <toad_> so that must work even better!
[11:23] <Janete> Fred,0.5,STABLE-1.50,5083 |
[11:23] <Janete> Fred,0.5,STABLE-1.50,5084 |===============================================================
[11:23] <Janete> Fred,0.5,STABLE-1.50,5085 |===============
[11:23] <Janete> Fred,0.5,STABLE-1.50,5086 |===========================================
[11:23] <Janete> Fred,0.5,STABLE-1.50,5087 |===============================
[11:23] <Janete> ups
[11:24] <FrogMan> toad - are you running a stable node ?
[11:24] <toad_> but yes, i think a network reset probably is called for
[11:24] <toad_> FrogMan: yes
[11:24] * interrupt (~chatzilla@64.122.23.213) has joined #freenet
[11:24] <Janete> greycat> sorry, where you got that numeric values?
[11:24] <FrogMan> then just lok at your logs, and ask yourself if that many MRI violated lines is appropriate
[11:24] <toad_> FrogMan: the thing is, it still sends MRIs to 5084's
[11:24] <greycat> Janete: http://127.0.0.1:8888/servlet/nodestatus/version_data.txt
[11:24] <toad_> it just doesn't send them as often as it sends them to 5085+'s
[11:24] <greycat> Janete: it's the (flat ascii) link
[11:24] <toad_> because it sends them differently
[11:24] <FrogMan> apparently, for whatever reason, 5084 doesn't respect them :(
[11:24] <toad_> anyway, i'll check the logs
[11:25] <toad_> lots of MRI violations, of course
[11:25] <toad_> aaaargh
[11:25] <toad_> stupid f*cking node
[11:25] <FrogMan> no, not 'of course'. You have caused their count to go down recently...
[11:25] <toad_> it did this yesterday!
[11:25] <toad_> why isn't it compressing the bloody log files?
[11:26] <FrogMan> okay, then count how many of those violated messages are for version 5084. Maybe *that* will help to convince you...
[11:27] <Janete> greycat: thanks
[11:27] <toad_> FrogMan: aren't most nodes on stable still 5084?
[11:27] <toad_> anyway I want to know WHY as well as WHAT
[11:27] <FrogMan> do you count more than 97% of violations as coming from 5084 ??
[11:28] <FrogMan> how many of YOUR nodes are still 5084 ?
[11:28] <toad_> argh
[11:28] <i2p_iip> <phamnuwen> More than 60% of my peers run 5087 (as I do)
[11:28] <FrogMan> just run the stupid commands - grep violated freenet.log | { grep 5084 | } wc -l
[11:28] <toad_> i don't have enough logging on to see the packets i'm sending!
[11:29] <toad_> FrogMan: that does not tell me why
[11:29] <toad_> of course 5084 will have WORSE rate limiting than recent builds
[11:29] <toad_> it's a question of whether it is 5087's fault
[11:30] <FrogMan> okay, so fix 5087 to produce a 5088 that CAN communicate with 5084, but CAN'T with 5087. whatever...
[11:30] <toad_> well maybe
[11:30] <toad_> or maybe it's more like, 5084's rate limiting sucks
[11:31] <toad_> we did a fair amount of work on rate limiting after 5084
[11:31] <FrogMan> no, 5087 <--> 5084 DOES NOT rate limit. 5084 uses a value of 0 for mRI's from 5087.
[11:31] <toad_> how do you know?
[11:32] <FrogMan> charts :)
[11:32] <FrogMan> just count the number of messages that 5084 is 'violating' and look at the values
[11:32] <lolo-laptop> toad_: is true, ken and I are running nodes on 5087 with 5087 LGB and they work OK ... but w/o the increased LGB it is unusable.
[11:33] <Janete> lolo-laptop: where can i change the LGB?
[11:33] <FrogMan> thank you, two supporters so far...
[11:33] <toad_> okay
[11:33] <lolo-laptop> Janete: in the Version.java file before rebuilding the freenet jar from source :-P
[11:33] <toad_> it appears we aren't sending the RequestInterval's
[11:33] <Janete> oops i'me not going to rebuild
[11:33] <toad_> even though I put in code to send requestintervals if build#==5084
[11:33] <toad_> hmmm
[11:34] <FrogMan> jez set LGB=5087 and be done with it, no complex thought required :)
[11:34] <toad_> okay
[11:34] <toad_> this is because I got it the wrong way around in PeerHandler.wantsRIInFNPMessages() :|
[11:35] <greycat> and when you're done with that, help me understand why jikes (1.14 and 1.21) can no longer build Freenet...
[11:35] <toad_> okay, i can fix that...
[11:35] <toad_> the question is whether we should reset stable anyway?
[11:35] <FrogMan> toad_ - we forgive your mistakes (when you fix them) ;)
[11:35] <toad_> probably it would be a good idea
[11:36] <toad_> but it would be quite disruptive and cause yet another "island" to be severed from the main line...
[11:36] <FrogMan> i support a reset, if you don't plan to change the protocol again (with tricky stuff like the above)
[11:36] * toad_ wonders how we can persuade users to keep track of new releases
[11:37] <toad_> maybe we should recommend they join at least one of our lists...
[11:37] * toad_ suspects most don't
[11:37] <hirvox> freenet-announce?
[11:37] <toad_> hirvox: for every new build?!
[11:37] <FrogMan> yeah, and the website ??
[11:37] <Janete> if it's imperative maybe you'll need some forced update?
[11:37] <hirvox> toad:for stable only
[11:37] <toad_> Janete: that's the thing, we can't force users to update, we can only cut them off when they don't
[11:37] <FrogMan> the incentive for upgrading is better performance, if we can offer that !!
[11:38] <toad_> most likely they won't hear about it, and they'll get cut off
[11:38] <i2p_iip> <phamnuwen> Has a LGB=<current version> - type network reset caused two separate stable-networks in the past? (Those < LGB on a "separate" net from those at LGB)?
[11:38] <Janete> toad_: is not possible to automatically download the new version (from freenet preferibly) and apply it on next node restart?
[11:38] <toad_> Janete: it's not a good idea legally or from a security standpoint
[11:39] <Janete> that's true
[11:39] <toad_> phamnuwen: to some extent, yes. As have protocol changes.
[11:39] <Janete> toad_: and, upon new version detection, putting a link in the web interface to force the update?
[11:39] <toad_> in any case it's time for a new stable build...
[11:40] <toad_> Janete: firstly, it's not possible to get it from freenet
[11:40] * interrupt (~chatzilla@64.122.23.213) Quit (Read error: 54 (Connection reset by peer))
[11:40] <toad_> secondly, it's not possible to force the user to do anything
[11:40] * srob99_ (~srob99@203-59-44-168.dyn.iinet.net.au) Quit ("Leaving")
[11:40] <lolo-laptop> well in this case it can be bridged, 5088 LGB=5087, 5087 LGB=<5084, there is no network split in theory
[11:40] <Janete> toad_: I mean, not force but make it as simple as possible
[11:40] <toad_> lolo-laptop: that's a de facto network split
[11:40] <toad_> Janete: it is reasonably simple
[11:41] <toad_> it cannot easily be done from within the node
[11:41] <toad_> I don't actually know how it is done on windows
[11:41] <toad_> but this is what i put on the announcement mails:
[11:41] <lolo-laptop> toad_: howso? the 5087 nodes can talk to 5088 and 5084, so the network is theoretically bridged...
[11:41] <toad_> Stable build 5087 is now available. The snapshots have been updated.
[11:41] <toad_> Please upgrade. You can do this on Windows by using the update option on
[11:41] <toad_> the start menu. On Linux, OS/X etc, you can update by using the
[11:41] <toad_> update.sh script (and restart the node). You can alternatively shut down
[11:41] <toad_> your node and download http://freenetproject.org/snapshots/freenet-latest.jar
[11:41] <toad_> over your existing freenet.jar, then restart your node.
[11:41] <Janete> yes, i run a windows node too
[11:41] <Janete> it's really easy
[11:42] <toad_> lolo-laptop: theoretically. I think given all that's happened (new routing algo in 5085, major rate limiting changes, lots of bugs), it'd be preferable to reset the network
[11:42] <toad_> the problem is we may need to do it again in future
[11:42] * lolo-laptop nods
[11:42] <toad_> I suppose we need to announce network resets on announce
[11:43] <i2p_iip> <phamnuwen> toad: If an old node connects to a newer node to which it cannot (by means of LGB) connect anymore, does the newer node actually TELL the older node what LGB it uses, or does it just say "denied". Because in the former case, FRED can be made to display the minimum recommended build on the gateway page.
[11:43] <greycat> sounds announcement-worthy to me.
[11:43] <verl> for all those that upgrade manually on windows and don't read the list, will they know about the freenet-ext.jar upgrade? perhpas it needs to be on the webpage?
[11:44] <greycat> verl: it's on my freesite, too, if anyone reads that....
[11:44] <toad_> we have no idea what the LGB is
[11:44] <toad_> we only know what the probable current highest build is
[11:44] <verl> greycat: good
[11:44] <toad_> and that's guesswork
[11:44] * toad_ emails ian...
[11:44] <greycat> verl: and if it can be inserted properly :-(
[11:46] <toad_> verl: that's part of the problem
[11:46] <toad_> but if they don't read the list, chances are they very very very rarely upgrade
[11:46] <toad_> if they don't read any of the lists
[11:46] <verl> toad: also, will the memory optimization be ported from unstable?
[11:46] * greycat usually upgrades when he sees "Build: 5086 (Latest: 5087)" on the web gateway
[11:46] <toad_> verl: yes
[11:47] <toad_> greycat: sure but you're here pretty often
[11:47] <Iakin> [15:58] <greycat> The irony is that I didn't even want to build in Contrib, but "ant clean" from the freenet directory bitched about stuff missing under Contrib.
[11:47] <greycat> yeah, I check /topic too.
[11:47] <Janete> why not automatically check a file in the website and open a pop-up asking for authorization to upgrade? (in windows)
[11:47] <verl> if you get it on the wepage i think 99% will get it. and it's not like it would be cluttered. it's not updated very often.
[11:47] <toad_> umm, you mean ant distclean?
[11:48] <Iakin> Huh? build.sh should work (if executed int the directory where it is)
[11:48] <toad_> Janete: yuck
[11:48] <greycat> toad_: no, I typed "ant clean"
[11:48] <toad_> hmmm
[11:48] <toad_> should I put out 5085 anyway, with the fix?
[11:49] <verl> and people still like the thing about going to the website to see updates, rather than mailinglists or irc
[11:49] <FrogMan> yes, replace the version where it all went wrong. 5085 it is... :)
[11:49] <toad_> FrogMan: huh?
[11:49] <toad_> ah
[11:49] <toad_> 5088 :)
[11:50] <FrogMan> this could be a good exercise... akin to resets and lgbs ...
[11:50] <FrogMan> :) - of course, it IS a serious option...
[11:50] * toad_ is going to merge 5084 anyway
[11:50] <toad_> err 5088
[11:51] <Iakin> greycat: try ./build.sh
[11:51] <FrogMan> stop teasing me, toad !!
[11:51] <toad_> we need to decide whether it will make lGB==5087, and whether it will bump the protocol number
[11:51] <toad_> if might just work
[11:51] * pwk__ (~phweak@dsl-62-3-71-168.zen.co.uk) has joined #freenet
[11:51] <Iakin> in the NBI or jcpuid folder
[11:51] <toad_> so perhaps we should just try it with lGB=5084
[11:51] <FrogMan> hello ?! you have a major problem while 5084 and 5087 are touching. Maybe you dont' recognize it yet.
[11:52] <toad_> i COULD put in an "we hate 5087"... but I don't see any reason why 5088/5087 would be a problem
[11:52] <toad_> FrogMan: yes, I found the bug, I fixed it
[11:52] <lolo-laptop> toad_: I think what you are doing is good.
[11:52] <lolo-laptop> toad_: becaus epeople on 5087 currently are those that upgrade often, and therefore 5087 will leave the network quickly.
[11:52] <lolo-laptop> go for it.
[11:52] <toad_> lolo-laptop: hmmm
[11:53] <toad_> probably you are right
[11:53] <FrogMan> so long as a 5084 and a 5087 exist in the same network, the formula exists for major trouble (unlimited queries, think "20K qph")...
[11:53] <Iakin> [15:58] <greycat> The irony is that I didn't even want to build in Contrib, but "ant clean" from the freenet directory bitched about stuff missing under Contrib.
[11:53] <Iakin> Heh
[11:53] <Iakin> oops..
[11:53] <Iakin> copy-paste buffer seems broken
[11:54] <i2p_iip> <phamnuwen> toad_: if you make 5088 with lgb=5087, the 5087 nodes can act as (admittedly bad) bridges. The question is: will this just make things slow for the dinosaurs still at 5084, or will it also screw up the entire routing for the newer nodes?
[11:54] <Iakin> nm
[11:54] * FrogMan smells a 5088 coming to a host near you ...
[11:54] <i2p_iip> <Newsbyte> toad, where've you been?!
[11:54] <Iakin> Toad, maybe Weak* didn't work for you because you used them wrongly ;)
[11:54] <i2p_iip> <Newsbyte> one would almost think you didn't have time to chat and were coding!
[11:55] <FrogMan> yes, that one makes me wonder too. I think there is more than one toad...
[11:55] <i2p_iip> <Newsbyte> which, obviously, seen the build, isn't so ;-p
[11:55] <toad_> Iakin: no, I just used a WeakHashtable
[11:55] <FrogMan> now that is uncalled for. It is my turn to beat the toad for a while...
[11:55] <i2p_iip> <Newsbyte> what are the main probs, now, toad?
[11:55] <toad_> I dropped it in
[11:55] <toad_> and I immediately got NPEs in unrelated code
[11:56] <toad_> hmmm
[11:56] <toad_> what's a reasonable number of lines to buffer? or should i just buffer 32kB?
[11:56] <toad_> in the logfile writer thread?
[11:57] <FrogMan> 256k for you!!
[11:57] * toad_ just buffers 32kB, and flushes every time we sleep
[11:58] * FrogMan is now known as frog_
[11:58] * interrupt (~chatzilla@64.122.23.213) has joined #freenet
[11:59] * TheSeeker (Fridlekh@4.27.134.106) has joined #Freenet
[12:01] <i2p_iip> <Newsbyte> goddamn connection
[12:01] <i2p_iip> <Newsbyte> what did I miss?
[12:02] <i2p_iip> <Newsbyte> me looks at toad
[12:02] <toad_> okay, /me is keeping the logger changes out of stable for now
[12:02] <toad_> will commit them to unstable though
[12:02] <toad_> it wasn't making any difference because we flushed after every line :)
[12:03] <i2p_iip> <Newsbyte> btw, my livingroom is finished more or less, now, so my puters are back
[12:03] <i2p_iip> <Newsbyte> and so I finally put in your ram, toad
[12:04] <toad_> or perhaps i will... i'm certainly going to test using it...
[12:04] <i2p_iip> <Newsbyte> one was bork, the others were 64 apart from one 128
[12:04] <i2p_iip> <Newsbyte> dunno if you put in a 256, but if you did, it must be the one that was kaput
[12:05] <toad_> it was useful to you nonetheless?
[12:05] <toad_> for the purpose of running freenet?
[12:05] <i2p_iip> <Newsbyte> anyway, I've set it up yesterday, netconnection is working, so...only the testnetwork remains to be waited for...
[12:05] <toad_> Newsbyte: bug in 5087's 5084-compatibility-in-rate-limiting code
[12:05] <i2p_iip> <Newsbyte> I think so
[12:07] <i2p_iip> <Newsbyte> I've replaced the 32 mb with 64, and then put in the 128, so I have 256 in total
[12:07] <i2p_iip> <Newsbyte> I'm thinking of using it also as IIP relay. It could need it, seen the bad connections these days ;-)
[12:08] <i2p_iip> <Newsbyte> anyone knows what to so, and if it works on win?
[12:10] <i2p_iip> <Newsbyte> darn...am I lagged again?
[12:11] <toad_> Iakin: any idea about the fixKeys errors?
[12:12] <toad_> Another day, another stable release. Sometimes it behaves itself, sometimes it doesn't.
[12:12] <toad_> After speaking with a few other node runners, we're of the general opinion that much of the current instability of the stable network is perhaps simply down to destructive interaction between the last major stable release and the current wave of releases. I seem to recall something similar happening once before when two stable versions with radically modified routing tried living side by side. Things didn't start to really settle
[12:12] <toad_> Perhaps it's time to start blocking those old nodes ? It's nice to have a grace period to allow infrequent Freenet users the chance to catch up with everybody else before the network blocks their node, but perhaps in this case it's doing more harm than good.
[12:12] <toad_> hmmm
[12:12] <i2p_iip> <Newsbyte> just make the whole damn thing 87 mandatory
[12:12] <toad_> Content of Evil seemingly supporting a reset...
[12:12] * FridlekhToo (Fridlekh@4.27.134.106) has joined #Freenet
[12:13] <toad_> the problem with a reset is that if we reset properly, then old node operators won't see the new build
[12:13] <toad_> and therefore won't upgrade
[12:13] <toad_> unless they find out about it out of band
[12:13] * TheSeeker (Fridlekh@4.27.134.106) Quit (Read error: 54 (Connection reset by peer))
[12:13] <i2p_iip> <Newsbyte> solution: remote-auto-update
[12:13] <toad_> Newsbyte: not on stable
[12:14] <i2p_iip> <Newsbyte> obviously only a possibility for the testnetwork
[12:14] <toad_> the question is what to do about stable
[12:15] <i2p_iip> <Newsbyte> I dunno...one should keep compatibilty as long and as much as possible, ofcourse. But if it really ain't possible...
[12:15] <toad_> well, I'm not sure the recent problems ARE due to the routing changes
[12:15] <i2p_iip> <Newsbyte> basically, it comes down to giving them a sign they have to update, rught?
[12:15] <toad_> i think it's more likely they're due to a series of bugs in the transition...
[12:16] <toad_> I suppose we could do a de facto reset, without changing the protocol number
[12:16] <toad_> i.e. just do 5088, making 5088 the lGB
[12:16] <i2p_iip> <Newsbyte> so...maybe you could set a messages, when needed, on the webinterface? Everyone using freenet then will see it...
[12:16] <toad_> i'm half inclined to put out 5088 with 5084 mandatory
[12:16] <toad_> Newsbyte: then you have to secure it.. then you get into key manglement problems
[12:16] <greycat> Newsbyte: where would the messages come from?
[12:17] <i2p_iip> <Newsbyte> 5085, you mean
[12:17] <toad_> Newsbyte: no, 5084
[12:17] <greycat> toad_: you lost me, too.
[12:18] <i2p_iip> <Newsbyte> no,no, I'm not talking about updating it, just making sure everyone that uses freenet is aware of the possible problem and should upgrade. A simple text-message on the mainpages of the indexes on the webinterface would do that, me thinks..
[12:19] <greycat> Newsbyte: you can't retroactively alter everyone's web interface text.
[12:19] <greycat> the index pages will probably mention it (at least CofE will)
[12:19] <Iakin> This probably is the reason for those cannot rename node-temp to node
[12:19] <Iakin> 2004-jul-29 16:08:14 (freenet.node.Node, main, NORMAL): starting ListenSelector..
[12:19] <Iakin> 2004-jul-29 16:08:19 (freenet.node.Main, Network reading thread, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:19] <Iakin> 2004-jul-29 16:08:20 (freenet.node.Main, Network reading thread, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:19] <Iakin> 2004-jul-29 16:08:21 (freenet.node.Main, Network reading thread, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:19] <i2p_iip> <Newsbyte> toad, 5084 already was mandatory... if the new builds conflict with the old ones, one should go for 5085, since 84 was still the old way
[12:19] <Iakin> 2004-jul-29 16:08:21 (freenet.node.Main, Network reading thread, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:19] <Iakin> 2004-jul-29 16:08:24 (freenet.node.Main, Network reading thread, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:19] <Iakin> Something somewhere ought to check that it really _is_ a change
[12:20] <Iakin> And then:
[12:20] <Iakin> 2004-jul-29 16:08:44 (freenet.node.Main, Network reading thread, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:20] <Iakin> 2004-jul-29 16:08:44 (freenet.node.Main, YThread-3, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:20] <Iakin> 2004-jul-29 16:08:44 (freenet.node.Main, YThread-13, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:20] <Iakin> 2004-jul-29 16:08:44 (freenet.node.Main, Network reading thread, MINOR): Address change: new addresses: iakin.poweruser.org:26828
[12:20] <Iakin> 2004-jul-29 16:08:44 (freenet.node.Main, YThread-13, ERROR): Cannot rename node-temp to node
[12:20] <Iakin> All within a second
[12:20] <toad_> Iakin: it was easier at the time to not check whether it was any different
[12:20] <Iakin> I think it would be good to do so
[12:20] <Iakin> :)
[12:21] <Iakin> 50% or so of my log talks about 'address change'
[12:21] <Iakin> toad, re the fixkeys thing..
[12:21] <toad_> hmmm
[12:21] <toad_> I wonder why it is called so often?
[12:21] <Iakin> For every connect
[12:22] <toad_> ah
[12:22] * interrupt (~chatzilla@64.122.23.213) Quit ("Chatzilla 0.9.64b [Mozilla rv:1.7/20040707]")
[12:22] <i2p_iip> <Newsbyte> toad, 5084 already was mandatory... if the new builds conflict with the old ones, one should go for 5085, since 84 was still the old way
[12:22] <Iakin> Dont you think the fixkeys key would have been automatically selected during the next select-spin?
[12:22] * toad_ adds the above to TODO
[12:22] <toad_> Iakin: huh?
[12:23] <toad_> fixkeys added it, meaning that the selector missed it
[12:23] <toad_> or something...
[12:23] <toad_> well the selector updated its writable status...
[12:23] <Iakin> maybe it was registered _after_ the select?
[12:23] <toad_> but didn't add it to the selected set
[12:23] <Iakin> or became writable _after_ the select?
[12:23] <i2p_iip> <Newsbyte> anyone knows something of how to set up an IIP relay?
[12:23] <toad_> Iakin: I don't think that stuff IS added after the select?
[12:23] <toad_> Iakin: and I thought the writable bits came from the select?
[12:25] <Iakin> toad, if we aren't properly clearing the selectedSet.. maybe they are lingering from an earlier occasion
[12:25] <toad_> Iakin: except that WE ARE
[12:25] <i2p_iip> <Newsbyte> as a server, I mean
[12:27] <toad_> okay, do I commit 5088 with lastGoodBuild=5084, and hope that the routing will sort out?
[12:27] <toad_> it will have a fix for the biiiig problem in 5087
[12:28] <toad_> i think that makes sense as the people who upgraded to 5087 are probably going to upgrade to 5088
[12:28] <toad_> otoh, maybe we need something new and exciting for the people who tried 5085 and went back to 5084.. e.g. a network reset
[12:29] * toad_ wonders where ian is.. he hasn't responded to my email...
[12:29] <i2p_iip> <Newsbyte> I got this as email :'I can't get the IP address to download FNC ! Where could I get this
[12:29] <i2p_iip> <Newsbyte> GI ?
[12:29] <i2p_iip> <Newsbyte> anyone cares to respond?
[12:30] <toad_> uhh, what does it mean?
[12:30] <frog_> ian is in san francisco, or LA or soemwhwre in CA ...
[12:30] <toad_> ah
[12:30] <toad_> hmm
[12:30] <toad_> so it's up to me
[12:30] <toad_> well
[12:30] <toad_> what are the advantages of a network reset?
[12:31] <frog_> do you mind me taking the moniker of 'frog' ??
[12:31] <toad_> i've registered amphibian...#
[12:31] <toad_> amphibian and toad_
[12:31] <toad_> toad was already taken
[12:31] <frog_> surely frog is also taken...
[12:31] * frog_ is now known as frog
[12:31] * frog is now known as frog_
[12:31] <frog_> yup
[12:32] <greycat> you could've just asked nickserv
[12:32] <frog_> i just did ;)
[12:33] * frog_ is resistant to 'too much' learning...
[12:33] <i2p_iip> <Newsbyte> I dunno...the guy wants to know the url?
[12:34] <greycat> the url for what? what's "FNC"?
[12:34] <i2p_iip> <Newsbyte> I was wondering about that myself, but I thought the Higher Gods would know...
[12:35] <i2p_iip> <Newsbyte> some freenettool?
[12:35] <frog_> FreenetNodeConfig ?
[12:35] * |UK-Monster| (~bbtt@cpc2-warr1-5-0-cust27.bagu.cable.ntl.com) has joined #freenet
[12:36] <toad_> hmmm
[12:36] <frog_> it doesn't really matter in the long run, just pick an option and drive it
[12:36] <FridlekhToo> hmm, I seem to have a real IP, but my DHCP lease expires every 4 hours >:(
[12:37] <toad_> well if I put out 5088, and leave it as 5084 lGB, then the advantage is that old content will be findable
[12:37] <frog_> FridlekhToo nasty ! and you are given a new IP every 4 hours as well ?
[12:37] <toad_> however, we still have to worry about the routing changes
[12:37] * FridlekhToo is now known as TheSeeker
[12:37] <frog_> so do that. Hopefully we lose all the 5087
[12:37] <TheSeeker> I don't know, it hasn't been 4 hours yet :P
[12:38] <toad_> well lets see
[12:38] <toad_> I'll commit 5088 with 5084 lGB
[12:38] <toad_> then i'll decide whether to do a reset anyway
[12:38] <frog_> don't worry toad, statistically, your even-numbered stable released are better received by the general population
[12:39] <greycat> hahaha
[12:39] <toad_> nah
[12:39] <toad_> hmmm
[12:39] <toad_> yes
[12:39] <toad_> ok
[12:39] <toad_> hopefully it'll settle then we can make 5088 mandatory
[12:39] <frog_> :)
[12:42] <frog_> don't forget the "* this is the release to settle all recent ailments on the stable network" part in your announcement.
[12:42] <frog_> use that and we will have good fortune
[12:43] <frog_> just don't ever make a statement like that for an odd-numbered stable release.
[12:46] <toad_> frog_: of course there will still be minor compatibility issues with 5084...
[12:46] <toad_> specifically, we still send MRIPacketMessage's and expect the other end to honour them
[12:46] <toad_> but the big recent problem was that we didn't send ANY MRIs
[12:46] <frog_> that is NOT minor.
[12:47] <frog_> oh, well, okay.
[12:47] <toad_> frog_: well, we will send RequestInterval's on FNP messages
[12:47] <toad_> in 5087, we send RequestIntervals on FNP messages to 5085+ nodes
[12:47] <frog_> It confuses my processes, but what the hell...
[12:47] <toad_> which is the opposite of what we should do
[12:47] <toad_> well, I can fix it, make it not send MRIPacketMessage's to 5084 at all
[12:47] <toad_> but that will take time and testing
[12:48] <toad_> or at least coding and risk :)
[12:48] <frog_> you've justified that course as 'retaining the old content'
[12:48] * TheSeeker (Fridlekh@4.27.134.106) Quit (Read error: 104 (Connection reset by peer))
[12:48] * TheSeeker (Fridlekh@4.27.134.106) has joined #Freenet
[12:48] <frog_> just do your best , and post-haste :)
[12:50] <frog_> if it is easier to 5088 w/5087 lgb , users will just have to carry their DS's across land to the next river.
[12:50] * Janete (~jano@155.210.155.101) has left #freenet
[12:52] * leex (~bbtt@cpc2-warr1-5-0-cust27.bagu.cable.ntl.com) Quit (Read error: 110 (Connection timed out))
[12:52] <frog_> i strongly believe that more frequent communication of MRI is causing spikier query rates...
[12:53] <toad_> eh?
[12:54] <toad_> that's bizarre
[12:54] <toad_> I don't see how it could cause spikier query rates
[12:54] <toad_> unless it's CHANGING faster
[12:54] <toad_> and it shouldn't be, it's pretty heavily stabilized
[12:54] <frog_> exactly. and changing in dramatic fashion
[12:54] <frog_> just keep an eye on the qpm graph (starting about a week ago)
[12:55] <toad_> when I investigated that the only thing I could find was that maybe the 10 minute cap is excessive
[12:55] <toad_> but I can't really take that off on stable
[12:55] <frog_> no, just look at qpm from time to time, is all i ask...
[12:55] <toad_> well not unless I outlaw 5084 anyway
[12:56] <toad_> frog_: well, show me the graphs
[12:56] <frog_> they are in your node.
[12:56] <toad_> i just restarted
[12:56] <toad_> show me some long term ones
[12:56] <frog_> okay, put on your toad-shades first...
[12:58] * jay (jcl@ool-18bf6dac.dyn.optonline.net) has joined #freenet
[12:59] <frog_> http://mywebpages.comcast.net/jkcorson/FreeNet/5087c.png
[12:59] * frog_ warns, be sure your browser is not caching a previous image
[13:00] <toad_> okay, this is a result of the bug in 5087
[13:00] <toad_> the breakdown of rate limiting between 5087's and 5084's
[13:00] <toad_> you're rejecting a good part of those queries, right?
[13:00] <frog_> nonsense, I use last good build = 5087 for this chart
[13:00] <frog_> this is "as good as it can get" right now :(
[13:01] <toad_> ah
[13:01] <toad_> hrrm
[13:01] <frog_> all my 5087 peers are 'flooded' but I am controlling my queries with MRI , sort of...
[13:01] * FridlekhToo (Fridlekh@4.27.134.106) has joined #Freenet
[13:01] * TheSeeker (Fridlekh@4.27.134.106) Quit (Read error: 104 (Connection reset by peer))
[13:01] * FridlekhToo is now known as TheSeeker
[13:02] <toad_> but if it's ticking along, then mRI will be communicated pretty regularly anyway
[13:02] <frog_> no, if i let 5084 in the door, you wouldn't see the query plot because it would be off the top of the chart
[13:02] <frog_> mRI more frequent is good. The values of mRI is bad (needs some dampening)
[13:02] <toad_> it has dampening
[13:02] <toad_> it's fairly thoroughly damped
[13:03] <toad_> damping it more will only result in hourly cycles instead of 10 minutely cycles
[13:03] <frog_> well it needs more !! anyway, go do your thing ...
[13:03] <frog_> i will give you an alternate implementation for it...
[13:03] <toad_> we need to find out what the REASON is
[13:04] <toad_> connected peers rising VERY slowly
[13:04] <toad_> that's the other interesting thing on that graph
[13:04] <frog_> the REASON is that some nodes are *used* for local requests. end of store.
[13:04] <frog_> "eee"
[13:04] <jay> i got the source for jdk 1.4.2 but haven't so far been able to compile it
[13:04] <toad_> frog_: what is that the reason FOR?
[13:04] <toad_> it is not the reason for the oscillations
[13:05] <jay> i've noticed Sig 11's when using the Java BigInt code, and *not* when using the native code
[13:05] <frog_> yes, it is. in an indirect manner.
[13:05] <toad_> no, it's not
[13:05] <frog_> go produce a 5088 :)
[13:05] <toad_> it's the reason that the values are nonzero
[13:06] <frog_> then we can argue some more :)
[13:06] * toad_ committing
[13:06] <jay> those from the same specie shouldn't argue
[13:07] <jay> frog_==FrogMan ?
[13:11] <toad_> yes
[13:12] * toad_ does final testing...
[13:12] <jay> to compile the JSDK, i have to get tools from RedHat 6.1 otherwise it won't work
[13:13] <jay> great eh?
[13:13] <toad_> :)
[13:14] <jay> dont worry i got it all under control ;)
[13:17] * frog_ (~chaziller@pcp403292pcs.mntcrm01.md.comcast.net) Quit (Remote closed the connection)
[13:17] * frog_ (~chaziller@pcp403292pcs.mntcrm01.md.comcast.net) has joined #freenet
[13:20] <toad_> okay, lets do it...
[13:21] <frog_> our argument ??
[13:21] * toad_ updating snapshots...
[13:21] <jay> yeah the battle
[13:21] <jay> it's on
[13:21] <toad_> announcement mail is written
[13:23] <toad_> frog_: what were you saying again?
[13:24] <frog_> okay, reload that image (i changed it) ...
[13:24] <Iakin3> Ahh.. Sun accepted my bug report
[13:24] * lolo-laptop restarts his unstable-code-node pretending to be 5088 now
[13:24] <jay> ugh
[13:24] <Iakin3> Minor documention issue only
[13:24] <toad_> hmmm
[13:24] <toad_> what happened at the end? a restart?
[13:25] <jay> should a RouteNotFound be treated as a "retry attempt" or should it not count as a retry ?
[13:25] <frog_> nope, just normal behavior. I am not browsing or anything...
[13:25] <toad_> well the outRI is completely different at the end...
[13:25] <toad_> jay: in what?
[13:25] <jay> toad_: on a ClientPut
[13:26] <jay> in fcpput
[13:26] <frog_> toad_ study the graph, and decide whether you agree that green (our MRIs out) is controlling the brown...
[13:26] <toad_> jay: probably not, but it should result in increasingly long delays/rate reductions...
[13:26] <toad_> frog_: it looks like it
[13:27] <jay> toad_: so the client should just keep trying then
[13:27] <toad_> it looks like increasing oscillations...
[13:27] <toad_> jay: perhaps
[13:27] <toad_> jay: but it should slow down if it repeatedly gets RNFs
[13:27] <jay> the client should?
[13:27] <toad_> yes
[13:27] <frog_> i believe that rate control is working just great. Too great. Green is capped at 60 on the graph...
[13:28] <jay> it's a single threaded insert.. 1 block at a time
[13:28] <jay> slow down the transmission of the data?
[13:28] <toad_> slow down retries?
[13:28] <jay> ah ok
[13:28] <toad_> just have a pause before trying again, starting at 100ms, and increasing by 20% on every consecutive RNF?
[13:28] <toad_> up to some limit...
[13:29] <jay> i haven't coded anything for that
[13:29] <toad_> well otherwise keep it as a retry
[13:29] <toad_> i don't suppose it really matters with only fetching one block at a time
[13:29] <jay> there's space for it to work like that.. it'll be on my relatively short TODO
[13:29] <frog_> toad_ notice how small of a change in green can affect brown in a dramatic way. And don't ignore how brown also drives the backoff (orange).
[13:30] <toad_> yeah, incoming queries seems to drive backoff
[13:30] <toad_> although not as clearly
[13:30] <toad_> okay, I'll go through the current calculation with you
[13:30] <frog_> that's okay, we know the theory. Now, my major problem with this graph is that green gets too close to zero, not that it wiggles too much.
[13:30] <toad_> I'm giving you an hour, after that I've got to go fix a computer
[13:31] <frog_> is almost done.
[13:31] <toad_> eh?
[13:31] <toad_> my main problem with that graph is that green appears to be on a pattern of increasing oscillations
[13:31] <toad_> btw re backoff have you tried turning on the KenMan hack lately?
[13:31] <frog_> you mean, the peaks and dips of green get closer together towards the end ?? i don't really see that when taking the full graph into consideration
[13:32] <toad_> globalQuota is following outRI, correct?
[13:32] <toad_> frog_: the peaks get gradually higher
[13:32] <frog_> not sure, i don't watch that (and probably should for you)
[13:32] <toad_> with the exception of the last bit
[13:33] <toad_> might be something to do with connected peers
[13:33] <toad_> but i doubt it
[13:33] <toad_> what sort of values are we dealing with here for outRI?
[13:33] <frog_> the thing that disturbs me most is the degree of change in the brown line. And when green goes 'too low' brown goes 'too high'
[13:33] <frog_> 10 = 100s on the graph
[13:33] <frog_> 60 (600s) is the max
[13:33] <toad_> okay
[13:33] <frog_> i scaled it to make them viewable together...
[13:34] <toad_> you don't have the reporting bug fix do you?
[13:34] <toad_> we were reporting -1's on the average...
[13:34] <toad_> but then that's irrelevant if we're only dealing with 5087's
[13:34] <toad_> since we won't report any -1's in that case
[13:34] <toad_> hrrm
[13:34] <toad_> still, the obvious thing is to disable the limit
[13:35] <frog_> which limit ?
[13:35] <toad_> it probably produces bad effects
[13:35] <toad_> PeerHandler.getRequestInterval
[13:35] <frog_> you are focused on the wrong end of the spectrum...
[13:35] <toad_> L1619 in the source after the 5088 commit
[13:35] <frog_> i would be happy (and you would be sick) if we set a minimum value for MRI that was farther away from 0.
[13:35] <toad_> I suspect that the MRI limit of 600,000ms is causing problems
[13:36] <frog_> no, it manages to slam queries to nothing with 600s ... see the end of graph ??
[13:36] <toad_> individual MRIs will be over it, even if as a whole it isn't
[13:36] <toad_> frog_: yes but individual MRIs != all MRIs
[13:36] <frog_> the problem is when mri goes 'too low'
[13:36] <toad_> they are different for each node
[13:36] <frog_> i know, this graph keeps it simple
[13:37] <frog_> and 'big picture' when focused on query levels
[13:37] <toad_> globalQuota would be interesting
[13:37] <toad_> probably it follows outRI
[13:37] <frog_> where shall i capture that from ?
[13:37] <frog_> 'Network Load' ?
[13:37] <toad_> globalQuota
[13:37] <toad_> there's a diagnostic for it
[13:37] <frog_> ah, okay.
[13:37] <toad_> just grab the average from the diag
[13:38] <frog_> good. will do. are we on a similar page yet (i'm done "arguing") ? ;)
[13:38] <toad_> well, it's oscillating
[13:38] <toad_> why is it oscillating?
[13:38] <frog_> wait, exactly *what* is oscillating ??
[13:38] <toad_> MRI starts at 0, because we don't record the last time's data
[13:38] <toad_> frog_: everything. the MRI, the received queries.
[13:39] <toad_> then we get tons of queries, because MRI is crazy
[13:39] <toad_> then our load spikes, so we increase the MRI
[13:39] <toad_> and the queries reduces
[13:39] <toad_> why do we overcompensate?
[13:39] <toad_> our load goes down too far, and we send very low MRIs, and we get tons of queries again :<
[13:40] <frog_> we are on the same page now
[13:40] <toad_> now, this should be prevented by the 10 minute half-life averaging we have everywhere
[13:40] <toad_> right?
[13:40] <frog_> the MRI does not oscillate in the manner that queries do - what i mean is, queries go from all to none (or pretty dramatic magnitude changes anyway) but out-MRI drifts fairly smoothly...
[13:40] <frog_> not necessarily...
[13:40] <toad_> we don't have falling-out-of-the-running-average errors
[13:40] <toad_> because it's a half-life based thing
[13:40] <toad_> queries are ~ 1/MRI. there's a slight time lag, but it's very slight.
[13:41] <toad_> well okay
[13:41] <toad_> here's the real question
[13:41] <frog_> yes that relationship exists. now to make it 10/mri , or somehow tone down the degree of effect MRI is having on queries :)
[13:41] <toad_> why when queries are increasing, does MRI continue to decrease?
[13:41] <toad_> e.g. the first time MRI falls on the chart
[13:41] <frog_> perhaps MRI is much slower to react to queries than vice versa...
[13:42] <toad_> uh, so what?
[13:42] <toad_> hmmm
[13:42] <toad_> are you saying that the queries should be averaged over the very short term?
[13:42] <toad_> instead of over the long term?
[13:43] <frog_> possibly. i don't know. I am only a figment of your imagination, here to help you.
[13:43] <toad_> so help me :)
[13:43] <frog_> :)
[13:43] * TheSeeker (Fridlekh@4.27.134.106) Quit (Read error: 60 (Operation timed out))
[13:44] <frog_> my knee-jerk reaction would be to tone down (dampen without using past history) the MRI changes, but as we just figured out, that may be very difficult.
[13:44] <toad_> very
[13:45] <frog_> well, i take back that 'past history' part. But it should be a *very simple* dampening method.
[13:45] <toad_> well, we have several damping methods already
[13:45] <toad_> we have to decide why they don't work
[13:45] <toad_> not bolt something new on
[13:45] <frog_> anyway, i'm done bothering you for know, just think about these things while you do other work...
[13:45] <toad_> grrr! we've got NOWHERE!
[13:46] <frog_> an answer will come to you ... I will go make more pretty graphs...
[13:46] <toad_> I doubt it
[13:46] <frog_> I may try something on my own...
[13:46] <frog_> and share if it looks meaningful / helpful for analysis
[13:47] * i2p_iip (~changate@host.teitel.net) Quit (Remote closed the connection)
[13:47] * toad_ wonders if the request counters are biased towards returning low values... hrrm
[13:47] <frog_> the key is in those MRIs. They are smooth in the graph because they are averaged. But you were right when you said 'individually they are screwed'
[13:47] * i2p_iip (~changate@host.teitel.net) has joined #freenet
[13:47] <toad_> we have a half-life-based running average of the time between requests, essentially
[13:47] <toad_> maybe it should be of the requests per hour instead?
[13:48] <frog_> that is an interesting idea, i like it anyway...
[13:49] <frog_> eventually we want to get that brown line as flat as possible (unfluctuating load) ...
[13:49] <frog_> and we do have the power to shape that line, with our MRI-gun ...
[13:50] * frog_ is now known as KenMan
[13:50] <toad_> well, that, and the PeerHandler mod (take out the "|| minRequestInterval > 600 * 1000")...
[13:50] <toad_> you want a jar?
[13:50] <toad_> a patchset?
[13:51] * KenMan goes to fetch an early lunch...
[13:51] <toad_> KenMan: !!
[13:52] <toad_> KenMan: do you want me to email you a patchset?
[13:52] <KenMan> hey toad, what's up ??
[13:52] <KenMan> i will switch over to 5088 and collect that globalquota stuff, unless you have a better use for me ...
[13:52] <toad_> KenMan: do you want me to email you a patchset? if so, where to?
[13:52] <KenMan> a patchset of what ?
[13:53] <toad_> turning off the maximum MRI, and averaging the rate rather than the time between reports
[13:53] <toad_> i'm not about to commit it to stable, but testing would be interesting
[13:53] <KenMan> oh, well, whichever you want me to graph, either way...
[13:53] <toad_> also it'd be useful to test with kenmanhack enabled
[13:53] <toad_> (separately)
[13:56] <KenMan> has anybody seen sanity walking past that webcam on the DEFCON floor ? man, he looks so drunk !!
[13:57] * toad_ sent, with instructions
[13:57] <toad_> bbiab
[13:57] * KenMan 's stomach is growlling
[13:57] <toad_> ttyl
[13:57] <KenMan> see you soon
[13:58] * Hory (~Miranda@81.196.25.110) has joined #FreeNet
[14:03] * toad_ back
[14:03] <toad_> rehi KenMan
[14:11] <toad_> KenMan: okay, that change was definitely broken
[14:13] * Lux (~Lux@82-37-17-24.cable.ubr03.wolv.blueyonder.co.uk) has joined #freenet
[14:14] <toad_> hi Lux
[14:14] <Lux> Hey :)
[14:14] <Lux> ive set my laptop up to be a node, glad the new stable one is out
[14:15] * toad_ is trying to debug oscillations... http://mywebpages.comcast.net/jkcorson/FreeNet/5087c.png
[14:23] * Tailchaser (~tailchase@pool-68-162-16-41.nwrk.east.verizon.net) has joined #freenet
[14:24] <toad_> okay...
[14:24] <toad_> my stable node doesn't oscillate
[14:24] <toad_> because a) it has significant cpu overhead, so bandwidth isn't the main cost and b) KenManHack is enabled
[14:25] <KenMan> so toad, do use your jar / patch, or no ??
[14:25] <toad_> KenMan: no
[14:25] <toad_> but do use plain 5088
[14:25] <KenMan> okay. Moving to 5088 :)
[14:26] <toad_> also I strongly suspect that KenManHack has something to do with my lack of oscillation
[14:26] <toad_> the delayed effect of bandwidth usage perhaps
[14:27] <KenMan> well, it does have the effect of reducing queries pretty strongly...
[14:27] <toad_> actually that's something else you can show on the graph... rateLimitingLoad
[14:27] <KenMan> oh no, 2 things to add ? globalQuota and rateLimitingLoad. Okay.
[14:27] <toad_> KenMan: true, however, I've seen 10kqph on stable with KenManHack enabled
[14:27] <toad_> if I tune down the logging
[14:27] <KenMan> bleechhh
[14:27] <toad_> what do you see without it?
[14:28] <toad_> what's your typical hourly localQueryTraffic value?
[14:28] <KenMan> i don't know. For many months now, my node is happiest with about 1200qph
[14:28] <KenMan> but then I usually set 75 peers, don't know if that matters...
[14:28] <toad_> that's probably about right if many of them succeed
[14:28] <toad_> well what did you get over the course of that graph?
[14:28] <toad_> well, 60 queries per minute would be about 3kqph
[14:29] * thelema|away is now known as thelema
[14:29] <thelema> hi all
[14:29] <toad_> hmmm
[14:29] <toad_> hi thelema
[14:29] <toad_> thelema: http://mywebpages.comcast.net/jkcorson/FreeNet/5087c.png
[14:29] <Lux> hi
[14:29] <toad_> thelema: interesting graph (reload it, it's changed)
[14:29] <thelema> what just happenned?
[14:29] <toad_> thelema: hmm?
[14:30] <thelema> in that graph
[14:30] <thelema> there's a distinct crunch in the last hour
[14:30] <toad_> KenMan: my KenManHack-enabled node seems to be settling to around 1000qph...
[14:30] <toad_> thelema: yeah, I know
[14:30] <toad_> no idea
[14:30] <KenMan> ... just normal ops, no browsing here
[14:30] <toad_> but the rest of the graph is quite interesting too!
[14:30] <thelema> where incoming requests drop to blah and out mRI goes way high
[14:30] <toad_> the last bit might be an artifact of the maximum limit on MRI
[14:30] <thelema> The rest of the graph indicates that the current mRI system isn't good at finding a stable state.
[14:31] <toad_> thelema: exactly
[14:31] * luckypunk (luckypunk@CPE000625f49f20-CM014320105752.cpe.net.cable.rogers.com) has joined #freenet
[14:31] <toad_> it's oscillating, and it's not clear why
[14:31] <luckypunk> hi toad
[14:31] <toad_> here's something interesting: if bandwidth is taken out of the equasion (by accepting radically less queries, the KenManHack), we don't oscillate
[14:31] * KenMan refreshs the graph up to the minute. You can see it before he does :)
[14:31] <toad_> hi luckypunk
[14:31] * Blacky882 (~VIP@rsteam.org) has joined #freenet
[14:31] <Blacky882> hello
[14:31] <thelema> toad_: most likely strings of successes make mRI go up and thus incoming requests go down.
[14:32] <Blacky882> is this support channel for freenet6 ?
[14:32] <thelema> by successes, I mean successful inserts/requests
[14:32] <toad_> Blacky882: no, freenetproject.org
[14:32] <thelema> Blacky882: no, freenetproject.org
[14:32] <Blacky882> ok sorry
[14:32] <toad_> Blacky882: which does not at present support IPv6
[14:32] <thelema> brb
[14:32] <Blacky882> ok
[14:32] <Blacky882> sorry
[14:32] <toad_> KenMan: how much time is the few pixels at the beginning before green starts to rise?
[14:32] <toad_> Blacky882: :)
[14:33] <toad_> Blacky882: you can stay if you like :)
[14:33] <KenMan> sorry, i didn't mean that I'm updating the graph regularly, just that 'i just did it and it is fresh'
[14:33] <Blacky882> tnx
[14:33] <KenMan> look at the ticmarks on the x axis for time reference
[14:34] <toad_> KenMan: it'd be REALLY interesting to have globalQuota on the graph
[14:34] <toad_> I'm coming to an interesting suspicion...
[14:34] <toad_> I suspect that globalQuota and outgoingRequestInterval are less strongly correlated than outgoingRequestInterval and localQueryTraffic
[14:35] <toad_> my globalQuota is pretty stable
[14:35] <toad_> but my oRI isn't
[14:35] <toad_> now, I suppose this could be because of a sudden spike in # conns...
[14:35] <toad_> but otoh...
[14:36] <thelema> back
[14:36] <Lux> Yay i can finally access TheContentOfEvil :D after only 10 hours!
[14:36] <toad_> oRI just rose significantly
[14:36] <toad_> localQueryTraffic is significantly down
[14:37] <toad_> globalQuota does seem to be falling... but not THAT fast..
[14:37] <toad_> and it's not caused by rateLimitingLoad either
[14:37] * i2p_iip (~changate@host.teitel.net) Quit ("Leaving")
[14:37] <thelema> the latest change could be normal node behavior in the case that a number of large transfers succeeded...
[14:38] <thelema> i.e. that last hour of graph.
[14:38] <thelema> It's not a bunch of new nodes.
[14:38] <toad_> thelema: that could also explain the oscillations...
[14:38] <toad_> but only if there's a HUGE time lag
[14:38] <toad_> that's possible with inserts...
[14:38] <thelema> Which is one reason I'm for data chording.
[14:38] <toad_> probably not with requests
[14:39] <toad_> they don't generally take that long
[14:39] <thelema> or that requests go really slowly.
[14:39] <toad_> do they
[14:39] <toad_> ?
[14:39] <thelema> 1K/s is an amazing speed.
[14:39] <thelema> well, on average...
[14:39] <toad_> thelema: check your successTransferRate...
[14:39] <thelema> many people have 90 active trailers on a 50K/s link
[14:39] * greycat changes topic to 'Freenet: Taming the World's Largest Tamagotchi | Upgrade to 5088 | Unstable: Upgrade to 60172 | Logs: http://newton.matcmp.ncc.edu/~lockej/freenet/chanlog/'
[14:40] <thelema> don't forget that failed xfers take up bandwidth too.
[14:40] <toad_> thelema: the transfers that succeed usually get good rates
[14:40] <toad_> the rest are either misreported, or are inserts
[14:40] <toad_> which fail far more often
[14:40] <thelema> so it could be a bunch of inserts.
[14:40] <thelema> someone inserting an ISO or something.
[14:40] <toad_> yeah, it could be inserts... inserts can take aaages...
[14:40] <toad_> not as long as they used to but still they can use up a great deal of bandwidth...
[14:41] <thelema> I don't have a node I can get at; what's a reasonable value for successTransferRate?
[14:42] <toad_> my last few daily averages:
[14:42] <toad_> 14310.65105087538
[14:42] <toad_> 14211.337574220603
[14:42] <toad_> 8970.314751142978
[14:42] <toad_> 9311.348869096364
[14:43] <toad_> 8243.182544441994
[14:43] <toad_> 3747.190316749942
[14:43] <toad_> those days are spread out over a significant period
[14:43] <toad_> about a month...
[14:43] <toad_> april...
[14:43] <thelema> 14K/s? really?
[14:43] <toad_> it was a while ago
[14:44] <toad_> probably that would be 5084
[14:44] <toad_> 14kB/sec averaged over 300 reports that day
[14:44] <toad_> for two days
[14:44] <toad_> okay
[14:44] <toad_> CPU is pegged
[14:45] <KenMan> average success keysize didn't change much. 17:00-18:00=(353036*75xfers) versus 16-17:00=(433987*56)
[14:45] <toad_> localQueryTraffic is practically nil
[14:45] <thelema> that's not as bad as I thought. Failed xfers must take a while to fail...
[14:45] <toad_> sod, it just finished... now CPU is no longer pegged...
[14:45] <toad_> aha
[14:45] <toad_> it was just compressing the logfile
[14:46] <toad_> now, the question is, is it going to keep falling...
[14:46] <toad_> ?
[14:46] <toad_> oh sh*t
[14:47] <toad_> well
[14:47] <toad_> if the incoming traffic falls
[14:47] <toad_> and the rateLimitingLoad stays about the same...
[14:47] <toad_> then globalQuota will continue to decrease...
[14:47] <KenMan> toad_ the reason your successTransferRate went high is that your no. of peers went low (perhaps?)
[14:47] <toad_> KenMan: i don't think so
[14:48] <toad_> but that was aaages ago
[14:48] <toad_> and we don't keep # peers
[14:48] <toad_> KenMan: I think the inertia in the system is actually causing problems...
[14:49] <toad_> no, that can't be right
[14:49] <toad_> if localQueryTraffic falls while rateLimitingLoad is roughly the same, the averages conspire to keep it falling
[14:50] <toad_> until rateLimitingLoad averages out to <= 1.0 again
[14:50] <toad_> the solution?
[14:50] * shendaras (~shendaras@ip68-97-113-208.ok.ok.cox.net) has joined #freenet
[14:50] <toad_> don't average rateLimitingLoad on input
[14:50] <toad_> and then super-average the output instead...
[14:51] <toad_> of course, estimatedIncomingRequestsPerHour IS necessarily an average...
[14:51] <toad_> question: should it be a long term one?
[14:51] <toad_> I suppose it ought to be the same term as the individual node ones...
[14:52] * Blacky882 (~VIP@rsteam.org) has left #freenet
[14:54] <toad_> KenMan: opinions?
[14:54] <toad_> thelema: opinions?
[14:54] <KenMan> none at the moment. sorry :(
[14:55] <toad_> if we average the load, and an external stimulus appears, which causes localQueryTraffic to fall slowly, with the load at approximately the same value, but slightly over 1.0
[14:55] * Lux is lost, but thinks he is learning a lot from reading this.
[14:55] <toad_> then the external stimulus is taken away
[14:55] <toad_> then the globalQuota will CONTINUE TO FALL
[14:55] <toad_> for as long as it takes for the load average to fall to 1.0
[14:55] <toad_> even though the load is now under 1.0
[14:56] <toad_> this would explain what we see on KenMan's graph!
[14:56] <toad_> at least some of it...
[14:59] <toad_> now if we take out that averaging, then we surely want to average the output
[15:00] <thelema> I'm all for nodes being less jumpy and more predictable
[15:00] <thelema> (at least over a period of a day or two)
[15:00] <toad_> thelema: well, here the problem is averaging in the wrong place...
[15:01] <toad_> ahhh
[15:01] <toad_> I'm not using the KenManHack on my stable node
[15:01] <toad_> I thought I was
[15:01] <toad_> oh well
[15:01] * shendaras (~shendaras@ip68-97-113-208.ok.ok.cox.net) Quit (Read error: 104 (Connection reset by peer))
[15:01] <KenMan> should I ? I think plain 5088 would be best here.
[15:01] * toad_ turns it off on unstable too
[15:02] <toad_> KenMan: I may have a new jar for you soon
[15:02] <Lux> whats this hack do?
[15:02] <thelema> Lux: limits load based on expected % of successful requests
[15:02] <Lux> ok
[15:02] <KenMan> toad_ I leave in about an hour, so I'll start a graph then. Gets you a full day's worth of pixels for tomorrow.
[15:03] <toad_> okay
[15:03] <toad_> I'll send you
[15:03] <toad_> diff and jar
[15:03] <KenMan> please take your time !
[15:03] <toad_> this is with turning off averaging on the load, and enabling averaging on the output globalQuota
[15:04] <KenMan> globalQuota looks pretty smooth per minute, but that's just my 2cents...
[15:04] * Lux (~Lux@82-37-17-24.cable.ubr03.wolv.blueyonder.co.uk) has left #freenet
[15:04] <toad_> KenMan: well, definitely include it on the graph
[15:04] <toad_> I'll send you a jar and diff, and if it changes, I'll just send you another one
[15:04] <KenMan> I just added your two requested variables.
[15:05] * KenMan is ready to start whatever, whenever... patience is a virtue for our CodeMonkey as well as our users ;)
[15:05] * shendaras (~shendaras@ip68-97-113-208.ok.ok.cox.net) has joined #freenet
[15:07] <toad_> okay, checked, sent it
[15:07] * xena (~xena@espians.com) has joined #freenet
[15:11] * tav_ (~tav@espians.com) has joined #freenet
[15:12] <toad_> okay, so it emulates... as long as load is high, keep reducing the traffic level slightly...
[15:12] <wind789> the windows installer does indeed update the ext.jar thing
[15:12] <toad_> wind789: excellent
[15:13] * tav_ is now known as tav|offline
[15:13] <toad_> okay, so the only major difficulty now is... we should have the half-life at least the expected time for a request to complete...
[15:13] <toad_> well not necessarily...
[15:13] <toad_> but there should be some relation between the two...
[15:15] <toad_> according to stats... search failures are pretty quick
[15:15] <toad_> so it's transfers that are the issue
[15:15] <toad_> Lowest global transfer rate estimate 2,361 bytes/second
[15:15] <toad_> Highest global transfer rate estimate 4,170 bytes/second
[15:15] <thelema> how long for a search failure?
[15:16] <toad_> if we assume a grossly pessimistic 1kB/sec, which is just under half the minimum estimate (i.e. key specific average) currently seen on my node, then requests should generally last less than 1100 seconds or so
[15:16] <toad_> Lowest global search time estimate 12723.0ms
[15:16] <toad_> Highest global search time estimate 63540.0ms
[15:16] <toad_> Single hop average time for search timeout 3388.5045108248546
[15:16] <thelema> freenet-unstable-muxnet.jar <- this can be removed from snapshots directory
[15:16] <toad_> it can indeed
[15:16] * toad_ deals with it
[15:17] <thelema> average time 3s? What's taking it?
[15:17] * KenMan suspects toad is on the verge of the 'stable release to quash the previous 100 releases'
[15:17] <KenMan> can I nickname it if happens ??
[15:18] <toad_> what's kio-freenet* ?
[15:18] <toad_> also what's fish-compat-freenet-ext.jar ?
[15:18] <shendaras> Single hop average time for search timeout 10556.502335873576
[15:18] <KenMan> KIO=Killer Io. It was Iakin's attempt to improve the NIO code, maybe.
[15:18] <toad_> may i kill it? :)
[15:18] <KenMan> probably :)
[15:19] * toad_ would have to talk to iakin about it
[15:19] <KenMan> unless it is already dead :o
[15:19] <toad_> well its corpse is on snapshots
[15:19] <thelema> 18 july... it's not that old.
[15:19] <toad_> snapshots is quite limited on space...
[15:19] <toad_> 18 july of what year?
[15:19] <thelema> oops, 2002
[15:20] <thelema> it is that old.
[15:20] <KenMan> move it to your home PC, see who balks... (that's how they handled security at my old job - take it away, see who cries)
[15:20] <jay> kio-freenet
[15:20] <KenMan> kaffe related then ?
[15:20] <jay> kde IOslave i wrote using the old buggy ezFCPlib
[15:20] * wind789 (wind789@6532175hfc51.tampabay.rr.com) Quit ()
[15:20] <toad_> okay, so any opposition to making the maximum half-life 1000 seconds?
[15:20] <toad_> for all the stats code?
[15:20] <toad_> or even 1100?
[15:21] <KenMan> what was is it currently ?
[15:21] <toad_> that would hopefully prevent oscillations caused by requests taking insane time periods to finish
[15:21] <toad_> KenMan: 5 minutes, totally arbitrary
[15:21] <toad_> = 300 seconds
[15:21] <KenMan> yeah, biggen it up !
[15:21] <jay> KenMan: it allowed you to browse freenet within kde's web browser using FCP without fproxy
[15:21] <KenMan> oh, cool !
[15:21] <jay> it worked in a limited way
[15:22] <toad_> 1100 seconds would give it space for the tiny fraction of successful requests that do 1kB/sec
[15:22] <jay> im going to update it when fcpget is working better
[15:22] <toad_> of course in practice, some requests will be even slower...
[15:22] <KenMan> jay: then just keep it in source form, in CVS... for now.
[15:22] <Iakin> Toad, from the NIO book 'The idea is that only keys in the selected set are considered to have legitimate readiness information'
[15:23] <jay> KenMan: it's in kdenonbeta right now
[15:23] <thelema> 1100 seconds seems good.
[15:23] <jay> KenMan: kde's source tree
[15:23] <toad_> Iakin: okay, so what we want is to mark stuff introduced by fix
[15:23] <toad_> Keys
[15:23] <toad_> and IF it has a successful read, THEN log an error message
[15:23] <toad_> if not, we're just being paranoid
[15:23] <toad_> and we can get rid of it
[15:23] <toad_> right?
[15:23] <Iakin> Toad, the ready set of a key is updated only when it is added to the selected set..
[15:24] <Iakin> So.. the non-selected keys might contain stale readiness information..
[15:24] <toad_> Iakin: I'm sure we've had missed reads/writes cured by fixKeys
[15:24] <Iakin> [18:45] <i2p_iip> <Newsbyte> I got this as email :'I can't get the IP address to download FNC ! Where could I get this
[15:24] <jay> KenMan: you want to delete it from snapshots? go ahead
[15:24] <toad_> if I do the above, we can be reasonably confident that it's working, when/if we get rid of the code
[15:25] <Iakin> Help him NB, he really needs it ;)
[15:25] <jay> newsbyte? needs help?
[15:25] <jay> i don't believe it
[15:25] * thelema is now known as thelema|away
[15:28] * toad_ restarts with new code...
[15:33] <KenMan> this is getting real busy, but here is a preview of what it will look like : http://mywebpages.comcast.net/jkcorson/FreeNet/5087c2.png
[15:33] <jay> is iip online?
[15:34] <KenMan> jay - outlook is bad
[15:34] <toad_> jay: there's a new IIP...
[15:34] <toad_> KenMan: on the basis of that... globalQuota is indeed playing a big part
[15:34] <jay> i can't connect right noq
[15:34] <jay> now
[15:34] <toad_> that bodes well for my recent mods...
[15:34] <toad_> jay: the new IIP network or the old one?
[15:34] <KenMan> I haven't restarted yet :(
[15:34] <jay> so there's another new iip
[15:34] * guido^pe (~unknown@dsl-213-023-238-076.arcor-ip.net) has joined #freenet
[15:35] * TheSeeker (~Fridlekh@4.27.134.106) has joined #Freenet
[15:35] <jay> i updated to the 'new' IIP maybe 2 months ago
[15:35] <jay> maybe more recent
[15:35] <jay> so there's one after that?
[15:35] <toad_> KenMan: one interesting thing to come out of all this... Freenet is definitely dealing with far too long timescales. Mostly because the files are too big, IMHO.
[15:36] <toad_> it may work for 24x7 nodes... reasonably...
[15:36] <toad_> but it won't work for newbies, and it won't work for people who only run 5 hours a day
[15:36] <KenMan> fixed key sizes will be neat. Then we will need to measure the overhead more accurately, which you already started with tcpdump :)
[15:36] <toad_> hehe
[15:36] <toad_> well, tcpdump isn't really for measuring overhead
[15:36] <toad_> but we do need binary presentation
[15:36] <KenMan> no, but it got you looking there ;)
[15:36] <toad_> hopefully thelema will pull a rabbit
[15:37] <toad_> [out of a hat, not the other pull...]
[15:37] <KenMan> I hope so !! Hops hasn't been pulled for a long time... Oh. Too late for that joke
[15:37] <KenMan> :p
[15:38] <KenMan> okay, i restart now with the jar you've given me
[15:39] <KenMan> this is getting scary - hitting something like 12 diag pages /min in order to get the data to chart :o
[15:42] <KenMan> maybe I will square the graphed rateLimitingLoad values, so that fluctuations are more visible...
[15:42] <KenMan> and shift it up above all the other clutter
[15:43] <KenMan> anyway, neat graphs to share tomorrow (fingers are crossed)...
[15:47] <toad_> the question is whether it will stop the looping
[15:47] <toad_> or whether it will simply get really long loops
[15:47] * Tailchaser (~tailchase@pool-68-162-16-41.nwrk.east.verizon.net) has left #freenet
[15:52] * interrupt (~chatzilla@64.122.23.213) has joined #freenet
[15:56] <Iakin> [19:51] <toad_> L1619 in the source after the 5088 commit
[15:56] <toad_> Iakin: ?
[15:56] <toad_> Iakin: oh, what's kio?
[15:56] <toad_> can i get rid of the kio stuff in snapshots?
[15:57] <Iakin> Hmmm.. L1600.. now.. _good_ coding standard is to keep classes < 200 lines or so ;)
[15:57] <jay> toad_: kio-freenet?
[15:57] <toad_> jay: yes
[15:57] <toad_> it's old, that's about all i know about it...
[15:58] <jay> nobody thought to check the owner of the file itself?
[15:58] <jay> -rw-rw-r-- 1 joliveri users 564489 Jul 18 2002 kio_freenet-20020718.tar.bz2
[15:58] <toad_> ahhh
[15:58] <toad_> doh
[15:58] <jay> it's old but you can delete it
[15:58] <toad_> okay, what is it, can i get rid of it?
[15:58] <jay> it'll reappear in a couple of months tho
[15:58] <toad_> hmmm
[15:58] <toad_> what IS it?
[15:59] <jay> it's a kde ioslave for freenet using fcplib
[15:59] <toad_> oooh
[15:59] * toad_ leaves it there then
[15:59] <toad_> does it work?
[15:59] <jay> it worked back then
[15:59] <jay> McNab's old fcplib sucked tho
[15:59] <jay> so it broke constantly
[16:00] <jay> im almost ready to update it with the new fcplib once i complete the DBR crap for ClientGet
[16:00] <jay> then you can browser freenet in konqueror
[16:00] <toad_> other than via fproxy
[16:00] <jay> yeah
[16:00] <toad_> of course, it won't support filtering etc
[16:00] * toad_ thinks we should expose that via FCP
[16:01] <jay> yeah filtering
[16:01] <jay> that's a tough one
[16:01] <jay> where to ideally put it
[16:01] <toad_> no need for every client author to implement their own
[16:01] <toad_> we should provide it as an FCP call
[16:02] <jay> is the filtering straight forward?
[16:02] <jay> i've never seen it in fproxy
[16:02] <toad_> not especially...
[16:03] <toad_> hmmm
[16:03] <toad_> the last 8 minutes have an outputBytes range of 624824 to 628092
[16:03] <toad_> pegged the output limit, in other words...
[16:04] <toad_> it takes a while for high level limiting to have an effect...
[16:04] <toad_> rateLimitingLoad has been 130% for some time...
[16:05] <Iakin> [21:34] <KenMan> KIO=Killer Io. It was Iakin's attempt to improve the NIO code, maybe.
[16:05] <Iakin> [21:34] <toad_> may i kill it? :)
[16:05] <Iakin> [21:34] <KenMan> probably :)
[16:05] <Iakin> [21:35] * toad_ would have to talk to iakin about it
[16:05] <Iakin> FFS, dont blame me
[16:05] <Iakin> I've never heard of it
[16:05] <toad_> hehe
[16:05] <toad_> bbiab
[16:05] <Iakin> kill it I say
[16:07] <Iakin> [21:39] <toad_> and IF it has a successful read, THEN log an error message
[16:07] <Iakin> [21:39] <toad_> if not, we're just being paranoid
[16:08] <Iakin> I assume that the channel acutally _might_ be readable.. but the next select should then give it to us
[16:08] <Iakin> Thing is... the readyset might indicate the _previous_ readiness of the channel.. not the nextcoming one
[16:09] <Iakin> [21:40] <toad_> Iakin: I'm sure we've had missed reads/writes cured by fixKeys
[16:09] <Iakin> By sheer luck maybe?
[16:09] <Iakin> And maybe caused by some other bug..
[16:10] <Iakin> Think of it.. fixKeys() will actually sample the set of non-ready keys and pseudorandomly add a few to the readyset..
[16:13] <hirvox> whee, my native fec rpm works :) it's an ugly hack, but it does the job
[16:14] <KenMan> oh man, at startup, globalQuota is WAY up there :( it will come into shape sometime soon though...
[16:14] <KenMan> Iakin, I was just picking on you with that 'KillerIO' crap :)
[16:14] * KenMan ... Away !
[16:15] <hirvox> now I just need to modify my fred RPMs to include it in the classpath
[16:15] <hirvox> afk
[16:16] * TLF (francisco@140.Red-81-40-113.pooles.rima-tde.net) has joined #freenet
[16:33] * Hory (~Miranda@81.196.25.110) Quit (Read error: 104 (Connection reset by peer))
[16:38] * greycat (~wooledg@192.35.79.70) Quit ("Lick Bush in '04")
[16:41] * jay (jcl@ool-18bf6dac.dyn.optonline.net) Quit (".")
[16:41] * Seed212 (wind789@6532175hfc51.tampabay.rr.com) has joined #freenet
[17:00] * Hory (~Miranda@81.196.25.110) has joined #FreeNet
[17:28] * toad_ back
[17:28] <toad_> aha
[17:28] <toad_> it seems to be stabilizing at ~ 1000...
[17:29] <verl> toad: any reports of NPE's while trying to access the ocm?
[17:29] <toad_> verl: recently?
[17:29] <toad_> don't think so
[17:29] <toad_> you got one?
[17:29] <verl> i've been having them in both 5088 and '87
[17:29] <verl> can't access it at all
[17:30] <toad_> verl: gimme stack trace
[17:31] * verl (~verlverl@h165n2fls33o877.telia.com) Quit (Excess Flood)
[17:31] * verl (~verlverl@h165n2fls33o877.telia.com) has joined #freenet
[17:31] <nicktastic> hehe oops
[17:33] * TLF is away: Por ah?, de juerga.
[17:34] * Ash-Fox (Hal-9000@aag33.neoplus.adsl.tpnet.pl) Quit (Nick collision from services.)
[17:34] * Ash-Fox (Hal-9000@aae168.neoplus.adsl.tpnet.pl) has joined #FreeNET
[17:41] * Hory (~Miranda@81.196.25.110) Quit (Read error: 60 (Operation timed out))
[17:46] * TLF is back (gone 00:13:47)
[17:56] <lolo-laptop> Jul 29, 2004 5:13:47 PM (freenet.transport.WriteSelectorLoop, Network writing thread, NORMAL): fixKeys added sun.nio.ch.SelectionKeyImpl@1747703
[17:56] <lolo-laptop> still
[17:58] <toad_> yes
[17:58] <toad_> i know will be fixed next ver
[17:58] <lolo-laptop> ok
[17:58] <toad_> or at least replaced :)
[17:58] <lolo-laptop> :)
[18:00] <toad_> yup, replaced with an even bigger and more annoying message (albeit at NORMAL)
[18:02] * robilad (~topic@mpiat2304.ag2.mpi-sb.mpg.de) Quit (Ping timeout: 14400 seconds)
[18:05] * interrupt (~chatzilla@64.122.23.213) Quit ("Chatzilla 0.9.64b [Mozilla rv:1.7/20040707]")
[18:06] <lolo-laptop> wait, so the cause of the message isn't going away, just getting a new message?
[18:08] <toad_> well we're not sure about the cause of the message...
[18:08] <toad_> but the new message is more specific
[18:08] <toad_> it only happens when more specific things happen :)
[18:08] <toad_> so it should happen less often
[18:09] <lolo-laptop> hehe ok
[18:09] <lolo-laptop> :)
[18:11] * lolo-laptop updates
[18:11] <lolo-laptop> :)
[18:11] <lolo-laptop> I gotta quit smiling so much... people at work look at me funny.
[18:11] <oierw> i get that a lot too
[18:12] <oierw> i now respond to "hey you. the one smiling"
[18:12] <lolo-laptop> haha
[18:12] <oierw> i think it's just a freak of how my face muscles work, or something, because I'm not actually happy all that much
[18:13] <lolo-laptop> hehe, I actually am happy a lot ... that's why I type :) a lot and I smile a lot IRL ... and then people look at me funny and know I'm not actually working and then I have to :-( of :-| for a while :)
[18:13] <lolo-laptop> s/( of/( or/
[18:18] <oierw> when I'm working I generalyl have a bewildered look on my face, or so I guess from other's people comments about me
[18:19] * Pascal (Pascal@c-24-13-17-191.client.comcast.net) Quit ()
[18:20] <nicktastic> Be on the lookout for terrorists with pinkeye and leprosy. Also, they tend to rub their hands together manically.
[18:26] * TLF (francisco@140.Red-81-40-113.pooles.rima-tde.net) Quit ("http://www.vitaliano.esp.cc || Adi?s a todos y a todas y que les vaya bien.")
[18:38] <mikeDOTd> 22 hours uptime, 84 open connections (and a 400% est. load for rate limiting)
[18:39] <mikeDOTd> ^ 5077
[18:39] <mikeDOTd> err, 5087
[18:42] * mikeDOTd reads his email and notes the changes in 5088
[18:42] * nicktastic (~nicktasti@c-67-163-227-74.client.comcast.net) Quit ()
[18:43] * nicktastic (~nicktasti@c-67-163-227-74.client.comcast.net) has joined #freenet
[18:51] <lolo-laptop> hmm... I have 83 connections in about 30 minutes...
[18:53] * Lux (~Lux@82-37-17-24.cable.ubr03.wolv.blueyonder.co.uk) has joined #freenet
[18:57] * guido^pe (~unknown@dsl-213-023-238-076.arcor-ip.net) Quit (Remote closed the connection)
[18:58] * Connelly (Default@c-24-21-147-63.client.comcast.net) has joined #freenet
[18:59] <Connelly> i was reading the Freenet wikipedia article
[18:59] <Connelly> " due to a mature network's intelligent routing a network of size n should only require log(n) time to retrieve any given document"
[18:59] <Connelly> http://discolab.rutgers.edu/classes/cs672/slides/FreeNet672Presentation.ppt
[18:59] <Connelly> is the only factual support i've been able to find for that statement
[18:59] <Connelly> is the statement true?
[19:00] * Hory (~Miranda@81.196.25.110) has joined #FreeNet
[19:00] <lolo-laptop> Connelly: if routing is working, yes.
[19:01] <Connelly> is there any more recent sim data on scalability?
[19:01] <lolo-laptop> no, nobody's simulated NGR afaik.
[19:01] <Connelly> it seems like a math proof is out of the question
[19:02] * Pascal (Pascal@c-24-13-17-191.client.comcast.net) has joined #Freenet
[19:03] <toad_> Connelly: okay, i'll give you the official line
[19:04] <toad_> freenet is a heuristic DHT
[19:04] <toad_> rather than a fixed DHT
[19:04] <toad_> there was a study where somebody sent a bunch of letters to people, they had to get them to the destination, only through people they knew personally
[19:05] <toad_> it took 6 "hops"
[19:05] <toad_> i.e. it on average took a chain of 6 people, routing only through their friends, to get across the united states
[19:05] <toad_> freenet is an attempt to reproduce that same principle, in part
[19:06] <toad_> therefore it should scale rather well
[19:06] <Connelly> in principle
[19:06] <toad_> right
[19:06] <toad_> and not being mathematically proven
[19:06] <toad_> the simulations we did of the old freenet routing algo according to ian would fit either log(N) or N^0.28
[19:06] <lolo-laptop> <flood>
[19:07] <toad_> either way is reasonable
[19:07] <lolo-laptop> Jul 29, 2004 6:24:02 PM (freenet.transport.WriteSelectorLoop, Network writing thread, NORMAL): fixKeys added freenet.transport.WriteSelectorLoop$SendJob: java.nio.HeapByteBuffer[pos=4960 lim=4960 cap=4960],java.nio.channels.SocketChannel[connected local=/192.168.0.3:55698 remote=/213.79.32.57:27074],freenet.MuxConnectionHandler@1bdfbf6 MuxConnectionHandler[conn=[tcp/connection: 55698>213.79.32.57:27074,freenet.transport.tcpConnection@12a123d], link
[19:07] <lolo-laptop> =[freenet.session.FnpLink@1139ac8], p=[freenet.presentation.MuxProtocol@1796649], identity=[DSA(6cb9 e71b e1e1 7162 1ecb 95bd b5f3 f36f e90a 8ae5)], sock=[Socket[addr=/213.79.32.57,port=27074,localport=55698]], chan=[java.nio.channels.SocketChannel[connected local=/192.168.0.3:55698 remote=/213.79.32.57:27074]], peer=[Peer [DSA(6cb9 e71b e1e1 7162 1ecb 95bd b5f3 f36f e90a 8ae5) @ 213.79.32.57:27074 (1/3)]], outbound=[true]],0,763166,prio=1: sun.n
[19:07] <lolo-laptop> io.ch.SelectionKeyImpl@15b8c38 - AND IT WROTE SUCCESSFULLY! This can happen occasionally but if it happens a lot, it could indicate a broken NIO implementation
[19:07] <toad_> lolo-laptop: :(
[19:07] <toad_> but the simulations were rather unrealistic
[19:07] <lolo-laptop> getting a pretty big number of them
[19:07] <Connelly> well that's ok
[19:07] <Connelly> my question was whether the statement was reasonable in the first place
[19:07] <toad_> i suspect that different parameters (more requests per insert or per node announcement) would have been closer to o(log n) (i'm sure i heard somebody saying that the graphs don't fit log...)
[19:08] <toad_> the statement may be credible
[19:08] <toad_> it's certainly our aspiration
[19:08] <Connelly> if it apparently scales, then it apparently scales
[19:08] <toad_> one of our aspirations
[19:08] <toad_> whether it scales in practice is another question
[19:08] <toad_> but there are "natural" models that scale very well
[19:09] <toad_> also, the simulations were of classical routing, not of NGR
[19:09] <toad_> although NGR follows some of the same principles
[19:09] <toad_> so, essentially... we don't really know
[19:09] <Connelly> ok
[19:09] <toad_> it may well work eventually
[19:09] <toad_> :)
[19:09] <toad_> welcome to the cutting edge :)
[19:10] * mush (~kkdowning@142.179.66.120) has joined #freenet
[19:10] <toad_> another question is whether it will scale if we take out path folding
[19:10] <toad_> if that is true, then it expands our range of possible use scenarios significantly
[19:10] <lolo-laptop> 56 minutes, 256MiB transferred...
[19:10] <toad_> of course there would be a cost...
[19:10] <lolo-laptop> not bad for a DSL node
[19:11] <toad_> but fixed routes + steganography is one promising approach for REALLY hostile environments i.e. where running a node is per se illegal
[19:11] <toad_> err fixed connections
[19:11] <toad_> well low flux connections
[19:12] <toad_> but that's the really long term ;)
[19:12] <lolo-laptop> freenet over wifi (skip TCP entirely?)
[19:13] <lolo-laptop> freenet for my cell phone
[19:13] <Lux> lol
[19:13] <toad_> nah, we'd probably still use TCP
[19:14] <toad_> or maybe UDP
[19:14] <Lux> hehe
[19:14] <Lux> cant the bittorrent technology be used someways?
[19:14] <Connelly> do you know of any links other than the given ppt
[19:14] <Connelly> that have sim data showing scalability?
[19:16] <toad_> Connelly: there was some in the IEEE paper, is that what you're reading?
[19:16] <Connelly> just some presentation
[19:16] <Connelly> http://discolab.rutgers.edu/classes/cs672/slides/FreeNet672Presentation.ppt
[19:17] <toad_> http://freenetproject.org/index.php?page=papers
[19:17] <Pascal> toad: did you see the message I sent you with your username and password for my box?
[19:17] <toad_> Pascal: yes, i changed the pw
[19:17] <Pascal> cool
[19:17] <Connelly> ok thanx
[19:19] <toad_> bbl zzz
[19:19] <Connelly> how does he simulate 1 million nodes?
[19:19] <lolo-laptop> damn, toad going to bed before 1am??
[19:19] <toad_> Connelly: very badly :)
[19:19] <lolo-laptop> g'night toad
[19:19] <Connelly> i can't imagine using 1 million threads
[19:19] <toad_> no, it was slightly cleverer than that
[19:24] <Lux> nite toad_
[19:31] <Connelly> http://en.wikipedia.org/wiki/Freenet#Scalability
[19:33] <Connelly> u guys might also want to edit that and make it more NPOV
[19:34] <Connelly> it reads like half-propaganda and half-encyclopedia right now
[19:35] <Lux> lol
[19:52] * Lux (~Lux@82-37-17-24.cable.ubr03.wolv.blueyonder.co.uk) has left #freenet
[20:45] * lolo-laptop (~lostlogic@68.251.84.226) Quit (Remote closed the connection)
[20:49] * Hory (~Miranda@81.196.25.110) Quit ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[21:12] * lostlogic using 220kB/s total bandwidth on a 1.5m/768k DSL yay for getting everything out of my service.
[21:20] * greycat (rfc1413@wooledge.org) has joined #freenet
[21:21] <greycat> Fred,0.5,STABLE-1.50,5084 141
[21:21] <greycat> Fred,0.5,STABLE-1.50,5085 27
[21:21] <greycat> Fred,0.5,STABLE-1.50,5086 75
[21:21] <greycat> Fred,0.5,STABLE-1.50,5087 116
[21:21] <greycat> Fred,0.5,STABLE-1.50,5088 38
[21:21] <greycat> Fred,0.6,1.51,60174 1
[21:21] <greycat> .... why do I have a 60xxx node in my routing table?
[21:21] <lostlogic> heh
[21:22] <jabawok_w> someone moved to stable and not updated their seednodes.ref?
[21:22] <jabawok_w> i would have thought it's connection would be refused though
[21:23] <greycat> it doesn't show up on the ocm page
[21:26] <greycat> I'm also curious why freenet.client.cli.Main put is throwing stack traces at me.
[21:27] <greycat> INSERTING_BLOCKS (20/36):[1/1] queued: 0 running: 4
[21:27] <greycat> java.io.EOFException: Could not parse message from stream
[21:27] <greycat> at freenet.presentation.FCPRawMessage.<init>(FCPRawMessage.java:76)
[21:27] <greycat> at freenet.presentation.ClientProtocol.readMessage(ClientProtocol.java:63)
[21:27] <greycat> and so on
[21:28] * leex (~bbtt@cpc2-warr1-5-0-cust27.bagu.cable.ntl.com) has joined #freenet
[21:40] * |UK-Monster| (~bbtt@cpc2-warr1-5-0-cust27.bagu.cable.ntl.com) Quit (Read error: 110 (Connection timed out))
[21:49] <KenMan> SOB - stable/5088 Unexpected Signal : 11 occurred at PC=0x4030CC9A
[21:49] <KenMan> at 45 minutes uptime :(
[21:58] <KenMan> 21 conns, all incoming ... so far (after 6 minutes)...
[22:06] <KenMan> 70 xfers outgoing , 26 peers ... but incoming is less than outgoing, and this is just the whacky start-up phase...
[22:07] <KenMan> i mean, incoming xfers < outgoing xfers, which is generally a good thing.
[22:13] <lostlogic> I have about 100 conns after 4 hours uptime
[22:13] <lostlogic> :-D
[22:14] <lostlogic> 92 conns, 115 transfers
[22:14] <lostlogic> 966MiB transferred
[22:14] <lostlogic> 4 hours on the dot
[22:18] <KenMan> i set the maximum at 80, which is pretty high in my book. With better rate limiting it should be less of an encumberance.
[22:19] <KenMan> i just got toad's latest custom jar he built for me, so I'm restarting. I should gather a good deal of data for him by tomorrow.
[22:20] <lostlogic> nice.
[22:20] <KenMan> things were just awful with 5087, so it is great that we have a 5088 to correct it with !!
[22:20] <KenMan> in only a day's time :)
[22:20] <lostlogic> I'm still doing my usual cvs version with Version.java sticky on stable branch and everything else unstuck...
[22:21] <KenMan> how goes that ? someone reported having a 60172 on _stable_ on devl, i think
[22:21] <lostlogic> hehe, it seems to work well, the only thing that I have is that most of my routes are backed off most of the time
[22:22] <KenMan> :( it may get better. QPH ?
[22:22] <KenMan> oh, it was greycat, just above , who reported one unstable node on stable ...
[22:22] <lostlogic> Smoothed local mean traffic (queries per hour): 4345.882
[22:23] <KenMan> wtf - kacpid is eating a lot of CPU :(
[22:23] <lostlogic> the global stats are falling, or so it would appear as the median is below the mean significantly (that's how the trendlines run, right?
[22:24] <KenMan> i'm not sure, but that sounds like a good situation. I can't seem to think it out straight.
[22:24] * lostlogic gone
[22:24] <KenMan> see ya !
[22:29] * KenMan restarts without preemptive kernel or acpi stuff...
[22:29] * KenMan (~chaziller@pcp403292pcs.mntcrm01.md.comcast.net) Quit ("ChatZilla 0.9.61 [Mozilla rv:1.7b/20040324]")
[22:39] * greycat (rfc1413@wooledge.org) Quit ("Lick Bush in '04")
[23:26] <TheSeeker> ok, got myself a node up... 60174
[23:32] * iip_i2p (~changate@host.teitel.net) has joined #freenet
These logs were automatically created by Jay Oliveri with his gimp hapi on irc.freenode.net.
