Dotaz: LeapSecond a NTP server

[leapsecond]

Zdravim, existuje metoda ktora by vedela vyriesit leapsecond na strane servera? Na strane klienta viem o moznosti spustenia ntpd s parametrom -x.

Odpovědi

[Lol Phirae]

http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14.

[miros]

chrony od verze 2.0 umí udělat leap smear na serveru. Zapíná se to pomocí voleb smoothtime a leapsecmode.

http://chrony.tuxfamily.org/manual.html#leapsecmode-directive

[Filip Jirsák]

Co si představujete pod "vyriesit leapsecond na strane servera"? Že NTP server bude správně posílat leap second flag?

[leapsecond]

Mam tu zopar uzatvorenych zariadeni, ktore nie su aktualizovane a viem, ze opat spadnu. Chcel som postavit zvlast NTP server, ktory by na nich posielal postupne updaty s mensimi rozdielami, kedze na strane klienta to nemam ako ovplyvnit.

[Lol Phirae]

V tom případě určitě nechceš neopatchovaný ntpd. Event. minimálně jeden den předem NTP prostě vypni.

[leapsecond]

A potom? :)

[Lol Phirae]

No potom ho zas zapni a čas se normálně postupně srovná, stejně jako to dělá ten leap smear.

[dustin]

Zajímavé řešení. To tedy bude stačit pro přeskočení té leap sekundy? NTP máme aktuální v debian 7, bere debianovské ntp servery. Díky moc.

[Lol Phirae]

To tedy bude stačit pro přeskočení té leap sekundy?

Nevím, jestli přeskočení je ten správný termín, ale jinak ano. Pokud se o té sekundě neopatchované zabugované jádro nedozví, tak problém nenastane.

[Lol Phirae]

Jinak docela slušnou dokumentaci k tomu má RH:

Resolve Leap Second Issues in Red Hat Enterprise Linux

How to clear the Leap Second Insertion flag after it has been received?

[dustin]

Díky

[miros]

Ono taky záleží jaké jsou požadavky na přesnost těch hodin. Jestli nevadí, že se čas rozjede zatím co bude ntpd vypnutý, tak potom není problém. Když je ale potřeba po celou dobu držet hodiny na více systémech blízko sobě, tak se hodí udělat ten leap smear na serveru.

[Jendа]

Pokud je to uzavřený ekosystém, zvážil bych přechod na časový standard, kde podobné hovadiny nejsou. Například right/*, TAI nebo gpstime. (proč sakra right/* není jedno z toho)

[miros]

Jestli jsou s tím ty programy schopny pracovat, tak klidně. Obecně to takhle moc provozovat ale nejde, protože programy často počítají s tím, že máme standardní Unixový čas, kde každý den má 86400 sekund.

[trubicoid]

> (proč sakra right/* není jedno z toho)

nejak nechapu :\

sam jsem si svoje stroje predelal na right/* prijde mi to spravny uz podle nazvu :)

[Jendа]

nejak nechapu :\

Jako že máme TAI a GPS Time (TAI - 19 sekund). A unixový right time je TAI-10. Takže máme tři trošičku posunuté standardy.

Ale teď jsem si přečetl že right time byl dřív než GPS time (protože right time je odvozený od unixové epochy (1970) a GPS je z roku 1980).

[Filip Jirsák]

A s každou novou přestupnou sekundou je příležitost k vytvoření nového "správného" času. Ale mám pocit, že období mezi 30. 6. 2012 a 30. 6. 2015 nikdo k zakotvení "správného" času nevyužil, to je trestuhodná nedbalost.

Ale teď jsem si přečetl že right time byl dřív než GPS time (protože right time je odvozený od unixové epochy (1970) a GPS je z roku 1980).

To přece neznamená, že right/* vzniklo v roce 1970, ale že vzniklo po roce 1970 (pokud byli autoři příčetní - určit počátek epochy do budoucnosti snad ještě nikoho nenapadlo).

[Josef Kufner]

A přitom dát začátek epochy do budoucnosti by umožnilo využít i zápornou část signed integeru.

[Jendа]

Zase by to neumožnilo vyjádřit třeba datum narození. A nebo prostě použiješ datový typ s větším rozsahem…

[Jendа]

(btw. v systému s přestupnými sekundami prostě _nemůžeš_ určit začátek epochy víc než půl roku do budoucnosti, pokud tedy nechceš, aby ti již udělené timestampy plavaly :)

[Filip Jirsák]

Stejně budou plavat časy v budoucnosti uložené dříve. Pokud jsem si loni naplánoval do kalendáře nějakou schůzku na letošní prázdniny a kalendář čas ukládá jako „počet sekund od“, přijdu na tu schůzku o sekundu dříve

[Petr Šobáň]

Lepší jak přijít o sekundu později )

[Jendа]

A s každou novou přestupnou sekundou je příležitost k vytvoření nového "správného" času.

Nejen. Taky můžu vytvořit nový správný čas okamžikem odeslání tohoto komentáře. A sekundu si definovat jako dobu 9192631771 period toho záření z césia.

To přece neznamená, že right/* vzniklo v roce 1970, ale že vzniklo po roce 1970

Nechtělo se mi to opisovat. A ano, je to pravděpodobné.

[Lol Phirae]

Nevím, jestli to bude dobrý nápad.

The files in /usr/share/zoneinfo/right contain local time information corrected for all leap seconds that have occurred since the beginning of the Epoch on 1970-01-01 00:00:00 UTC. The other time zone files in /usr/share/zoneinfo do not have leap second corrections added. ... Any application that expects the time to be in UTC will have issues if a right/* timezone is used.