Re: Captured topology data; ossa2007

On Wednesday 09 May 2007 19:13, you wrote:
> Well, what does the data say?  Does it support or refute any of these
> theories?

Well, there is a spike at 0.2 on my peers and my intercepted swap locations. 
This has been true for a while; before the network reset it was at 0.0. 
Having said that it's not that big a spike any more. But the intercepted swap 
data only goes out to 6 hops.

That leaves probe requests. Which continue to be perverse, but I think we have 
some chance of investigating with the new recorded data:

INFO   | jvm 1    | 2007/05/08 20:21:43 | LOCATION 0: 1.3539134879558823E-5 - 
estimated nodes: 73859.96290721533 (62 hops)
INFO   | jvm 1    | 2007/05/08 20:27:31 | LOCATION 1: 2.361622498392446E-5 - 
estimated nodes: 84687.54008574181 (73 hops)
INFO   | jvm 1    | 2007/05/08 20:32:56 | LOCATION 2: 0.004470353498917001 - 
estimated nodes: 671.0878682696541 (40 hops)
...
INFO   | jvm 1    | 2007/05/09 20:36:29 | LOCATION 247: 0.9916986858272543 - 
estimated nodes: 250.07595910356943 (42 hops)

Clearly something is wrong here. It might very well be routing that is wrong. 
I'll have a look at the detailed probe logs. We might have to introduce even 
more topology monitoring mechanisms. :(
>
> Ian.
>
> On 5/9/07, Matthew Toseland <toad-EI5O+8PHWbJeeLb3ft/[email protected]> wrote:
> > 1. We have added code to accurately capture the long-range network
> > topology by monitoring swap requests (and adding a per node uid for each
> > location mentioned), and through probe requests (a request routed to a
> > location, which returns info such as how close it got to the location,
> > how many hops it took etc; we have now added per-hop info on the peers of
> > the nodes it passed through). Obviously neither mechanism is perfect:
> > swapping only gives us 6 hops, and probe requests rely on working
> > routing.
> >
> > What should we do with this data? We have a few theories:
> > - There may be a well-connected core of developer nodes etc, and then
> > most of the rest of the network is newbies connected exclusively to
> > newbies, no long links. Probably because of the current means for newbies
> > to obtain noderefs. - Selective pressure for node locations to cluster
> > together: Core nodes get very close together locations (around 0.25 at
> > the moment), and newbies get the rest. When a newbie node arrives, if its
> > location is close to the core it moves to the core, possibly displacing
> > not-so-close locations. If it's not close to the core it stays in newbie
> > space. And newbie locations are dumped when the newbies leave. Result:
> > Newbies occupy most of the location space, but are fairly sparsely
> > distributed; established nodes occupy a very small area, much denser than
> > the newbies' area. Before the last network reset this was very obvious in
> > the locations from the swap data, it's not so obvious any more, so maybe
> > it isn't a real effect..
> >
> > The basic question here is does #freenet-refs cause serious problems in
> > the network topology, and are there other major problems such as location
> > clustering as described above.
> >
> > How do we use the collected data to verify these theories, or get other
> > data on the network?

_______________________________________________
Tech mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGQiMzA9rUluQ9pFARAuKUAKCvD4wtNh5ZgGQZMYf+Wp656V4z2gCfbMlj
6nKt4EKDqWl3s7hZXXv8l78=
=oeMh
-----END PGP SIGNATURE-----