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
5084-performance.txt.gz
Description: GNU Zip compressed data
5087-performance.txt.gz
Description: GNU Zip compressed data
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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]
