Torperf

[Mike Perry]

Thus spake Karsten Loesing (karsten.loesing at gmx.net):

> - Do we want to keep the #1919 Torperf runs running or migrate them to
> some other VM (that has enough memory)? What do we expect to learn from
> keeping them running or migrating them that we didn't learn from the
> first week or two? Instead of keeping them running we could also make a
> PDF report and put it on metrics.tpo/papers.html.

I think this is very important to keep running, and that we should
think about adding new runs for based on the ratios of measured
consensus bandwidth to published descriptor bandwidth. Guards with
high ratios for this value have been observed by the bandwidth
authorities as having lots of slack capacity, where as Guards with
low ratios would be overloaded.

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

Is it hard to keep all of these running and logging for some reason?
Does the 1919 script take up a lot of RAM?

I can make these and any other changes to the 1919 script to help this
along.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20101014/13ee0e5a/attachment.pgp>