Opened 3 months ago

Closed 3 months ago

Last modified 2 months ago

#29854 closed defect (not a bug)

Missing diagnostic keys in relay lines, but the data is in the header

Reported by: teor Owned by: juga
Priority: Medium Milestone: sbws: 1.1.x-final
Component: Core Tor/sbws Version:
Severity: Normal Keywords: tor-bwauth, sbws-1.0-must-moved-20181128, sbws-11x-final-removed-20190312, sbws-110-proposed, changes-version-minor
Cc: pastly, juga Actual Points:
Parent ID: #28547 Points:
Reviewer: teor Sponsor:

Description

These keys are in the bandwidth file header, but there are not any similar keys in the relay lines:

  • recent_priority_list_count
  • recent_priority_relay_count
  • recent_measurement_attempt_count
  • recent_measurement_failure_count

Counting the number of times that a relay was put in the priority list is useful, so we can find out if a relay is not being prioritised.

Similarly, counting the number of times that we can't measure a relay is also useful.

Can we have these keys in each relay line:

  • relay_recent_measurement_attempt_count
  • relay_recent_measurement_failure_count

Child Tickets

Change History (7)

comment:1 in reply to:  description Changed 3 months ago by juga

Replying to teor:

These keys are in the bandwidth file header, but there are not any similar keys in the relay lines:

  • recent_priority_list_count

There's "relay_recent_priority_list_count": https://github.com/torproject/sbws/blob/0333fadc221baf17d429f55261842f9f6e09ba5b/sbws/lib/v3bwfile.py#L590. But i forgot to add it in the example in #29754.

  • recent_priority_relay_count

This would be the number of relays that were in a priority queue when this relay was prioritized?.
I'm not sure it's useful.

  • recent_measurement_attempt_count

There's "relay_recent_measurement_attempt_count": https://github.com/torproject/sbws/blob/0333fadc221baf17d429f55261842f9f6e09ba5b/sbws/lib/v3bwfile.py#L590. But i forgot to add it in the example in #29754.

  • recent_measurement_failure_count

This's the one that we might be able to guess after all the others. I don't think it's possible to know it during the measurement, since it would be the case when the queued relay didn't end up in the worker thread measure_relay nor the callback result_putter nor the callback error result_putter_err.
These would happen when the code reach this point: https://github.com/torproject/sbws/blob/0333fadc221baf17d429f55261842f9f6e09ba5b/sbws/lib/v3bwfile.py#L590

Counting the number of times that a relay was put in the priority list is useful, so we can find out if a relay is not being prioritised.

Similarly, counting the number of times that we can't measure a relay is also useful.

Can we have these keys in each relay line:

  • relay_recent_measurement_attempt_count

It is, see above.

  • relay_recent_measurement_failure_count

Don't see how, see above.

If you agree with it, this ticket can be closed.

comment:2 Changed 3 months ago by juga

Another key that i forgot to add in the spec example: "relay_in_recent_consensus_count"

comment:3 Changed 3 months ago by juga

Status: assignedneeds_review

comment:4 in reply to:  3 Changed 3 months ago by juga

Replying to juga:

https://github.com/torproject/sbws/pull/355

This PR is actually for #29853.

If you agree with it, this ticket can be closed.

comment:5 Changed 3 months ago by asn

Reviewer: teor

comment:6 Changed 3 months ago by teor

Resolution: not a bug
Status: needs_reviewclosed

comment:7 Changed 2 months ago by teor

Milestone: sbws: 1.1.0sbws: 1.1.x-final

Move sbws 1.1.0 tickets into 1.1.x-final, to match Tor's milestone scheme.

Note: See TracTickets for help on using tickets.