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

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

#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 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.

 >    - 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.


 >  - 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.

 >    - 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.

 >  - 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.

 >    - 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.

 > 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 etc.

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