#22122: Add support for six new key-value pairs added by OnionPerf ---------------------------------+----------------------------------- Reporter: karsten | Owner: metrics-team Type: enhancement | Status: merge_ready Priority: Medium | Milestone: metrics-lib 1.7.0 Component: Metrics/metrics-lib | Version: Severity: Normal | Resolution: Keywords: | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: ---------------------------------+-----------------------------------
Comment (by karsten): Replying to [comment:6 iwakeh]: > I think there should be an OnionperfResult class that also supports the old torperf format. > > Eventually, there might be more use cases for the additional data in onionperf measurements. > And, onionperf already adds many keys that are not part of the torperf format. > > So, all 'torperf' should become 'onionperf' soon. After giving this some thoughts I think it's more complicated than this. The reason is that we're using OnionPerf in a kind of Torperf- compatibility mode right now, where it uses the same measurement setup (with static downloads of 50KB, 1MB, 5MB files) and produces the same data format with only minimal additions. But we'll soon want to add more realistic measurement setups (simulated website downloads), produce a richer data format (probably JSON based, IIRC), and present more useful measurement results on Tor Metrics. That's what we'll want to call OnionPerf, not what we're doing right now. And we'll still want to refer to past measurements and data formats as Torperf. How about we: 1. change the type annotation in .tpf files produced by OnionPerf to `@type torperf 1.1`, because that format is still backward compatible to `@type torperf 1.0` but adds new fields that a parser for the old format does not recognize; 2. keep referring to everything in CollecTor that downloads from OnionPerf instances as OnionPerf, because we're really downloading from that new tool, not from the old Torperf tool; 3. update https://collector.torproject.org/#type-torperf to say that these are "Torperf and OnionPerf Measurement Results" and specify what fields are new in version 1.1; 4. leave metrics-lib's `TorperfResults` unchanged and just say that it supports new fields added in version 1.1; 5. rename metrics-web's `onionperf.csv` (beta) to `torperf2.csv`, because it still uses the same measurement setup and data format as the former `torperf.csv`. It just adds a new column that makes it backward- incompatible with `torperf.csv`. And how about once we're moving to more complex measurement setups and a richer data format in OnionPerf we call that `@type onionperf 1.0`, `OnionPerfMeasurement`, `onionperf.csv`, and so on. What do you think? -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22122#comment:7> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs