Opened 6 months ago

Last modified 6 months ago

#33896 new defect

Depictor: stop claiming so many digits of precision for clock skew

Reported by: arma Owned by: tom
Priority: Medium Milestone:
Component: Metrics/Consensus Health Version:
Severity: Normal Keywords:
Cc: metrics-team Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In
https://consensus-health.torproject.org/#authorityclocks
we state clock skew numbers like "-0.386114 seconds".

There's no way that 114 part is at all accurate, since this figure is influence by (for example) network latency, Tor processing latency, etc.

We list only 1 or 2 or 3 digits after the decimal point. I'm thinking two digits would be a nice balance.

Motivated by the discussion on tor-relays@:
https://lists.torproject.org/pipermail/tor-relays/2020-April/018372.html

Child Tickets

Change History (2)

comment:1 Changed 6 months ago by tom

ACKing. This is trivial, but I don't expect I'll get to it until the quarantine is lifted.

comment:2 Changed 6 months ago by teor

NTP is accurate to within 1-100 milliseconds:
https://en.m.wikipedia.org/wiki/Network_Time_Protocol

So we definitely don't need to show the third digit.

It's unlikely we will ever care about the first or second digit. But if there are ever race conditions in the authority voting code, it could be useful to know which authority goes first.

It's worth noting that we show consensus download times in milliseconds. So maybe we could use millisecond precision for consistency?
https://consensus-health.torproject.org/#downloadstats

That said, most of the other times are in seconds.

Note: See TracTickets for help on using tickets.