Re: [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:  closed
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:  fixed
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-
Changes (by karsten):

 * status:  merge_ready => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:16 karsten]:
 >  1. Squash and merge to master.

 Done yesterday.

 >  2. Put out a release, possibly adapting the change log.

 Done yesterday.

 >  3. Update the specification page on metrics-web.

 Actually, the specification page does not say which detail a given graph
 is supposed to have, and we did not yet add a new 6 month graph. So, we
 don't have to update the specification page. Which also makes sense,
 because we did not change the protocol version number.

 >  4. Coordinate deployment by making backups and then updating.

 Done yesterday.

 >  5. Create tickets for the suggested medium-term and long-term changes.

 Created #25175 and #25176 for this today.

 >  6. Maybe also create a ticket for removing redundant graphs in the
 clients document.

 Created #25177 for this today.

 I think that addresses all next steps. Closing as fixed. Thanks for all
 the input!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-

Comment (by karsten):

 Ah, great. Sorry for moving forward without waiting for your reply. I
 thought it would be good to get this deployed rather sooner than later. We
 can adjust things later on as needed.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-

Comment (by irl):

 This looks fine to me. Sorry for taking a while to get to replying.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  merge_ready
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:  iwakeh   |Sponsor:
-+-
Changes (by karsten):

 * status:  needs_review => merge_ready


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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):

 Actually, we could as well move forward with what we have. The changes to
 3 months graphs are easily reversible, because they don't affect files in
 `status/` but only files in `out/`. If we later find out we want something
 else, we can simply write new `out/` files. Let's rather deploy what we
 have, because the current situation is bugging too many users.

 As commented on #16513, I squashed all fixup/squash commits and pushed to
 master. I'm now preparing a release. Leaving this ticket open until we're
 done with all 6 steps above.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:
-+--
Changes (by karsten):

 * cc: irl (added)


Comment:

 Replying to [comment:17 iwakeh]:
 > The commits look fine (also commented on #16513 for the two related to
 that ticket), pass the usualy tests

 Sounds great. Thanks for checking!

 > I leave this on review as the solution plan and graphs might need
 feedback from others, too.

 irl, that would be you. Any thoughts? :)

 > Next steps in comment:16 seem fine to me.

 Okay.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 iwakeh):

 The commits look fine (also commented on #16513 for the two related to
 that ticket), pass the usualy tests

 I leave this on review as the solution plan and graphs might need feedback
 from others, too.

 Next steps in comment:16 seem fine to me.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online

Re: [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:
-+--
Changes (by karsten):

 * Attachment "3-month-graph-with-24-hour-resolution.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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):

 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.

 [[Image(relay-search-upsampled.png, width=700px)]]

 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.
- 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.
  - Medium-term fix:
- We start retaining data in statuses on 24 hour granularity rather
 than 48 hours for up to 6 months.
- 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.
  - 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.
- 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.

 I can try this out this afternoon. Does this make sense?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:
-+--
Changes (by karsten):

 * Attachment "relay-search-upsampled.png" added.


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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: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: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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 iwakeh):

 The suggestion in comment:4 seems ok, technically all data for shorter
 graphs can be taken from there.
 Can the clients using the data provide all useful/needed graphs with this
 change and deal with possibly omitted data?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:
-+--
Changes (by iwakeh):

 * reviewer:   => iwakeh


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:   |Sponsor:
-+--
Changes (by karsten):

 * status:  accepted => needs_review


Comment:

 Setting to needs_review to get a review of the idea above to add 6 month
 graphs and skip graphs as soon as we run into a single data point with too
 long reporting period.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  accepted
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * status:  new => accepted
 * owner:  metrics-team => karsten


Comment:

 Accepting this ticket as something I'm going to work on over the next
 week.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Replying to [comment:4 karsten]:
 > Here's a possibly smarter idea. We add a 6 month history object with a
 data resolution of 1 day. And we skip graphs if the reported data interval
 of even a single data point is higher than the graph interval.

 irl, iwakeh, I'm curious what you think about this idea!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:  #24155   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by karsten):

 * parent:   => #24155


