[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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:
---------------------------+--------------------------------
Changes (by irl):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:11 karsten]:
 > I experimented a bit with this and came to the conclusion that we should
 probably avoid mixing 50 KiB, 1 MiB, and 5 MiB measurements and instead
 focus on 1 MiB measurements only. Otherwise we might see confusing results
 where, for example, partial 5 MiB downloads are completed faster than full
 1 MiB downloads on some days. Also, I could imagine that 1 MiB is still a
 reasonable size for LTE experiments, whereas 5 MiB is too large and 50 KiB
 too small.

 My understanding for this one was that instead of performing three
 downloads, we would modify OnionPerf to only perform the one download, and
 derive values for smaller file sizes from the partial completion times.

 Perhaps we need to modify OnionPerf to report different numbers, instead
 of percentiles. I think useful sizes would be 50K, 200K, 500K, 1M, 2M and
 5M. To conserve bandwidth on the LTE probe(s) we could limit the downloads
 to 1M, although we'd have to see if we actually want to include those on
 Tor Metrics or just do a one-off analysis.

 I am confused as to why exit circuits completed faster than onion
 circuits. Are you comparing `DATAPERCx` to `DATARESPONSE` or to `START`? I
 wonder if there's enough overhead in circuit setup that 1M is not enough
 time to see benefit from using an onion circuit instead.

 Replying to [comment:12 karsten]:
 > In addition to the third graph on partial downloads above, please also
 review [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-25774&id=2761d1f733989a5c5aa5d9a4af69ea9153bc4b8f
 commit 2761d1f in my task-25774 branch] which implements the first two
 graphs on build times and latencies as discussed earlier.

 I do not have an environment set up for metrics-web's statistics or
 Rserve, only for running enough to test Relay Search at the moment, so I
 have not run the code. The titles, descriptions and URLs all look good and
 I did not find any obvious errors in the Java, R or SQL.

 I would not object to this being merged, but it's up to you if you want to
 wait for me to have a test environment set up.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25774#comment:13>
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