On Thursday 10 May 2012 01:08:45 Evan Daniel wrote: > On Tue, May 1, 2012 at 7:48 AM, Zlatin Balevsky <zlatinb at gmail.com> wrote: > >> On 04/28/2012 06:56 PM, Zlatin Balevsky wrote: > >>> In Gnutella we observed that long-lived nodes tend to be better > >>> connected and that they also cluster with other high-uptime nodes. > >>> If the same is true for Freenet it's a good idea to keep an eye for > >>> side effects as you tweak the behavior. > >> > >> Good to know - I'll look for that. Are there any particular effects > >> you had in mind? The Metropolis-Hastings correction in the new probes > >> should produce a fairly uniform distribution of endpoints despite > >> clustering and well-connected nodes, but explicitly simulating the > >> effects of high uptime could be helpful. > > > > There was a study that higher uptime correlated with the probability > > of further uptime so if you shift bias towards low-uptime nodes you > > could end will lower overall reliability. It was done on a different > > network with different usage patterns but imho you should definitely > > treat node uptime as a parameter in any simulations. > > MH should produce a good simple random sample from all nodes currently > online, provided that the walk is of sufficient length, regardless of > clustering effects. If there are partitioning effects, those will make > the required walk length to get good dispersion longer, in a way that > might be somewhat difficult to measure, but as long as the network is > not completely partitioned, a sufficient walk length will produce a > good sample. The fact that a large sample must be taken over an > extended period means that low-uptime nodes will have a somewhat > disproportionately lower chance of being in the sample (I think... > need to do math here), but isn't a huge problem.
Can we tell whether the network is partitioned? I guess that's one of the key outcomes? I.e. are there barriers between different parts of the network, are there large areas with similar locations but few connections, etc? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120620/d0a5b618/attachment.pgp>