[mnet-devel] peerman controversy plus measurements

[Arno Waschk]

i observed peerman wasting huge amounts of memory by creating very high 
peerman levels due to huge data structures being produced then. i am not 
sure whether this is the case of Enochian, nor whether this is still 
possible with the actual peerman version.
I do not understand how to read run #3 being mentioned twice ... is that 
two runs?
Arno


On 12 Feb 2004 15:47:59 -0500, Zooko O'Whielacronx <zooko at zooko.com> wrote:

>
> People who don't hang out on the #mnet channel on irc.freenode.net all 
> day might
> not know that there is a controversy over peerman.  Arno doesn't like 
> peerman,
> as he spent many long hours studying logs in an attempt to diagnose 
> bermuda
> triangle bugs, and then he discovered that he was wasting his time 
> because of
> peerman.  Actually now that I'm writing this I don't know how exactly 
> peerman
> interfered.  Anyway, this was back in December or so when this happened.
>
> Arno has a good argument than instead of probabilistically masking the 
> existence
> of peers who might be gone, peerman should just sort them to the back of 
> the
> list and let the higher-layer logic (e.g. blockwrangler, relay listener, 
> etc.)
> decide when to try peers who might be gone.
>
> See footnote 1 for the description of how peerman works [1].
>
>
> Anyway, I was just running my own nodes without peerman turned on (since 
> peerman
> is turned off by default in current CVS), and I observed this flurry of 
> "lookup
> contact info" messages.  So I decided to take some measurements.
>
> Since my node (named <nw31m>) has been around for a long time, it has 
> met lots
> of other nodes at different times in the past, and it still remembers 
> the public
> key and some historical performance measurements from each one.  In fact,
> I guess it remembers 53 of them as you will see below.
>
>
>  * Run #1: peerman turned off (default).  PYUTILDEBUG=true.  I ran the 
> process
> at nice level 20.  Start the node, publish a file (MC Hawking's "What We 
> Need
> More Of Is Science"), shut down the node.  It took exactly 300 seconds, 
> and
> sent out a total of 341 "lookup contact info" messages, searching for the
> contact infos of 53 unique peers.
>
> Only three unique peers sent messages to my node during that time, and 
> that
> includes itself!  So I think the actual working network was of size 3 
> during
> this run.
>
>  * Run #2: peerman turned on.  Same PYUTILDEBUG=true and nice=20.  Same 
> process
> including publishing the same file again.
>
> It took 156 seconds, and sent out a total of 8 "lookup contact info" 
> messages,
> searching for the contact infos of 3 unique peers.  Again, there were 
> only 3
> peers alive during the experiment.
>
>  * Run #3, peerman turned off again.  This time I turned off debug mode 
> and I
> didn't nice the process.  170 seconds, 247 lookups on 51 unique peers.
>
> Run #3, peerman turned off again.  PYUTILDEBUG=false, nice=0.  199 
> seconds, 5
> lookups on 2 unique peers.
>
>
> You probably shouldn't pay much attention to how many seconds the runs 
> took,
> since much of that time was spent waiting for me to click on the user 
> interface.
> However we can say that with no peerman, with around 50 peers known, 
> only 3 of
> whom are currently on-line, we generate more than one "lookup contact 
> info" per
> second.
>
>
> Now one "Enochian" fellow has turned up on IRC and said that when he 
> turned
> peerman on (by editing MojoConstants.py) he got a blow-up in which the 
> node took
> up 340 MB RAM, sent lookups out at a very high rate, and had to be 
> killed with
> SIGKILL.  That is a disturbing report, and if anyone else sees such a 
> thing and
> captures a mojolog of the event I would very much like to have the 
> mojolog!
>
>
> Regards,
>
> Zooko
>
> [1] Here is the original note I wrote saying that I was going to write 
> peerman:
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=3510400&forum_id=7702
>
> ... and then after implementing peerman, I realize that by adding 
> exponential
> backoff retrying it doesn't lose track of metatrackers:
>
> http://zgp.org/pipermail/p2p-hackers/2003-December/001556.html
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> mnet-devel mailing list
> mnet-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mnet-devel
>



-- 
http://www.arnowaschk.de


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel