[metrics-bugs] #30238 [Metrics/Onionperf]: OnionPerf json analysis file is different than the one recreated from logs

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed May 6 14:16:06 UTC 2020


#30238: OnionPerf json analysis file is different than the one recreated from logs
---------------------------------------+---------------------------
 Reporter:  acute                      |          Owner:  karsten
     Type:  defect                     |         Status:  closed
 Priority:  Medium                     |      Milestone:
Component:  Metrics/Onionperf          |        Version:
 Severity:  Normal                     |     Resolution:  duplicate
 Keywords:  metrics-team-roadmap-2020  |  Actual Points:  0.5
Parent ID:                             |         Points:  2
 Reviewer:                             |        Sponsor:  Sponsor59
---------------------------------------+---------------------------
Changes (by karsten):

 * status:  accepted => closed
 * resolution:   => duplicate
 * actualpoints:   => 0.5


Comment:

 I found the issue!

 The difference comes from running the analysis ''with'' or ''without'' the
 `-d` or `--date-filter` parameter:
  - Running it ''without'' that parameter produces an analysis file that is
 16 MiB large in uncompressed form and that contains measurements from that
 day and the day before. This is what I assume acute did when recreating
 files.
  - Running it ''with'' that parameter produces an analysis file that is
 7.7 MiB large in uncompressed form and that contains only measurement from
 that day. This is what OnionPerf does by default at midnight.

 I think this is closely related to #29369 or even a duplicate. It happens
 when OnionPerf wasn't running at midnight. We need to fix what we do in
 that case, but it seems like #29369 is the better place for that. At least
 we now know that this ticket is not about some entirely unknown issue and
 the files produced by OnionPerf are usable. In fact, OnionPerf was doing
 exactly what it was supposed to do in both cases, just not what one might
 expect it to do.

 This only took a fraction of the expected time, because the bug hunt was
 comparatively easy and no reprocessing of past measurement files to be
 served by CollecTor was necessary.

 Closing as duplicate.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30238#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the metrics-bugs mailing list