[tor-relays] Authorithy clock skew in consensus health page

torjoy south_america_bridges at protonmail.com
Wed Dec 16 20:16:58 UTC 2020


Thanks for the answers!


Here in my home middle relay I like to keep timing accurate, just because i work with timming applications and this is also an hobby for me. So, the screenshot below is from my chrony's daemon that syncs time throught an ssh tunnel for an remote NTP server i also manage... Concerning you told about the clock skew being of 1 or 2 seconds in some cases and in others some minutes... I just think i'm doing just fine with this accuracy. I will read the documents, i just thought that tor can take advange of very accurate timming (of few milisseconds or even microsseconds accuracy).

Regards,

Luiz




Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Em terça-feira, 15 de dezembro de 2020 às 06:22, Roger Dingledine <arma at torproject.org> escreveu:

> On Tue, Dec 15, 2020 at 04:43:53AM +0000, torjoy wrote:
>
> > Its just a curiosity question... What is the reference source used in comparsions of authorities clock skew in consensus health?
>
> There are two "consensus health" tools, DepicTor and DocTor:
> https://gitweb.torproject.org/depictor.git/tree/
> https://gitweb.torproject.org/doctor.git/tree/
>
> And I think if this is the page you're talking about:
> https://consensus-health.torproject.org/#authorityclocks
> it is generated by DepicTor.
>
> > Are they synced throught NTP daemons (like chrony or opentpd for example)?
>
> The directory authorities each use whatever tools they want to use
> for keeping their time accurate. I imagine that yes, many of them use
> some sort of ntpd.
>
> > TOR can take advange of very accurate timing in the authorities and relays? I know that just few seconds (or miliseconds?) are fine of clock offset. And if the relay's clock has some fluctuation of hundreds of miliseconds? For example going from -100mS of offset to +300mS offset and them to -200 mS offset...
>
> Correct, clock problems on the order of a second or two are fine.
>
> In fact, I don't think that DepicTor's measurement will be more accurate
> than that anyway, because I think the number comes from looking at the
> Date stamp in the http header of the response, and comparing it to what
> time the local DepicTor script thinks it is. So there will be issues
> like network latency that affect it in tiny ways.
>
> > I mean, too much clock noise can be a problem for TOR?
>
> Correct. For directory authorities, they need to synchronize within
> a minute or so, because of the timing required for voting about the
> consensus documents:
> https://spec.torproject.org/dir-spec
>
> Relays can handle some more skew than that, but if they get too skewed
> then they will start fetching and serving the wrong directory information.
>
> Hope that helps,
> --Roger
>
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ntp.png
Type: image/png
Size: 45867 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20201216/d6eff1cb/attachment-0001.png>


More information about the tor-relays mailing list