Decide whether to make bwauth output available

The various bandwidth authorities write down all sorts of stuff as they operate. We should figure out what of this stuff we want to save, and get it recorded on the metrics archive for posterity.

(Later we will want to figure out what of it is worth graphing, presenting to other researchers as performance details, etc)

Child tickets: [[TicketQuery(parent=#2532 (moved))]]

added component::metrics/analysis owner::karsten priority::low resolution::wontfix severity::blocker status::closed type::task labels

Trac:
Description: The various bandwidth authorities write down all sorts of stuff as they operate. We should figure out what of this stuff we want to save, and get it recorded on the metrics archive for posterity.

(Later we will want to figure out what of it is worth graphing, presenting to other researchers as performance details, etc)

to

The various bandwidth authorities write down all sorts of stuff as they operate. We should figure out what of this stuff we want to save, and get it recorded on the metrics archive for posterity.

(Later we will want to figure out what of it is worth graphing, presenting to other researchers as performance details, etc)

Child tickets: TicketQuery(parent=#2532)

I'll have a look at the logs of my bandwidth scanner and make some guesses what data we might want to keep. Mike, if you have any ideas what stuff you want to keep in the archives, please let me know.

Trac:
Cc: N/A to mikeperry
Status: new to accepted

I think we want to do #2394 (moved) before we think about this bug. We aren't even visualising what the bw authorities are doing. That is step 1. Step 2 can be deciding which parts of how they do it are useful for further improvements.

We also want to do #2551 (moved) before this. Any circuit data we collect should come from TorPerf, not the bandwidth auths.

Mike says:

In my opinion we really really want to drop #2532 (moved) and replace it with https://trac.torproject.org/projects/tor/ticket/2394 and/or just call #2394 (moved) the actual way we want to implement #2532 (moved). We need a way to visualize and store the bw auth votes before we heave the sql data at anyone. In fact, I wonder if they'd even use the sql data if we provided it after doing #2394 (moved). People who need that level of detail should just be running their own bandwidth auths (a process we should make simpler).

I'm changing priority to minor and removing the milestone.

Trac:
Priority: normal to minor
Milestone: Deliverable-May2011 to N/A

Moving to the Analysis component and changing the summary to reflect that we first need to decide whether it makes sense to publish the bwauth output. Once we're sure, we should create a Metrics Data Processor ticket to collect the data and then a Metrics Website ticket to make it available.

Trac:
Component: Metrics to Analysis
Summary: get bwauth output up on metrics website to Decide whether to make bwauth output available

So, Mike thinks we shouldn't collect any data from the bandwidth authorities, because they're not as useful as the Torperf data.

I think we shouldn't start collecting data that we don't know exactly what to do with, because of the poor guy that has to maintain the data collection and processing code in the future.

I'm going to close this ticket. Please re-open if there are good reasons to collect bwauth data despite the stated two reasons against it.

Trac:
Status: accepted to closed
Resolution: N/A to wontfix

I think this is being done in #21377 (moved)

Trac:
Sponsor: N/A to N/A
Reviewer: N/A to N/A
Severity: N/A to Blocker

closed

mentioned in issue #2533 (moved)