Comment:

 Replying to [comment:6 teor]:
 > This is related to the metrics ticket #24155 about the tor reporting
 change in #23856. There's also #24829 about the graphs we show.
 >
 > Maybe #24155 should be the parent here? (How does metrics do parent
 tickets?)

 Sure, can't hurt. (I'd say we do parent tickets in a similar way as other
 teams.)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by teor):

 This is related to the metrics ticket #24155 about the tor reporting
 change in #23856. There's also #24829 about the graphs we show.

 Maybe #24155 should be the parent here? (How does metrics do parent
 tickets?)

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
Changes (by sjcjonker):

 * cc: sjcjonker@… (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Here's a possibly smarter idea. We add a 6 month history object with a
 data resolution of 1 day. And we skip graphs if the reported data interval
 of even a single data point is higher than the graph interval.

 Let me illustrate this idea by giving a table of all documents containing
 histories together with their graph intervals (columns), data resolution
 (cells), and maximum number of data points (in parentheses):

 ||=''document'' =||=''3 days'' =||=''1 week''=||=''1 month''
 =||=''3 months''   =||=''6 months''=||=''1 year'' =||=''5 years''
 =||
 ||clients|| ||'''~~1 day (7)~~''' ||'''~~1 day
 (31)~~''' ||'''~~1 day (92)~~''' ||'''1 day (183)''' ||2 days (183) ||10
 days (183) ||
 ||bandwidth  ||15 minutes (288) ||1 hour (168)||4 hours (186)
 ||12 hours (184)   ||'''1 day (183)''' ||2 days (183) ||10 days (183)
 ||
 ||uptime || ||1 hour (168)||4 hours (186)
 ||12 hours (184)   ||'''1 day (183)''' ||2 days (183) ||10 days (183)
 ||
 ||weights|| ||1 hour (168)||4 hours (186)
 ||12 hours (184)   ||'''1 day (183)''' ||2 days (183) ||10 days (183)
 ||

 Example: The 3 days bandwidth graph has a data resolution of 15 minutes
 which means that it can hold up to 288 data points (3 * 24 * 60 / 15 =
 288).

 Suggested changes in bold are to add a 6 months graph with a resolution of
 1 day and also to drop the shorter graphs from clients documents with a
 data resolution of 1 day. (The latter is unrelated to this change, but why
 not clean up here now that we discovered this redundancy.)

 How does this sound?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [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:  metrics-team
 Type:  defect   | Status:  new
 Priority:  High |  Milestone:
Component:  Metrics/Onionoo  |Version:
 Severity:  Major| Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by karsten):

 Here's what happened:
  - The relay upgraded from a tor software version reporting bandwidth for
 4 hour intervals to 0.3.2.6-alpha on December 2 and later downgraded to a
 pre-0.3.2.6-alpha version on December 21. During that time it reported
 bandwidth values for 24 hour intervals.
  - Onionoo's 1 month graph has a fixed data point interval of 4 hours. It
 cannot report data with a resolution of only 1 data point per 24 hours.
 That's why Onionoo includes all those `null` values, simply meaning that
 it doesn't know how much bandwidth the relay read or wrote during that
 time.
  - Relay search displays those `null` values as `0` values, which it
 shouldn't do. Knowing that a relay pushed 0 bytes is a different thing
 than not knowing how many bytes it pushed.
  - Only the 1 month and 3 months graphs are affected, because they have a
 data resolution of 4 hours and 12 hours, respectively. Look at the 1 year
 graph with a data resolution of 48 hours and which doesn't have a gap in
 December 2017.
  - Note that this is the same issue that leads to blank 1 month and 3
 month graphs and non-blank 1 year graphs for new relays.

 Is this a bug in Onionoo? Probably.

 What can we do? We could go through all reported data points for a given
 graph and pick the largest interval as data point interval. That is, if
 all data points have an interval of 4 hours, we produce graph data with 1
 data point per 4 hours. But if there's at least 1 reported data point with
 an interval of 24 hours, we aggregate all data for that graph to 1 data
 point per 24 hours.

 A possible downside is that the graphs for 3 months, 1 month, 1 week, and
 3 days will basically contain the exact same data. Maybe we can do
 something smart to avoid providing data that is too redundant, but not too
 smart in order to not move too much logic into clients.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #24729 [Metrics/Onionoo]: Find reason for 'null' values in Onionoo document (was: This relay shows that there was 0 read/write bytes per second for almost a month)

[Tor Bug Tracker & Wiki]

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

Old description:

> This relay shows that there was 0 read/write bytes per second for almost
> a month even though the Consensus Weight stays above 8000.
> https://atlas.torproject.org/#details/5D86AFD7CE409251E67B373B4F0E780A0F41C944

New description:

 See comment:1 for a data example.
 Next steps:
 * determine possible cause of null-values (incl. data check on CollecTor)
 * discuss, if this is a desirable feature or bug
 * fix cause, if ncessary


 ---
 Initial report:
   This relay shows that there was 0 read/write bytes per second for almost
 a month even though the Consensus Weight stays above 8000.
 https://atlas.torproject.org/#details/5D86AFD7CE409251E67B373B4F0E780A0F41C944

--

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs