[mnet-devel] peerman controversy plus measurements

[Zooko O'Whielacronx]

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