On 2 May 2018, at 18:32, Iain Learmonth irl@torproject.org wrote:
On 02/05/18 02:09, Keifer Bly wrote: My suspicion is that my posted uptime was retained because I did not restart the relay software while my router firmware was updating (it was offline for about 2 hours), but it thought I’d share this little thing I noticed.
You're correct. The uptime that is shown in relay search is calculated from your relay's self-reported last restart time. This means that if your relay has not restarted, it will have the same last restart time when it rejoins the consensus and your uptime will not start back from zero.
Downtime on relay search is calculated from the time that the relay was last seen in a consensus, so this would start from zero at the first consensus that does not include your relay (and so also only has a resolution of one hour, whereas your last restart time has a resolution of one second).
Onionoo (the relay search backend) does keep track of the fractional time a relay was included in the consensus for a given time period in the "relay uptime documents":
https://metrics.torproject.org/onionoo.html#uptime
This could be confusing, as now we have two definitions for uptime: 1) the relay was running and may or may not have been in the consensus, or 2) the relay was in the consensus. Maybe we should fix the ambiguity.
Being in the consensus is called "Running", but what it actually means is that a majority of directory authorities found your relay reachable.
So perhaps we could use: * uptime for the amount of time since the tor process started * reachable time for the amount of time the relay has been online and available to clients
T