After #1 is decided, we can convert past bwauth data, can't we? If it's helpful I can (at some point) compare your data against historical (converted) data as I've been doing: https://tomrittervg.github.io/bwauth-tools/
-tom On 18 March 2018 at 20:22, Matt Traudt <pas...@torproject.org> wrote: > I've made some good progress on a bare bones, doesn't-do-more-than-it- > has-to bandwidth scanner. It can generate output just like torflow[0]. > > We need to decide on how to scale results that come from different > measurement systems. The simple, don't-make-it-harder-than-it-has-to-be > idea is (quote [1], see [2]): > >> Express each weight as a proportion of the total, and multiply by > some agreed total (e.g. for the current network it would have to be the > total of the consensus weight, but within some limited range to avoid > unbounded growth). > > So we need to: > > 1. Decide on a large total. > > I suggest 50 million to start the conversation (bike shedding) based on > that being close to the current total consensus weight so relay > operators won't see a large (though inconsequential) change. > > 2. Have all the torflow operators switch to this new method. > > Ouch. I wouldn't mind being told I'm wrong about this step being > necessary. > > 3. Find all the places that hint at consensus weight being directly > comparable to bandwidth (such as [3]) and change the wording. > > Matt > > [0]: https://paste.debian.net/1015409/ > [1]: https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rom > e/Notes/BandwidthAuthorityRequirements#Scaling > [2]: https://trac.torproject.org/projects/tor/ticket/25459 > [3]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2290 > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev