Opened 3 months ago

Closed 3 months ago

#29523 closed enhancement (wontfix)

advertised bandwidth graph could better represent short horizon change

Reported by: starlight Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics/Website Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Fifty Quintex relays went offline at 2/16/2019 07:03 UTC and advertised bandwidth for exit and exit+guard relays dropped 9.1% from 11457731000 to 10412355000; remained there for over one day. According to

https://metrics.torproject.org/bandwidth-flags.png?start=2019-02-14&end=2019-02-18

nothing happened.

Child Tickets

Attachments (3)

better_advt_bw.png (29.6 KB) - added by starlight 3 months ago.
better stacked advertised bandwidth
better_advt_bw_alt.png (24.7 KB) - added by starlight 3 months ago.
better line advertised bandwidth
better_advt_bw_alt2.png (51.9 KB) - added by starlight 3 months ago.
two-scale variant

Download all attachments as: .zip

Change History (10)

Changed 3 months ago by starlight

Attachment: better_advt_bw.png added

better stacked advertised bandwidth

Changed 3 months ago by starlight

Attachment: better_advt_bw_alt.png added

better line advertised bandwidth

comment:1 Changed 3 months ago by starlight

If one squints hard metrics graph does faintly represent the large shift in advertised bandwidth. Attached graphs much clearer. Perhaps a non-stacked graph with a separate automatic scale for each class would work better? 10% move in exit bandwidth has a huge impact, but appears minor relative to the all class total.

comment:2 Changed 3 months ago by karsten

I didn't fully understand the suggestions above yet, but also see #29330 for a somewhat related ticket.

comment:3 Changed 3 months ago by starlight

Summary: advertised bandwidth graph is brokenadvertised bandwidth graph could better represent short horizon change
Type: defectenhancement

apologies for the grouch summary

Changed 3 months ago by starlight

Attachment: better_advt_bw_alt2.png added

two-scale variant

comment:4 Changed 3 months ago by starlight

Uploaded the line-graph with Guard on the primary Y-axis and the rest on secondary Y-axis. Difficult to coerce Excel into displaying more than two, but this is the idea. I've seen many an engineering plot with several Y-axis scales stacked on one side or the other.

Guard bandwidth much more interesting in this rendition.

comment:5 Changed 3 months ago by karsten

Okay, I now understand better what this ticket is about. Ignore my remark above, #29330 is unrelated.

So, there are two things to consider here:

  1. The graph on Tor Metrics has a data granularity of 24 hours whereas yours has 3 hours. The clear cut in your graph is much less clear when looking at 24 hour averages. Unfortunately, there's not much we can do about this with our current graphing engine. Using daily averages is an easy way to reduce the overall amount of data, and for most use cases it's sufficient. There will always be edge cases when more detail is better, but I'm afraid that we can't address those cases with our current resources.
  1. It's certainly possible to provide a different view on the data by plotting four lines rather than four stacked areas. I'm aware that stacked area plots are not perfect. But they have advantages, too, including showing the overall bandwidth and how each class of relays contributes to that. What we could do, however, is make this configurable by offering stacked area vs. line plot. That could be part of #29340. Still, I don't know if the drop you refer to would be more visible in a plot with four lines and a data granularity of 24 hours.

Does this make sense? Sorry, I'm afraid there's not much we can do here.

comment:6 Changed 3 months ago by starlight

Fair enough on all points. Spent some time reading #29330, #29340 and I observe this area of metrics is undergoing review and potential revision. If the graphs are rewritten please consider incorporating a selectable layout as described in (2) and supporting some manner of per-class Y-axis scaling, perhaps by allowing user determination of which class(es) to display.

Also I promote the idea of supporting higher resolution graphs for recent history, perhaps three or six months, where sharp perturbations will etch clearly. The graphs uploaded to this ticket posses one-hour resolution, drawn from a relay and including every interval of consensus and descriptor data. Relay bandwidths and consensuses change in lively fashion and Metrics graphs ought to express that.

Please feel free to close this ticket.

comment:7 Changed 3 months ago by karsten

Resolution: wontfix
Status: newclosed

I made a remark on #29340 to consider providing an option for lines rather than stacked areas. I'm still not sure whether that would help much, but we can try when working on that ticket.

Making the set of displayed classes configurable would probably be too much for our current graphing engine. If people want to configure graphs even more, they should fetch the CSV file and possibly our graphing code and make their own graphs.

As indicated above, higher-resolution graphs are out of scope for now. We lack the resources to provide those.

Thanks for the suggestions! Closing.

Note: See TracTickets for help on using tickets.