Opened 3 weeks ago

Last modified 12 days ago

#30612 needs_revision enhancement

Replace timeouts-and-failures graph with errorcodes graph

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

Description

The ERRORCODE field discussed in #29787 is going to add much more detailed information about timeouts and failures of OnionPerf measurements. We should just throw out our timeouts-and-failures graph and replace it with a graph similar to this one suggested on #29787. This ticket is for adding that graph to the website.

Child Tickets

Attachments (2)

onionperf-errorcodes-public.png (89.1 KB) - added by karsten 2 weeks ago.
onionperf-errorcodes-onion.png (87.8 KB) - added by karsten 2 weeks ago.

Download all attachments as: .zip

Change History (5)

Changed 2 weeks ago by karsten

Changed 2 weeks ago by karsten

comment:1 Changed 2 weeks ago by karsten

Reviewer: irl
Status: newneeds_review

Here are two samples of the new graph containing error codes rather than generic failures and timeouts:



These are based on graphs I made for #29787 where we discussed how to extract error codes from logs. The graphs above are tailored for the Tor Metrics website.

Setting needs_review for the graphs. The code will have to wait until #29787, #30602, and #30610 are resolved.

comment:2 Changed 13 days ago by irl

Status: needs_reviewneeds_revision

This graph is heading in the direction of graphs that are interesting for us but not so useful to put on Tor Metrics. This is not an easy graph to explain to the general public. Explaining cases where tor might refuse to attach a stream to a circuit goes way beyond what we've had to explain in other graphs.

It's also a very busy plot, that might be concealing information. When bars are on top of each other it is not clear if there is a consistent z-order or if it is somewhat intelligent to show shorter bars on top?

Is there some middle ground for a plot between this one and the one currently on Tor Metrics that is simpler to explain but still is more detailed than the current one?

comment:3 in reply to:  2 Changed 12 days ago by karsten

Replying to irl:

This graph is heading in the direction of graphs that are interesting for us but not so useful to put on Tor Metrics. This is not an easy graph to explain to the general public. Explaining cases where tor might refuse to attach a stream to a circuit goes way beyond what we've had to explain in other graphs.

I see what you mean.

How about we write a specification/description what these error cases mean for ourselves and decide later whether that's digestible for Tor Metrics users? Worst case we decide against adding this graph but still have a description for a graph we discuss internally.

It's also a very busy plot, that might be concealing information. When bars are on top of each other it is not clear if there is a consistent z-order or if it is somewhat intelligent to show shorter bars on top?

It is indeed a lot of information, though I don't think it's concealing anything. If two OnionPerf instances had the same error type on a given day the two bars are stacked. Admittedly, this isn't obvious and would require a half sentence in the explanation.

Is there some middle ground for a plot between this one and the one currently on Tor Metrics that is simpler to explain but still is more detailed than the current one?

What parts would you simplify?

For example, we might reduce the number of error types by picking the most common ones and using an "other" category for the rest. This would require making sense of the error types, though, which is something we should do anyway.

Or did you have anything else in mind?

Thanks for the feedback!

Note: See TracTickets for help on using tickets.