Report relays that sbws sees in the consensus, but never chooses to test
We should count:
- the number of consensuses that sbws has seen a relay in the consensus
- the number of times sbws chooses to test a relay
- the number of times sbws chooses to exclude a relay (for example, because it's an authority)
If there are a large number of exclusions, we should split the exclusions into subcategories.
Activity
changed milestone to %sbws: 1.1.x-final
Trac:
Description: We should count:- the number of consensuses that sbws has seen a relay in
- the number of times sbws chooses to test a relay
- the number of times sbws chooses to exclude a relay (for example, because it's an authority)
to
We should count:
- the number of consensuses that sbws has seen a relay in the consensus
- the number of times sbws chooses to test a relay
- the number of times sbws chooses to exclude a relay (for example, because it's an authority)
If there are a large number of exclusions, we should split the exclusions into subcategories.
Replying to teor: [..]
- the number of times sbws chooses to exclude a relay (for example, because it's an authority)
Authorities are excluded from the possible list of relays to measure (https://gitweb.torproject.org/sbws.git/tree/sbws/lib/relayprioritizer.py#n50). Do you think that it would be needed to report the authorities seen and a keyvalue that says it's an authority?
[..]
Replying to juga:
Replying to teor: [..]
- the number of times sbws chooses to exclude a relay (for example, because it's an authority)
Authorities are excluded from the possible list of relays to measure (https://gitweb.torproject.org/sbws.git/tree/sbws/lib/relayprioritizer.py#n50). Do you think that it would be needed to report the authorities seen and a keyvalue that says it's an authority?
[..]
Authorities are flagged in the consensus. So I think we can just document the authority exclusion.
-
Following the proposed KeyValues in https://pad.riseup.net/p/sbws-exclude-reasons-keep:
- any KeyValue that is based on the last bandwidth file adds more code complexity, because it would mean to read and parse the last bandwidth file
- fetch consensus every hour (instead of every 5min) so that we can assume every consensus fetched is new
- store the number of times a relay is in the consensus
- created a KeyValue to report the number of time a reported relay was in the consensus
- a header KeyValue with the total number of consensus could be calculated as the the maximum number of consensuses in a bandwidth line (maybe missing some?)
- it can't be know the relays that were not in any consensus, since they won't be reported
- it'd be possible to report the number relays that were not in any consensus
Branch: https://github.com/juga0/sbws/tree/ticket28566
Not creating PR, not changing to merge_ready since master is not in 1.1.X version yet.
Trac:
Cc: pastly, juga to N/A
Points: N/A to 1
Owner: N/A to juga
Status: new to assigned -
Replying to juga:
- a header KeyValue with the total number of consensus could be calculated as the the maximum number of consensuses in a bandwidth line (maybe missing some?)
Store the number of times that the consensus is fetched in branch https://github.com/juga0/sbws/tree/ticket28566_01
-
https://github.com/torproject/sbws/pull/345
Rebased on #29591 (moved).
Trac:
Status: assigned to needs_review -
To review from https://github.com/torproject/sbws/pull/345/commits/a3ba9548ade21d6f2674af42e59dc22040ff526f (include)
Hi! I've made some small suggestions throughout the code. It's a little tricky to follow, but I think documenting functions will fix that. Also, I'd strongly suggest documenting what exactly each new field should contain. Once that's done you should feel free to merge.
Trac:
Status: needs_review to needs_revisionmentioned in issue #28868 (moved)