[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