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 <[email protected]> wrote: > Thus spake Karsten Loesing ([email protected]): > >> - 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 >
