Torperf

[grarpamp]

Somewhat related, came up in chat as a possible todo...
Is anyone collecting stats regarding hidden service to hidden service
performance?

On 10/14/10, Mike Perry <mikeperry at fscked.org> wrote:
> 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
>