[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Torperf



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