NTP sync in stappen

[ZodiacQ]

Hoi,

Ik was benieuwd of het mogelijk was om ntpd zo te configureren, dat hij bij een afwijking in stappen synchroniseert.

Bvb. 1 seconde verschil, wordt in stappen van 100ms terug gesynct.

Reden: Bij de introductie van een schrikkel-seconde kan de klok plotselings 1 seconde afwijken (+ of -). Default wordt met ntpd deze afwijking in 1 keer tenietgedaan. Online zijn er niet veel aanwijzingen te vinden over eventuele opties voor ntp.conf.

Ik zie wel informatie ivm slew vs steps, maar nergens geen syntax om eventuele andere waarden op te geven.

Tnx.

[ Voor 12% gewijzigd door ZodiacQ op 01-09-2011 14:10 ]

[Kees]

Ik vraag mij af waarom je dit zou willen? Ga je dan ook bijvoorbeeld de zomer/wintertijd in stappen aanpassen?

[Mijzelf]

Kees schreef op donderdag 01 september 2011 @ 15:52:
Ga je dan ook bijvoorbeeld de zomer/wintertijd in stappen aanpassen?

NTP synct op UTC, en heeft dus niets te maken met zomer/wintertijd.

[Verwijderd]

nee maar bij de winter/zomer tijd verandert de tijd in 1x met 1 uur. dat gebeurt ook niet in stappen van 100ms

waarom de schrikkelseconde wel? als de appartuur niet kapot gaat bij de wintertijd waarom wel bij een schrikkelseconde?

[Verwijderd]

Sommige software vindt het niet leuk als de tijd ineens enorm achteruit loopt, zelfs al gaat het om secondenwerk. Denk bijvoorbeeld aan MTA of MDA software.

Edit: als je ntpd draait als daemon dan zal deze altijd heel subtiel de klok bijgewerkt houden. Hij rekent de clock drift voor je uit zodat hij die kan compenseren. Easy!

[ Voor 36% gewijzigd door Verwijderd op 01-09-2011 16:52 ]

[remco_k]

Verwijderd schreef op donderdag 01 september 2011 @ 16:18:
nee maar bij de winter/zomer tijd verandert de tijd in 1x met 1 uur. dat gebeurt ook niet in stappen van 100ms

Op UTC nivo gebeurd er zelfs helemaal niets mee, en heeft derhalve dan ook niets te maken met timesync.
Zomer/wintertijd is een lokale tijdelijke offset die wordt toegepast, buiten de sync om. UTC tijd blijft gelijk.

waarom de schrikkelseconde wel? als de appartuur niet kapot gaat bij de wintertijd waarom wel bij een schrikkelseconde?

Omdat de schrikkelseconde op UTC nivo wordt toegepast en geen lokale (tijdelijke) offset is.
De meeste software die iets met tijd doet, doet dat intern dan ook op UTC nivo waardoor je geen last hebt van tijdelijke zomer/winter offsets.

[ Voor 9% gewijzigd door remco_k op 01-09-2011 17:11 ]

[Mijzelf]

Uit de man page van ntpd:

-x
Normally, the time is slewed if the offset is less than the step
threshold, which is 128 ms by default, and stepped if above the
threshold. This option sets the threshold to 600 s, which is
well within the accuracy window to set the clock manually.
Note: Since the slew rate of typical Unix kernels is limited to
0.5 ms/s, each second of adjustment requires an amortization
interval of 2000 s. Thus, an adjustment as much as 600 s will
take almost 14 days to complete. This option can be used with
the -g and -q options. Note: The kernel time discipline is dis-
abled with this option.

Volgens mij staat hier dat tijdverschillen kleiner dan 128 ms worden weggewerkt met 0.5 msec/sec. Maar je kunt die grens vergroten tot 600s, waar die schrikkelseconde ruim inpast.

[ZodiacQ]

Mijzelf schreef op donderdag 01 september 2011 @ 17:22:
Uit de man page van ntpd:

[...]

Volgens mij staat hier dat tijdverschillen kleiner dan 128 ms worden weggewerkt met 0.5 msec/sec. Maar je kunt die grens vergroten tot 600s, waar die schrikkelseconde ruim inpast.

Yup, had ik ook gelezen. Dus ik kan er vanuit gaan dat dit niet in ntp.conf aan te passen is, maar dat ik het init.d script moet aanpassen.

Tnx.

[army]

Waarom zou je het aanpassen? Dit punt staat netjes beschreven in oa de NTP-FAQ:

5.3.4. What happens during a Leap Second?

The theory of leap seconds in explained in Q: 2.4.. In reality there are two cases to consider:

If the operating system implements the kernel discipline described in Section 5.2, ntpd will announce insertion and deletion of leap seconds to the kernel. The kernel will handle the leap seconds without further action necessary.

If the operating system does not implement the kernel discipline, the clock will show an error of one second relative to NTP's time immediate after the leap second. The situation will be handled just like an unexpected change of time: The operating system will continue with the wrong time for some time, but eventually ntpd will step the time. Effectively this will cause the correction for leap seconds to be applied too late.

Zolang de afwijking tussen NTP en je systeemklok niet meer is dan 1000 seconden is er niets om je zorgen om te maken. Het kan alleen wel even duren.

[army]

Verwijderd schreef op donderdag 01 september 2011 @ 16:50:
Sommige software vindt het niet leuk als de tijd ineens enorm achteruit loopt, zelfs al gaat het om secondenwerk. Denk bijvoorbeeld aan MTA of MDA software.

Edit: als je ntpd draait als daemon dan zal deze altijd heel subtiel de klok bijgewerkt houden. Hij rekent de clock drift voor je uit zodat hij die kan compenseren. Easy!

Als software hier van onderuit gaat, want wordt het tijd voor een bugreport met een verwijzing naar hoe BIND dit bijvoorbeeld oplost door met delta's te rekenen. Dus ja het is mogelijk, maar de programmeur moet even aan de slag.