gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz-commits] storm/doc/pegboard/attacking_gisp--hemppah peg.rst


From: Tuomas Lukka
Subject: Re: [Gzz-commits] storm/doc/pegboard/attacking_gisp--hemppah peg.rst
Date: Tue, 10 Jun 2003 21:32:59 +0300
User-agent: Mutt/1.5.4i

On Tue, Jun 10, 2003 at 09:10:34AM -0400, Hermanni Hyytiälä wrote:
> -We expect that GISP is able to route some queries to their destination peers 
> eventually,
> -altough the performance of a lookup is expected to decrease (Chord's fault 
> tolerant
> -properties). Also, we except that some of the queries are lost. With this 
> test case, we wish 
> -to get more information how big the lost rate is (Chord's fault tolerant 
> properties). 
> +We expect that GISP's fault tolerance is at least at the same level as 
> Chord_'s 
> +fault tolerace since GISP's routing table is based on Chord's routing table:
> +
> +.. place here some results from the Chord paper
> +
> +Thus, we expect that GISP is able to route some queries to their destination 
> +peers eventually, altough the performance of a lookup is expected to 
> decrease. Also, 
> +we except that some of the queries are lost. With this test case, we wish 
> +to get more information how big the lost rate is.
> +
> +Eventually, we will compare (and validate) our test results with the Chord's 
> +fault tolerance properties.

Still far too vague. 

You're leaving so much "wriggle room" for yourself that you're not actually
saying much anything. Almost any results from a test would fit what you
say above. That's *NOT* good.

The questions you need to answer theoretically *carefully* are:

        - do you think that eventually the network will regain its original
          performance with time or not?

        - if not, what can you say about the eventual steady state performance?

        - how long will it take to reach it?

>  Simulation Process: 
>  - Create 90 normal peers in the network (ID is in the format "peer1 -peer90")
>  - Create 10 "dumb" peers in the network (ID is in the format "dumb1-dumb10")
>  - If necessary, the number of total peers and "dumb" peers can be 
> increased/decreased
> -  (for "clearer" analysic etc)
> -- Create 5000 key/value items in the network (the format is "key1-100", 
> "value1-100")
> -- Perform 2500 queries randomly with *normal* peers (random peer selection 
> (peer1-100) 
> -  and random query selection (key1-100))
> +  
> +    .. list different settings...
> +  
> +- Create 5000 key/value items in the network (the format is "key1-5000", 
> "value1-5000")

You were saying earlier 100*N?


> +- Perform 2500 queries randomly with *normal* peers (random peer selection 
> (peer1-5000) 
> +  and random query selection (key1-5000))

Why 2500? What is your expectation for the routing info to converge?

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]