Re: [tor-bugs] #25774 [Metrics/Ideas]: Record latency measurements using OnionPerf

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs