Two more from Frost:

----- Anonymous ----- 2006.10.09 - 02:17:14GMT -----
nodeUptime: 1d3h
Freenet 0.7 Build #990 r10647

* Cached keys: 922,080 (28.1 GiB)
* Stored keys: 17,904 (559 MiB)
* Overall size: 939,984/1,227,554 (28.6 GiB/37.4 GiB)
* Cache hits: 2,841 / 25,117 (11%)
* Store hits: 105 / 20,426 (0%)
* Avg. access rate: 0/s

----- Anonymous ----- 2006.10.09 - 11:47:34GMT -----

Node status overview

* bwlimitDelayTime: 71ms
* nodeAveragePingTime: 428ms
* networkSizeEstimateSession: 401 nodes
* avrConnPeersPerNode: 6,438919 peers
* nodeUptime: 22h2m
* missRoutingDistance: 0,0451
* backedoffPercent: 34,7%
* pInstantReject: 0,0%


Current activity

* Inserts: 4
* Requests: 23
* ARK Fetch Requests: 7


Peer statistics

* Connected: 10
* Backed off: 5
* Disconnected: 7
* Listen Only: 1


Peer backoff reasons

* ForwardRejectedOverload 5

Location swaps

* locChangeSession: 8,703159E-1
* locChangePerSwap: 1,611696E-2
* locChangePerMinute: 6,581585E-4
* swapsPerMinute: 4,083639E-2
* noSwapsPerMinute: 1,358188E0
* swapsPerNoSwaps: 3,006682E-2
* swaps: 54
* noSwaps: 1796
* startedSwaps: 9091
* swapsRejectedAlreadyLocked: 17537
* swapsRejectedRateLimit: 10


Bandwidth

* Total Output: 703 MiB (9.08 KiBps)
* Payload Output: 502 MiB (6.48 KiBps) (71%)
* Total Input: 557 MiB (7.19 KiBps)
* Output Rate: 9.96 KiBps
* Input Rate: 7.91 KiBps


Store size

* Cached keys: 35 894 (1.09 GiB)
* Stored keys: 27 020 (844 MiB)
* Overall size: 62 914/61 377 (1.91 GiB/1.87 GiB)
* Cache hits: 1 700 / 47 833 (3%)
* Store hits: 188 / 37 905 (0%)
* Avg. access rate: 1/s


JVM info

* Used Java memory: 93.8 MiB
* Allocated Java memory: 108 MiB
* Maximum Java memory: 190 MiB
* Available CPUs: 1
* Running threads: 162



