[tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document

[Tor Bug Tracker & Wiki]

#24729: Find reason for 'null' values in Onionoo document
-----------------------------+------------------------------
 Reporter:  Dbryrtfbcbhgf    |          Owner:  karsten
     Type:  defect           |         Status:  needs_review
 Priority:  High             |      Milestone:
Component:  Metrics/Onionoo  |        Version:
 Severity:  Major            |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:  #24155           |         Points:
 Reviewer:  iwakeh           |        Sponsor:
-----------------------------+------------------------------

Comment (by karsten):

 Replying to [comment:15 iwakeh]:
 > Replying to [comment:14 karsten]:
 > > Hmm, no, I don't like my last suggestion anymore after trying it out
 based on the #16513 changes. Those interpolated/upsampled points look much
 more awkward than I had expected. We'd mainly shift confusion from missing
 points to points that look like glitches. Also, we don't really need a 3
 month graph and a 6 month graph.
 >
 > Makes sense.
 >
 > > ...
 > > New plan:
 > >  - Short-term fix:
 > >    - We change just the bandwidth graph for 3 months to a data
 resolution of 24 hours rather than 12 hours. That way it can accommodate
 new statistics along with old statistics.
 >
 > Let's take a look and try how this influences the resulting graphs.

 Alright, I implemented this and attached a sample graph showing 3 months
 of the relay in question in this ticket:

 [[Image(3-month-graph-with-24-hour-resolution.png, width=700px)]]

 The graph of the left is the current graph. It contains `null` values in
 the middle.

 The graph on the right is the new graph. It has fewer data points, but it
 does have the part in the middle and an additional part on the right that
 is not contained in the graph on the left.

 Please review the last four commits in
 [https://gitweb.torproject.org/user/karsten/onionoo.git/log/?h=task-16513-24729
 my task-16513-24729 branch] which is based on your earlier task-16513-2
 branch:

  - 8a14e83 is an important fix related to #16513.
  - 08932a6 is what I suggested as "Tor time" in #16513 and which is
 similar to your suggestion in #25091.
  - b00d44a changes the data resolution of the bandwidth 3 months graph.
  - 5769dca retains histories on a 24 hour granularity for up to 6 months
 rather than 6.

 (Feel free to comment on the first two commits on #16513, if you prefer,
 and on the last two commits on this ticket.)

 > >    - We fix Relay Search to plot `null` as missing data point rather
 than the value `0`. That's going to fix the 1 month graph, and it's the
 right thing to do anyway.
 >
 > This is a ticket, i.e., planned already, afaik.

 Okay.

 > >  - Medium-term fix:
 > >    - We start retaining data in statuses on 24 hour granularity rather
 than 48 hours for up to 6 months.
 >
 > The granularity of one day is a good choice, imo.

 Done. See the fourth commit above.

 > >    - In 3 months from now, we change the 3 months graph to 6 a months
 graph with a resolution of 24 hours.
 > >    - Also in 3 months from now, we change Relay Search to display a 6
 months graph rather than the 3 months graph.
 >
 > Sure, the graphing window should rather be set and computed at the
 client side.

 Right, though in this case I basically meant to change the label from "3
 Months" to "6 Months". Computing things would be left to the long-term fix
 below.

 > >  - Long-term fix:
 > >    - We stop giving out data for fixed intervals and provide all data
 in a single history object along with a normalized x axis with timestamps.
 >
 > A fine goal and the way to go.

 Agreed.

 > >    - We teach Relay Search to draw different graphs based on this
 single history object. Basically, it will need to learn how to downsample
 data points that are too detailed for a graph showing a long period of
 time.
 > >
 >
 > Clients should be able to handle the new data.

 Agreed.

 > > I can try this out this afternoon. Does this make sense?
 >
 > Yes.  It might be good to also hear more from the client/Relay Search
 side here.  And, an opinion of what users expect to see graphed, e.g. six
 vs. three month, granularity etc.

 Hopefully, the attached graphs are sufficient to make a decision on the
 short-term fix. And yes, the medium-term and long-term changes should be
 discussed more on their own tickets.

 So, assuming this review goes through, how do we proceed, and in which
 order?

  1. Squash and merge to master.
  2. Put out a release, possibly adapting the change log.
  3. Update the specification page on metrics-web.
  4. Coordinate deployment by making backups and then updating.
  5. Create tickets for the suggested medium-term and long-term changes.
  6. Maybe also create a ticket for removing redundant graphs in the
 clients document.

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