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 karsten):

 Replying to [comment:12 iwakeh]:
 > The suggestion in comment:4 seems ok, technically all data for shorter
 graphs can be taken from there.

 Agreed.

 > Can the clients using the data provide all useful/needed graphs with
 this change and deal with possibly omitted data?

 As of now, clients cannot handle this yet. But I think that's #24831, so
 at least Relay Search will be handle to handle this at some point.

 However, I thought more about omitting data. Maybe we should not do that.
 Here's a new idea:

  - We add a 6 month history object with a data resolution of 1 day. (Same
 as above.)
  - We drop the shorter graphs from clients documents with a data
 resolution of 1 day. (Same as above.)
  - If we compile a graph from a history '''only''' containing entries with
 a data resolution that is too low for the graph (e.g., data is provided
 for 24 hours, but the graph shows data for 12 hours), we skip that graph.
 (Same as we do right now, same as above.)
  - If we compile a graph from a history '''also''' containing entries with
 a data resolution that is too low along with entries with the high-enough
 data resolution (e.g., data is provided for 4 hour intervals, then for 24
 hour intervals, then again for 4 hour intervals), we include that graph
 and interpolate data as necessary. (This suggestion is new. The earlier
 suggestion was to drop this graph.)

 Here's why I think that this suggestion is better:
  - Even if we add a 6 month graph today, the data in current status files
 for 3 to 6 months ago is already compressed to a resolution of 2 days.
 We'd basically have to wait 3 months for 6 month graphs to first appear,
 or we'd have to re-import data. Ewww.
  - I'm worried that there are edge cases where we're compressing data in
 status files a tiny bit too early. The effect might be that we're not
 providing any graphs at all.

 Here's a possible issue that I see with this suggestion:
  - Whenever a relay changes its reporting interval, graphs will suddenly
 be a lot less volatile, which might confuse relay operators wondering what
 happened. But I think the explanation that their relay is now reporting
 data on a lower resolution should be obvious enough to quickly answer
 those questions.

 I did not implement this, because I'd still want us to resolve #16513
 first. Raising priority on that even more, so that we can finally resolve
 this one.

 How does this plan sound?

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