Force o ntpd a fazer mudanças em etapas menores

Question

A documentação do NTP diz:

Under ordinariy conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities - http://doc.ntp.org/4.1.0/ntpd.htm

No entanto, isso não é nada do que eu notei na prática. Se eu alterar manualmente o tempo do sistema para trás ou para frente 5 ou 10 segundos, inicie ntpd , noto que ele ajusta o relógio de uma só vez.

Por exemplo, com este código:

#!/usr/bin/env python
import time
last = time.time()
while True:
    time.sleep(1)
    print time.time() - last
    last = time.time()

Quando altero a hora pela primeira vez, noto algo como:

1.00194311142
8.29711604118
1.0010509491

Então, quando eu inicio o NTPd, vejo algo como:

1.00194311142
-8.117301941
1.0010509491

Existe alguma maneira de forçar o ntpd a fazer os ajustes em etapas menores?

    

Answer 1

Passar ntpd -x ao iniciar o daemon manterá as alterações muito pequenas: não haverá nenhum passo no relógio. É claro que configurar o giro significa apenas que pode demorar um pouco para corrigir lacunas maiores se você começar com o relógio muito longe do horário correto. Citando alguns parágrafos na página man

Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large. The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence.

Desde que você ajustou seu relógio em 10 segundos, você definitivamente excedeu o domínio do que o NTP estava esperando ver, portanto, o avanço.

As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used.

The issues should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.

Executando ntpdate antes de iniciar os serviços principais e, em seguida, executando ntpd -x depois disso, pode ser uma boa solução combinada para garantir que as etapas principais aconteçam antes que o timekeeping sem etapas seja necessário.

    

Answer 2

Se isso é para o código que você quer escrever, esta pode ser a resposta que você está procurando: link