[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22122 [Metrics/metrics-lib]: Add support for six new key-value pairs added by OnionPerf
#22122: Add support for six new key-value pairs added by OnionPerf
---------------------------------+-----------------------------------
Reporter: karsten | Owner: metrics-team
Type: enhancement | Status: closed
Priority: Medium | Milestone: metrics-lib 1.7.0
Component: Metrics/metrics-lib | Version:
Severity: Normal | Resolution: implemented
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------------+-----------------------------------
Changes (by karsten):
* status: merge_ready => closed
* resolution: => implemented
Comment:
Replying to [comment:8 iwakeh]:
> Replying to [comment:7 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.
>
> Valid concerns.
>
> >
> > 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;
>
> Agreed.
Opened #22263 for this.
> > 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;
>
> Agreed.
Nothing to be done here.
> > 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;
>
> Agreed.
Also part of #22263.
> > 4. leave metrics-lib's `TorperfResults` unchanged and just say that
it supports new fields added in version 1.1;
>
> Agreed.
Nothing to be done here. We don't explicitly say which minor versions are
supported. Maybe we should, but in that case we should do that for all
descriptor types. In any case, this shouldn't block closing this ticket.
> > 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`.
>
> I would suggest `torperf-1.1.csv` to reflect the type version.
Done.
> > 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?
>
> That all makes sense. Fine.
Okay, great. I think we're done here now. Thanks for reviewing!
Closing.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22122#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs