> > Connection attempts 1193 > > Connection successes 1047 > > Consecutive failed connections 0 > > Probability of connection failure 0.017196883744822623 > > Umm, why is this bad?
On my node, connectingTime is in the 10s range. The above was doing 1 a second. If connection bring ups are expensive (I thought they were), then firing up 1 a second to a node we were just connected to 1 second ago, seems, well, odd to me. If we compute the bandwidth used, surely the other node would be less loaded (in terms of CPU used and upstream used) leaving the connection up. The # of open connection is about as free as things get in freenet. The don't kill os with context switches, they don't take lots of memory, unlike threads. No connection should be reopened within 5x the connecting time, or put another way, leave connections open if they haven't been idle for 5x the connecting time. If not 5x, how about 1x? > How do you know they are in your store? I was mistaken, it was a new edition. I was surprised as it hadn't been updated in a while and then it was. > > messageSendTime is curious, 3 orders of magnitude improvement in the > > maximum. Stunning. Now, it remains to be see if that is due to > > improvements or lack of load on my node. [shakes head] 3 orders of > > magnitude. Nope, didn't hold. I've been hammer back into the ground, slightly surpassing the old numbers. 1.4E7 max for messageSendTime. :-( Could we limit inbound requests once this rises above 60s and upstream > 75%. 1.4E7 just seems pointless. > > Right now, these are using up all the job slots and stalling out my > > outbound connection even though I have 9 transmitting. > > Eh? They will be using up threads, you mean it's queryrejecting because > of threads? Yes. _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
