On Monday 10 December 2007 20:37, David Sowder wrote: > I have location data in an RRD for each of my two, currently up nodes, > as obtained via FCP using pyFreenet's utility for such. My graphs from > the last week has had the location all over the place for one node, > while the other node is more calm, but still not appearing to truly > favor any particular spot on the location circle.
So the second node is wandering about a lot? This is probably an artefact of poor topology... > > Matthew Toseland wrote: > > On Monday 10 December 2007 18:52, Robert Hailey wrote: > > > >> On Dec 10, 2007, at 11:49 AM, Matthew Toseland wrote: > >> > >> > >>>> In the present network, it probably would; but in theory I think that > >>>> the patch is correct (or some variant thereto). > >>>> > >>> Nothing would ever be dropped from the network, because when it's > >>> considered > >>> for dropping, it would get reinserted to 20 other nodes! > >>> > >> I am not recommending that this patch be applied... yet. Every point > >> that you have raised against it is perfectly valid. In the present > >> network, because the nodes drift locations soo much, this patch (even > >> if perfectly tuned; maybe re-insert with HTL=1) would cause data > >> blocks to "chase" the nodes around the network. Resulting in massive > >> network traffic increases, as you said. *IF* it helped access of data, > >> it would only be due to the renewed data being passed through the node > >> caches (which would probably be overflowed with old insert data). > >> > >> My suggestion at present is to: > >> (1) stabalize node locations enough that data stores come alive, or > >> > > > > Dependant on topology (which we can control), node uptimes (which we can't > > control), ... > > > > > >> (2) bias/soft-anchor towards what is in the datastore (or perhaps what > >> has most-recently been put in the data store?). > >> > > > > Will not happen without major simulations. > > > >> I agree that either of which would require simulations. > >> > > > > Right. And in the latter case, simulating it would be slow, as we'd have to > > maintain fairly large virtual datastores in the simulation. > > > > > >> #1 would be a > >> statistical solution (network drift < datastore utility-threshold) and > >> may be presently attainable with tuning, whereas #2 would be more > >> pragmatic (and tend to specialize nodes further). #1 may already be > >> the case if the network size was large enough, but an algorithmically > >> correct freenet should support any size network (as math scales very > >> well). > >> > > > > IMHO the next step forward is simply to log location changes and display them > > either on the location page or on a subpage, or as CSV data (or perhaps > > through SNMP) so it can be graphed externally. Maybe for the node's peers as > > well as itself. Are you interested in doing some data collection code? Lets > > discover whether there actually is a problem with location drift before we > > try to solve it ... > > > > Another thing you could do would be to implement a datastore histogram > > generator. We had one in 0.5. > > > >> As an example of the general problem (although it seems to have helped > >> get a routable network); even the theory of a node randomizing it's > >> location totally obsoletes it's datastore. > >> > > > > Usually the node will swap back to where it should be within a fairly short > > period. However, again, we need some hard data from the real network before > > we even implement simulations. > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071210/4475f0b2/attachment.pgp>
