Maybe you are right. I did see some suspicious RNFs earlier... On Wed, Jul 28, 2004 at 11:15:40AM -0400, Edward J. Huff wrote: > On Wed, 2004-07-28 at 08:42, Toad wrote: > > Obviously my efforts are worthless. I should go get a job stacking > > shelves. > > Not at all. I'm just pointing out the facts. It's a lot harder to > retrieve data from 5087 than from 5084, and the number of nodes running > 5084 seems to be increasing. Just now the number of 5087 also > increased, or my node connected to more of them. Later the numbers > decreased, because some nodes were dropped from the RT. > > 5085 and later have much more accurate upstream bandwidth limiting. > Also freenet.client.cli.Main seems to work better in 5085 and later. > > Upon falling back, my local success ratio went from 0.3% to 10%. > This is requesting splitfile blocks in random order from a large > list of blocks (which have been reported inserted or successfully > retrieved by others) with random htl ranging 0 to 20, with > no immediate retries. My 75 GiB datastore is not yet full... > > There is something going on which causes lots of quick RNF's. See > attached logs of my request script (which uses freenet.client.cli.Main > to issue requests). The 5087 performance data came before the 5084 > data. Build 5087 was getting large numbers of RNF's, even with only one > request pending at a time. 5084 got a bunch of them just after restart, > when there were only a few connections open, but after the node got > connected, there have been almost none, and the number of pending > requests maxed out at 40. > > localRequestSuccessRatio: > hour 1090994400 1262 3 0.002377179080824089 > hour 1090998000 1006 6 0.005964214711729622 > hour 1091001600 1183 1 8.453085376162299E-4 > hour 1091005200 1156 3 0.0025951557093425604 > fall back to 5084 -- fewer requests, more successes. > hour 1091008800 471 20 0.04246284501061571 > hour 1091012400 579 17 0.02936096718480138 > hour 1091016000 480 25 0.052083333333333336 > hour 1091019600 784 79 0.10076530612244898 > > requestSuccessRatio: > hour 1090998000 1944 20 0.0102880658436214 > hour 1091001600 2419 8 0.0033071517155849523 > hour 1091005200 2394 16 0.006683375104427736 > hour 1091008800 897 38 0.042363433667781496 > hour 1091012400 832 34 0.040865384615384616 > hour 1091016000 772 29 0.03756476683937824 > hour 1091019600 1786 114 0.06382978723404255 > hour 1091023200 1684 210 0.12470308788598575 > > # Histogram of node versions in fred's Routing table > # Jul 28, 2004 9:55:04 AM > # nodes: 1599 > Fred,0.5,STABLE-1.49,5063 1 > Fred,0.5,STABLE-1.50,5070 1 > Fred,0.5,STABLE-1.50,5083 1 > Fred,0.5,STABLE-1.50,5084 708 > Fred,0.5,STABLE-1.50,5085 165 > Fred,0.5,STABLE-1.50,5086 607 > Fred,0.5,STABLE-1.50,5087 115 > unknown 1 > > # Histogram of node versions in fred's Routing table > # Jul 28, 2004 10:44:39 AM > # nodes: 1537 > Fred,0.5,STABLE-1.50,5083 2 > Fred,0.5,STABLE-1.50,5084 686 > Fred,0.5,STABLE-1.50,5085 156 > Fred,0.5,STABLE-1.50,5086 576 > Fred,0.5,STABLE-1.50,5087 117 > > All inbound requests ever received, from 201 unique hosts: > > Receive Accept Acc/Rcv Succeed Suc/Acc Host Address Version > > Data by host version > > 1199 1199 1.000 43 0.036 5087 > 1173 1173 1.000 18 0.015 5084 > 472 472 1.000 16 0.034 5086 > 119 119 1.000 1 0.008 5085 > > Connections open (Inbound/Outbound/Limit) 164 (111/53/800) > Transfers active (Transmitting/Receiving) 89 (45/44) > Amount of data transmitted/received over currently open connections 162 MiB/118 MiB > Total amount of data transmitted/received 231 MiB/149 MiB > Uptime 5 hours 43 minutes > Current upstream bandwidth usage 13865 bytes/second (138.6%) > > > > > On Wed, Jul 28, 2004 at 08:32:12AM -0400, Edward J. Huff wrote: > > > On Wed, 2004-07-28 at 06:06, Jano wrote: > > > > Solved it changing the -Xmx128m to -Xmx256m. > > > > > > > > I suppose this can be a general problem, I'm running stable without any > > > > tweaks since a month or so. > > > > > > > > In the good side, two minutes running and I can see all the activelinks, > > > > where the previous build failed after many hours :) > > > > > > > > > > I upgraded promptly to 5085, 5086, and 5087. All used more CPU time, > > > but eventually would finish. Stackdump showed lots of biginteger stuff > > > while compute-bound. Inserts were better than 5084, but retrieval much > > > worse. RNF occurred in around 10 to 50% of all requests. (Each request > > > was for a unique key). Requesting peers-mode ocm seemed to trigger a > > > lot of CPU usage. > > > > > > Switching back to 5084, I get much better performance on requests, with > > > very few RNF's. Even fewer than I used to get, probably due to load > > > factors. It appears that many stable nodes are switching back to 5084, > > > since I seem to recall that a day or two ago there were relatively few > > > 5084 nodes. (I didn't save the histogram then). > > > > > > # Histogram of node versions in fred's Routing table > > > # Jul 28, 2004 8:25:46 AM > > > # nodes: 1556 > > > Fred,0.5,STABLE-1.49,5063 1 > > > Fred,0.5,STABLE-1.50,5070 1 > > > Fred,0.5,STABLE-1.50,5083 1 > > > Fred,0.5,STABLE-1.50,5084 692 > > > Fred,0.5,STABLE-1.50,5085 164 > > > Fred,0.5,STABLE-1.50,5086 615 > > > Fred,0.5,STABLE-1.50,5087 81 > > > unknown 1 >
> _______________________________________________ > Support mailing list > [EMAIL PROTECTED] > http://news.gmane.org/gmane.network.freenet.support > Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support > Or mailto:[EMAIL PROTECTED] -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