On Sat, Oct 07, 2006 at 12:01:21AM +0100, toad wrote:
> 1. THE STORE IS *LESS* EFFECTIVE THAN THE CACHE!
> ------------------------------------------------
> 
> Please could people post their store statistics? Cache hits, store hits,
> cached keys, stored keys.
> 
> So far:
> [23:11] <nextgens> # Cached keys: 6,389 (199 MiB)
> [23:11] <nextgens> # Stored keys: 24,550 (767 MiB)
> [23:09] <nextgens> # Cache hits: 217 / 12,738 (1%)
> [23:09] <nextgens> # Store hits: 14 / 10,818 (0%)
> 
> (Cached hits / cached keys) / (Stored hits / stored keys) = 59.56
> 
> [23:12] <cyberdo> # Cached keys: 17,930 (560 MiB)
> [23:12] <cyberdo> # Stored keys: 24,895 (777 MiB)
> [23:14] <cyberdo> # Cache hits: 178 / 3,767 (4%)
> [23:14] <cyberdo> # Store hits: 11 / 2,970 (0%)
> 
> (Cached hits / cached keys) / (Stored hits / stored keys) = 22.47
> 
> [23:14] <sandos> # Cached keys: 45,148 (1.37 GiB)
> [23:14] <sandos> # Stored keys: 16,238 (507 MiB)
> [23:11] <sandos> # Cache hits: 41 / 861 (4%)
> [23:11] <sandos> # Store hits: 5 / 677 (0%)
> 
> (Cached hits / cached keys) / (Stored hits / stored keys) = 2.95
> 
> Thus, in practice, the cache is far more efficient than the store.
> 
> The cache caches every key fetched or inserted through this node.
> 
> The store stores only keys inserted, and of those, only those for which
> there is no closer node to the key amongst our peers.
> 
> 
> The cache being more effective than the store (and note that the above
> is for CHKs only) implies either:
> 1. Routing is broken.
> 2. There is more location churn than the store can cope with.
> 3. There is more data churn than the store can cope with.
> 
> 
> 2. SUSPICIONS OF EXCESSIVE LOCATION CHURN
> -----------------------------------------
> 
> ljn1981 said that his node would often do a swap and then reverse it.
> However several people say their location is more or less what it was.
> It is necessary to make a log of a node's location changes over time...
> 
> 
> 3. PROBE REQUESTS NOT WORKING
> -----------------------------
> 
> "Probe requests" are a new class of requests which simply take a
> location, and try to find the next location - the lowest location
> greater than the one they started with. Here's a recent trace (these can
> be triggered by telneting to 2323 and typing PROBEALL:, then watching
> wrapper.log):
> 
> LOCATION 1: 0.00917056526893234
> LOCATION 2: 0.009450590423585203
> LOCATION 3: 0.009507800765948482
> LOCATION 4: 0.03378227720218496
> [ delays ]
> LOCATION 5: 0.033884263580090224
> [ delays ]
> LOCATION 6: 0.03557139211207139
> LOCATION 7: 0.04136594238104219
> LOCATION 8: 0.06804731119243879
> LOCATION 9: 0.06938071503433951
> LOCATION 10: 0.11468659860500963
> [ big delays ]
> LOCATION 11: 0.11498938134581993
> LOCATION 12: 0.11800179518614218
> LOCATION 13: 0.1180104005154885
> LOCATION 14: 0.11907112718505641
> LOCATION 15: 0.3332896508938398
> [ biggish delays ]
> LOCATION 16: 0.6963082287578662
> LOCATION 17: 0.7003642648424434
> LOCATION 18: 0.7516363167204175
> LOCATION 19: 0.7840227104081505
> LOCATION 20: 0.8238921670991454
> LOCATION 21: 0.8551853934902863
> LOCATION 22: 0.8636946791670825
> LOCATION 23: 0.8755575572906827
> LOCATION 24: 0.883042607673485
> LOCATION 25: 0.8910451777595195
> LOCATION 26: 0.8930966991557874
> LOCATION 27: 0.8939968594038799
> LOCATION 28: 0.8940798222254085
> LOCATION 29: 0.8941104802690825
> LOCATION 30: 0.9103443172876444
> LOCATION 31: 0.9103717579924239
> LOCATION 32: 0.9107237145701387
> LOCATION 33: 0.9108357699627044
> LOCATION 34: 0.9130496893125409
> LOCATION 35: 0.9153056056305631
> [ delays ]
> LOCATION 36: 0.9180229911856111
> LOCATION 37: 0.9184676396364483
> LOCATION 38: 0.9198162081803294
> LOCATION 39: 0.9232383399833453
> [ big delays ]
> LOCATION 40: 0.9232484869765467
> LOCATION 41: 0.9398827726484242
> LOCATION 42: 0.9420672052844097
> LOCATION 43: 0.9442367949642505
> LOCATION 44: 0.9521296958111133
> [ big delays ]
> LOCATION 45: 0.9521866483104723
> LOCATION 46: 0.9562645053030697
> LOCATION 47: 0.9715290823566148
> LOCATION 48: 0.9722492845296398
> LOCATION 49: 0.974283274258849
> [ big delays ... ]
> 
> Clearly there are more than around 50 nodes on freenet at any given
> time, and the above includes some really big jumps, as well as some
> really small ones. This may be a problem with probe requests, but it
> is suspicious...



> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20061027/20882029/attachment.pgp>

Reply via email to