#25774: Record latency measurements using OnionPerf
---------------------------+--------------------------------
Reporter: irl | Owner: metrics-team
Type: project | Status: needs_revision
Priority: Medium | Milestone:
Component: Metrics/Ideas | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: irl | Sponsor:
---------------------------+--------------------------------
Comment (by karsten):
Replying to [comment:3 irl]:
> Replying to [comment:1 karsten]:
> > If we were to put this on Tor Metrics, we'd probably make the source
configurable and display either all sources at once or just a single one
of them. And we'd probably stack the three graphs for the hops vertically,
rather than horizontally, or alternatively use three colors for the three
hops.
>
> This sounds good. This is not how I was expecting the graphs to look,
the 2nd hop seems to happen faster than the 1st hop. Perhaps there are
some overheads we incur on the 1st hop that regular clients wouldn't have
because we don't use guards. (I don't think we can fix this, it's just
something we should work out and document.)
Indeed, this might be related to us not using guards. And yes, we should
investigate this more and document it.
> It looks like there is overlap in the ranges for the 2nd and 3rd hops,
so I think having separate plots is necessary and putting the 3 on the
same plot with different colours wouldn't be readable.
I was thinking of a graph like
[https://metrics.torproject.org/connbidirect.html our "Fraction of
connections used uni-/bidirectionally" graph]. There's some overlap in
that graph, too. Anyway, we can decide later.
> The plots that share the same row are easier to compare than those that
share the same column, so we should consider what users may want to
compare.
Yes, but. We haven't used more than one graph in the same row on Tor
Metrics. The reason is that all graphs have a configurable time frame on
the x axis, and imagine how this graph would look like with years of data
and 3 graphs next to each other. Also something we can decide later, when
we're more sure what it is that we want to graph.
> For parameters, the current parameters for the existing performance
graphs are all applicable except that it probably does not make sense to
have this for the onion measurements.
Right, it doesn't make much sense to have this for public vs. onion
measurements. Nor does it matter whether we're fetching 50 KiB, 1 MiB, or
5 MiB files. Which basically leaves the source as parameter.
> > I think this already addesses the "circuit build latency" part in the
ticket description. What exactly is meant by "end-to-end latency" there?
Maybe there's data for that, too.
>
> End-to-end latency is the latency to send data across the circuit. From
looking at the TorPerf spec, this would be the difference between
DATAREQUEST and DATARESPONSE divided by 2.
Aha! I'll make another graph for that. Do we want to do the division-by-2
step here, which includes the implicit assumption that both directions are
equally fast, or do we want to use a round-trip metric of some kind? Just
thinking about what would be more intuitive, that is, least confusing for
users.
Thanks for your feedback so far!
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25774#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online