Thus spake Karsten Loesing (karsten.loesing@xxxxxxx): > - 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
Attachment:
pgpsZAjgoA2Jt.pgp
Description: PGP signature