[metrics-team] inconsistent eff. family counter in Relay Search
nusenu
nusenu-lists at riseup.net
Fri Jan 26 06:01:00 UTC 2018
While trying to understand why atlas / Relay Search
displays inconsistent family counters I stumbled on a minor bug.
Unfortunately this was only observed on data from
2018-01-26 04:00:00 UTC and the problem disappeared in the data from
2018-01-26 05:00:00 UTC.
(I have the full details files if need should be)
https://atlas.torproject.org/#search/family:FC9AC8EA0160D88BCCFDE066940D7DD9FA45495B
The effective_family counters displayed next to the nickname is probably implemented
as len(effective_family)+1 but should be len(effective_family-self)+1.
This could be fixed in onionoo by always or never include the self fingerprint
in the effective_family array.
I like teor's suggestions for priorities so I'm including it here:> When someone asks for a task, they could tell you:
> * how important it is
This is a "nice-to-have" display fix
> * when they need it done by
There is no actual hard requirement.
Maybe by the end of the year 2018?
> * what will happen if it's not done
A minor number of relay operators might be confused by incorrectly
displayed eff. family member counters (but most don't know the meaning
of that number and so it might be not that confusing after all)
minor documentation bug:
https://metrics.torproject.org/onionoo.html#details_relay_effective_family (and other places)
> Array of $-prefixed fingerprints
they are no longer $-prefixed
--
https://mastodon.social/@nusenu
twitter: @nusenu_
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20180126/9b83b352/attachment.sig>
More information about the metrics-team
mailing list