Hi all,
Its just a curiosity question... What is the reference source used in comparsions of authorities clock skew in consensus health? Are they synced throught NTP daemons (like chrony or opentpd for example)? 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... I mean, too much clock noise can be a problem for TOR?
Best regards,
Luiz
Sent with [ProtonMail](https://protonmail.com) Secure Email.
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
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@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
Roger Dingledine -
torjoy