On Sat, Oct 25, 2003 at 10:31:26PM -0700, Mike Stump wrote:
> Inserts with 6281 feel very slow.  A brief comment to YoYo using nim,
> and 4:38 later it finished.  I could have sent it by hand to 11,120
> nodes myself in that time if I had connections open to them all, as my
> uplink wasn't in use, yet.
> 
> At least YoYo came up.
> 
> 
> Lowest global time estimate   323563ms
> Highest global time estimate  449279ms
> 
> Gosh, this is still wrong.  On a small network, things should have
> been fast.  There must be something terribly wrong.

Maybe. It's not that small. Anyway, there were probably still a lot of
pre-6280 nodes on the network...
> 
> This is choice:
> 
> Last connected never
> Last attempted 95s ago
> Connection attempts 10
> Connection successes 0
> Consecutive failed connections 10
> Probability of connection failure 0.8926258176000001
> 
> Puzzle me this, if we've never connected why is the probability less
> than 1.0?

Because it doesn't start at 0? It's a decaying average, it's not
attempts/successes. The reason for this is to make it sensitive to
recent events.
> 
> This is just ugly:
> Last success  33 years 306 days 3 hours 11 minutes 19 seconds 

Ouch.
> 
> 
> Thanks for getting rid of the recent code that limits outbound queries
> to 300, it wasn't necessary (anymore, now that we have messageSendTime
> limiting).
> 
> Search died time of 351s seems excessive.

Interesting. If the node dropped the query, it's possible... I dunno.
> 
> Any the worst thing from that table:
> 
> Status for tcp/62.3.69.103:20371
> Last connected  1s ago
> Last attempted  1s ago
> Connection attempts  1193
> Connection successes 1047
> Consecutive failed connections 0
> Probability of connection failure 0.017196883744822623

Umm, why is this bad?
> 
> This is unfriendly, I've only been up for an hour. And from the
> outbound connects table:
> 
> 1256  1107    2       62.3.69.103
> 738   714     0       69.27.47.154
> 176   175     0       63.231.80.217
> 77    70      2       208.180.130.230
> 16    14      2       69.10.142.2
> 
> this, on a machine that has tons of free slots in my connection pool.

Why is this bad? Maybe they closed the connections because they were
overwhelmed? Those aren't in your routing table are they?
> 
> After an hour, my machine has not one query into it.  I guess me and
> my 9G datastore that I brought over from oldnet that was being
> hammered just isn't interesting anymore.  Sniff.  I've had 4 inbound
> connects all from the same node, so at least I am not a leper.

Hmm. Interesting. Announcements by default happen after 2 hours, and
will take some time for it to succeed... it's newly on the unstable
branch, so nobody knows about it.
> 
> Inbound connects over http for pictures aren't reliable anymore,
> someone may have broken it recently, past few weeks, as it I think
> used to work better.  Pull up PornOfLove (off YoYo) and see if you get
> all pictures the first time.  If they aren't in your cache, get them
> in, then clear out the browser cache, then hit reload.  I'm seen 1-4
> broken pictures, when I know they should be in the cache.

We need to implement a user-only cache... this is just pcaching in
operation.
> 
> Also, with wget running on the web port, a browser trying to get at
> the various status pages for fred (ocm for example) can really crawl,
> as in 30+ second delays in the middle of the page.  This should not
> happen, each connection should be able to get by the other one, and no
> global locks to keep it from getting the data should exist.

Wget only uses one thread.. but it may time out. Each download uses a
thread. Even if wget times out, the thread will still be running. Maybe
we should NIO fproxy... it will be significant work though. We limit the
number of HTTP connections for exactly this reason.
> 
> 
> And a random one from the log:
> 
> Got StateReachedEvent (State FAILED reached.) with currentRequestProcess == null! 
> for freenet.client.AutoRequester:(not requesting)():freenet:[EMAIL PROTECTED]
> 
> Odd, that one was in my datastore.  Not sure why it should fail.  A
> few things that I know are in my datastore can't be pulled up.  At
> least one of them was an edition, not a DBR.  Is this normal?  I was
> under the impression that edition things would stay and not just
> randomly fall off?

How do you know they are in your store?
> 
> Oh, cool 454 (3 DFs) requests into my node, I'm not a leper!  Gosh,
> now at full tilt (on the upstream), rejecting 60% of 359 requests in
> the last minute.  Blink, gosh, people really like me 28 transmitting.
> Oh, I'm gonna pay for the earlier comments now.

:)
> 
> I have a wget of yoyo going of depth 3, so that all of yoyo plus the
> first page or so of the linked sites would be hot on my box.  I
> suspect a few of the newbies to the fine new network that wanted to
> look around discovered that I had everything they wanted.
> 
> 
> The sentData success rate seemed to be low before, 20-80% success
> rates, now, in the last two hours, 98% and 96%.  If this holds, and I
> hope it does, this looks much better.  I tweaked loadbalancing to
> being back on for the new network, I had tryied turning it off to see
> how things were like that way.  Not sure if this impacted it.  Also,
> this is with an order of magnitude bigger numbers now, much nicer.

That is good.
> 
> 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.
> 
> Inbound QR are down 2 orders of magnitude.  Time will tell if it
> holds.  Hum, now down to 1 order of magnitude.  I don't think it will
> hold.
> 
> 
> Anyway, that's long and rambling enough...  Notice, no Wild and Crazy
> ideas today...  I'll save them up for next time.

-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to