Re: [chrony-users] Quickly syncing time |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
- To: chrony-users@xxxxxxxxxxxxxxxxxxxx
- Subject: Re: [chrony-users] Quickly syncing time
- From: Miroslav Lichvar <mlichvar@xxxxxxxxxx>
- Date: Tue, 9 May 2017 14:35:34 +0200
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=mlichvar@xxxxxxxxxx
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5BF2D80B20
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5BF2D80B20
On Sat, May 06, 2017 at 08:52:40AM -0700, Deven Hickingbotham wrote:
> I have a GPS app that runs on a Raspberry Pi. The system is powered off
> most of the time, but on startup needs to sync time very quickly using PPS.
>
> It looks like the makestep directive is the way to do this. Which of the
> following would be better?
>
> makestep 0.01 10
>
> makestep 0.01 -1
>
> The first would make adjustments during the first 10 updates, while the
> second would do so continuously, correct? Note: none of the apps running
> would be adversely affected by jumps in the clock (they would benefit by
> having more accurate time).
Unless the system will be offline for very long intervals (e.g.
months), in which it could gain a very large offset, which would take
too long to correct, or it can be suspended and resumed without an
RTC, it's better to limit the number of updates in which the clock is
allowed to be stepped.
It provides a partial protection against some MITM attacks, where the
attacker would try to step the clock years ahead in order to expire
certificates, etc. If the clock can be stepped only on start, a MITM
attack after that can at worst speed up or slow down the clock, with
no possibility to jump years ahead.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.