Thus spake Karsten Loesing (karsten.loesing@xxxxxxx): > > On Oct 15, 2010, at 4:13 AM, Mike Perry wrote: > >> I would love to have all of these datastream available for comparison > >> when various events and perf tweaks change the network. In fact, I > >> would love it if we could have the following 5 torperf runs logging > >> continuously and all overlayed on the main Torperf metrics graph: > >> > >> 1. Fastest 3 guards by network status > >> 2. Fastest 3 guards by ratio of ns_bw/desc_bw > >> 3. EntryGuards=0 (default current torperf) > >> 4. Slowest 3 guards by network status > >> 5. Slowest 3 guards by ratio of ns_bw/desc_bw > > Okay, I think we can continue running the 3 or 5 Torperf runs with > modified guard node selection algorithms in the future if we think the > data is useful. However, note that > > a) the 3 Torperf runs for #1919 run on some machine which is, AFAIK, not > one of our VMs and which may or may not host the 3 or even 5 Torperf > runs in the future, > > b) I have no idea how to add 2 more Torperf runs with the guard > selection algorithms you stated, and I can update the #1919 script to handle runs #2 and #5. I've added it to my TODO list. > > The problem wasn't that the script was taking a lot of RAM, but rather > > that each torperf instance comes with its own tor instance. Spinning > > up another 9 clients caused the memory issues. > > I think we can ask for more memory for the VM running this. Ok, let's do that and put them all there. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpg9WKRiUYTW.pgp
Description: PGP signature