> On 2 May 2018, at 18:32, Iain Learmonth <[email protected]> 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 _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
