abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 12:00 | Nová verze

Po cca 3 týdnech od vydání Linux Mintu 18.3 s kódovým jménem Sylvia a prostředími MATE a Cinnamon byla oznámena také vydání s prostředími KDE a Xfce. Podrobnosti v poznámkách k vydání (KDE, Xfce) a v přehledech novinek s náhledy (KDE, Xfce). Linux Mint 18.3 je podporován do roku 2021.

Ladislav Hagara | Komentářů: 6
15.12. 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 46
15.12. 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
15.12. 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 8
15.12. 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
14.12. 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 10
14.12. 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
14.12. 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
14.12. 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
14.12. 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (0%)
 (1%)
 (1%)
 (76%)
 (14%)
Celkem 1003 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Pár poznámek k řízení času přes NTP

    27.9. 21:20 | Přečteno: 2813× | Linuxové drobty | Výběrový blog | poslední úprava: 24.10. 00:17

    Nějakou dobu jsem se věnoval naladění ntp na co nejpřesnější doregulaci času. A někdy to tedy moc nejde. Takže bych si sem zanesl pár poznámek. A možná budou i někomu k užitku.

     

    NTP protokol je jeden z nejstarších protokolů na internetu. Funkční je od roku 1985 a ne některých postupech je to znát. Funguje tak, že system pošle UDP paket na synchronizační server, dostane odpověď, kde je napsán čas příjmu výzvy a čas odeslání odpovědi z toho serveru, má zaznamenaný čas vyslání a čas příjmu a z těchto časů spočte jednak zpoždění signálu a jednak svůj posun času.

     

    Tohle provádí na několik nastavených serverů. Z nich pomocí "intersection algorithm" volí ty, které jsou mimo přesný čas a s ostatními pracuje. Zatím algoritmus dobrý.

     

    Ted pár negativních postřehů. Algoritmus finálně vždy zvolí server, ke kterému se blíží (sys_peer). Pokud v nějaké situaci je několik kandidátních serverů a časově od sebe poněkud vzdálených, třeba díky zatížení linky, tak ntp může přepínat mezi servery a čas plave. Není zde žádný algoritmus, kdy klient by se blížil k nejakému váženému průměru času serverů, které byly kvalifikovány jako s OK časem.

     

    Vztah k jednomu serveru: Klient posílá měřící pakety za interval, který považuje na základě vyhodnoceného posunu času za optimální, což je nejdříve 64 vteřin, později se interval prodlužuje až na 1024 vteřin a tam zůstane pokud není nějaká katastrofa. Z každého měření si zaznamenává zpoždění k serveru a vypočítaný offset. Pamatuje si posledních 8 měření a opět (podobně jako v případě serveru) se váže k jedinému z nich a od něj odvozuje posun častu vůči serveru. Preferuje samozřejmě měření, které má menší delay a je novější. A když je nejnovější s větším delay tak samozřejmě záleží o jak moc větší delat. Nicméně to co mne nedávno překvapilo na lokální siti, bylo jak algoritmus nebere v potaz offset. Ze stavu plně časově synchronizovaných strojů se mi při přenosu cca 100G rsyncem po lokální síti rozhodily stroje asi o 20ms. NTP mezitím začal pracovat na synchronizaci. To co bylo ale zajímavé, že v několika případech volil jako hlavní měřící paket ten, co tomu neodpovídal. Na vnitřní sítí mám delay mezi systémy pod 1ms konkrétně první starší měření 0.28 a novější 0.41ms přičemž u prvního měření bylo offset 24,49 a u druhého (pozdějšího) 16,6 (už doladění času probíhalo), přesto perzistentně klient trval na tom, že rozdíl času k tomuto serveru je podle toho prvního (rychlejšího ale s větším offsetem) měření do té doby než proběhlo ještě následující měření. Přičemž je zřejmé, že s jakýmkoliv delay pod 1ms to druhé pozdější měření je přesnější.

     

    Tolik jen pár pozorování. Určitě s NTP nebudu nic dělat, ale když by vám trochu čas plaval, tak to může být i tímto.

    Ještě přidám pár grafů:

    Situace je taková. Domácí server je i zálohovací server a jednou za 2 dny prochází připojené notebooky a desktopy a provádí úplné a inkrementální zálohy podle zadanách časů. To co probíhalo a je zachyceno na grafech byla.

    1. malá inkrementální záloha jednoho notebooku 19:00 - 19:20
    2. úplná záloha druhého notebooku 20:05-22:20 a navazující inkrementální zálohy desktopu a serveru do 22:48
    3. inkrementální záloha posledního notebooku 23:00 - 23:15.

    Zátěž které měl server je následující.

    Průtok dat disky

    Průtok diskem

    IOPS

    iops

    Zatížení disků

    zatizeni

     

    Zatížení je primárně na zařízení backuppc, což je RAID 10 nad disky a,c,,d,e.

     

    Toto zatížení se projeví jako load:

    interupty

    a v zatížení paměti

    pamet

    díky této zátěži se začnou i posouvat presnosti hodin procesoru systému. Celkový obrázek je:

    Jak máme porozumět tomu kmitání ofsetu nahoru a dolů.

    Přesnější pohled na odchylku dává:

    Tedy v 19:00 hodiny začaly odjíždět do 19:20 a pak se srovnávaly do 20:00. ve 20:00 začaly odjíždět znovu až do 21:00 kde se začaly rovnat, přibližně od 21:40 do 22:40 se držely jakž takž a pak ujely do záporné odchylky s maximem 23:30. Současně pokud se podíváme na chybu, tedy hodnotu kolik si ntpd myslí, že jsou správné hodiny daleko.

    je vidět jak chyba stoupá od 19:00 do maxima v 21:30 a pak s prestávkami padá. v nezatíženém systému je odhadovaná chyba hluboce pod milisekundu.

    Jak si tohle vysvětlovat? Každé hodiny jsou špatné a ntpd je kompenzuje. Standardně na mém nezatíženém systému je to kolem 20 ppm. Při zatíženém systému (mém systému) se hodiny zpomalí a ntpd to musí vykompenzovat. Kompenzuje to upravami jaderného parametru ppm, tedy kolik jednotek za milion tiků musí přidat nebo ubrat. viz následující graf.

    A teď trochu vysvětlování a souvislostí. První záloha trochu pohnula časem ale nic moc. chyba vybehla a ntpd na to zareagoval mírnou vlnkou ppm v čase cca 19:30 která dokázala odchylku trochu stáhnout i když chyba se zatím moc nesnížila. Velká zátěž pohnula s hodinami více a ntpd reagoval celkem pomalu. až v 21 začal masívně navyšovat ppm, aby chybu stáhnul. Nicméně, jak vidět se mu to podařilo brzy cca 21:30 už byly hodiny celkem přesné  Hodnota ppm 24 a něco se asi dá chápat jako správná kompenzace pro můj zatížený systém, nicméně zátěž skončí v 22:40 s malou ještě zátěží po 23. A vysoká hodnota ppm zůstává a hodiny zbytečně zrychlí, odchylka letí do záporna (čas serveru proti kterému se synchronizujeme je pomalejší) a ntpd trvá až do 0:30 než výrazně ppm vrátí nebo přesněji až do 6 a něco než najde znovu správnou hodnotu ppm pro nezatížený systém. což je důvod kmitání odchylky kolem přesného času. Jen poznámka - zajímavost - nesouvisející s časem. když jedou mi ty zálohy, tak rapidně se změní práce s inody.

           

    Hodnocení: 100 %

            špatnédobré        

    Obrázky

    Pár poznámek k řízení času přes NTP, obrázek 1 Pár poznámek k řízení času přes NTP, obrázek 2 Pár poznámek k řízení času přes NTP, obrázek 3 Pár poznámek k řízení času přes NTP, obrázek 4 Pár poznámek k řízení času přes NTP, obrázek 5 Pár poznámek k řízení času přes NTP, obrázek 6 Pár poznámek k řízení času přes NTP, obrázek 7 Pár poznámek k řízení času přes NTP, obrázek 8 Pár poznámek k řízení času přes NTP, obrázek 9 Pár poznámek k řízení času přes NTP, obrázek 10 Pár poznámek k řízení času přes NTP, obrázek 11

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    Bedňa avatar 29.9. 00:00 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Nikdy som neskúmal ako to funguje, proste to funguje, ale som rád, že teraz viem už ako.

    Dík.
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    Marián Kyral avatar 29.9. 08:17 Marián Kyral | skóre: 29 | blog: Sem_Tam | Frýdek-Místek
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Normálně bych to přešel, ale těch chyb je nějak moc ;-)
    …oédeslání…
    …nění…
    …měžení…
    …perzisteně…
    …že z jakýmkoliv delay…
    Jinak já jsem rád, že ntp alespoň nějak funguje. Bohužel v některých případech ani ntp nepomůže. Třeba když zapnu počítač po delší době a mezitím došlo k posunu času na letní/zimní. Ntp v tomto případě nezafunguje - že prý to je moc velký posun - a musím to řešit ručně. Je to sice jen dvakrát ročně, ale uvítal bych, pokud bych ani tohle řešit nemusel.
    29.9. 08:32 little-drunk-jesus | skóre: 13
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Nestacilo by do ntp systemd service pridat do ExecStartPre= jednorazovou synchronizaci pomoci ntpdate? Takze by se ti cas syncnul skokove pred tim, nez by ntp demon nabehl?
    29.9. 10:18 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Za starých dobrých (pre-systemd) časů bývalo zvykem, že to v init scriptech pro xntpd bylo.
    29.9. 10:17 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Máte nějaký důvod, proč nemít v hardwarových hodinách čas v UTC?
    Marián Kyral avatar 30.9. 18:50 Marián Kyral | skóre: 29 | blog: Sem_Tam | Frýdek-Místek
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Abych pravdu řekl, vůbec netuším, jak tam ten čas mám uložený. Je to ještě nějaký AMD Athlon. A nejsem si jist, jestli aktuální MB ještě zažil dual boot s windows XP. Musím zkontrolovat.
    Dalibor Smolík avatar 25.10. 09:36 Dalibor Smolík | skóre: 54 | blog: Postrehy_ze_zivota | 50°5'31.93"N,14°19'35.51"E
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Mrknout se do BIOSu?
    Rozdíly v řeči a ve zvyklostech neznamenají vůbec nic, budeme-li mít stejné cíle a otevřená srdce.
    1.10. 11:44 MP
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    systemd-timedated to umi. Ale na druhou stranu, neni tak "jemny" jako klasicke ntp, na desktop ok, ale nasazeni na serveru je otazkou.
    4.10. 14:02 lertimir | skóre: 61 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Diky za poznámky, někdy to nevidím. K synchronizaci dvě poznámky. Jednak všechny systémy důsledně jedu v UTC a lokální hodiny jsou součástí lokálního nastavení. A za druhé buď periodicky a nebo při vypínání systému provádím hwclock -systohc, které zapíše systémový čas do hw hodin a pak při dalším startu to není nijak moc daleko.
    29.9. 16:48 Pavel Píša | skóre: 12
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP

    V mnoha současných distribucích je jako základ pro NTP použitá varianta daemona chrony. Ten používá následující konfigurační soubor /etc/chrony/chrony.conf. V něm je možné povolit, že je na začátku přípustné provést korekci mimo běžné limity.

    makestep 1 -1
    

    První hodnota říká, při jak velkém rozdílu již nedojíždět k správnému času plynule, u nás, jakmile je rozdíl větší než 1 sekunda. Druhý parametr pak omezuje do kolika výměn po startu je ještě přechod na srovnání času skokem přípustný. U studentských stanic v lokální síti to moc neřešíme a záporná hodnota (-1) pak specifikuje, že kdykoliv dojde k velkému odstupu od serveru, tak se natvrdo stanice sesynchronizují. Pro server nebo prostředí s certifikáty a bezpečností to asi není ideální, ale i když bootujeme naše prostředí v laboratořích, kde jiné katedry používají Windows, tak je od problémů s časem pokoj.

    Volby rtconutc a rtcsync máme zakomentované, aby nebyly při nutnosti soužití s jinými systémy potíže a GNU/Linux pak na stanicích RTC ignoruje.

    Více ke zkušenostem může říct správce naší infrastruktury - Aleš Kapica.

    29.9. 19:16 miros
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Není zde žádný algoritmus, kdy klient by se blížil k nejakému váženému průměru času serverů, které byly kvalifikovány jako s OK časem.
    Takový algoritmus v ntpd je, dokonce je i ve specifikaci NTP jako "combining algorithm". Offsety serverů, které ve výpisu ntpq -pn mají značku + jsou zkombinovány s tím co má *. Jako váha se bere "root distance".
    4.10. 13:46 lertimir | skóre: 61 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Ano je. Ale v RFC 1305 je psáno:
    Appendix F describes an optional algorithm to improve accuracy by combining the time offsets of a number of clocks.
    Takže díky "optional" netuším, jak to je u konkrétních daemonů. U standardního ntpd jsem nenašel žádnou volbu, kterou bych tento volitelný algoritmus zapnul nebo vypnul. A osobní pocit z pozorování chování hodin bylo: "Přibližuji se k sys-peer serveru (s hvězdičkou v ntpq -p)." Ne že se přibližuje k nějakému váženému průměru.
    5.10. 21:36 miros
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    RFC 1305 je už hodně staré a bylo nahrazeno RFC 5905. ntpd je referenční implementace, podle které se ty RFC psaly, takže obsahuje všechny popsané algoritmy.

    Minimální a maximální počet zkombinovaných serverů se dá nastavit přes tos minclock a tos maxclock.

    Když si vypíšete asociace přes ntpq -c as a pak proměnné všech serverů přes ntpq -c 'rv $ID', jakou root dispersion a delay má ten server s hvězdičkou oproti těm s pluskem? Možná je mnohem blíž a tak má jeho offset mnohem větší váhu.
    21.10. 22:40 lertimir | skóre: 61 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    doplnil jsem pár grafů.
    24.10. 01:05 Y.
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    Zvazili jste možnost, že hodiny jsou stále stejné přesné, ale mění se přesnost měření, např, pakety dorazí do ntp o něco později, či ntp z nějakého důvodu není vzbuzeno čas, atp? Něco v tomto směru se mi zda na ně RT kernelu pravdepodnejsi než že se začnou rozjíždět hodiny.
    24.10. 07:57 lertimir | skóre: 61 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    V prvním grafu o čase (pátý graf od konce) je zelená křivka "delay", zachycující zpoždění paketů mezi mým serverem a časovým serverem. Ta křivka se celou dobu nemění (Server je na gigabitu a i silný přenos s notebooku linku nenaplní). Skutečně se hodiny rozjíždějí. Stejnou zkušenost mám i z před více let, kdy na virtuálním serveru byla občas spouštěna zátěž kdy 8 jader jelo cca 2 hodiny na plnž výkon (load asi 8-14) a čas vždy o milisekundy ulítl než ho server dokompenzoval právě pomocí jaderného parametru.
    24.10. 19:13 Vantomas | skóre: 25 | Praha
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    V čem vadí, že se rozjede čas o pár jednotek nanejvýš desítky milisekund?
    24.10. 23:40 lertimir | skóre: 61 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
    To asi jak kdy. Já nikde neříkám, jestli to vadí nebo ne. Jen popisuji chování NTP hodin. Některé aplikace na rozcházení času mohou být citlivé (např. NFS), ale milisekundy vadit nebudou a v běžném použití to kritické není. Na druhou stranu pokud by někdo vytvářel přesné hodiny pro organizaci a chtěl od nich vyšší přesnost, je lepší když je rozjede na dedikovném HW (což může být klidně osamocené RPi jedoucí jen hodiny) a ne na systému jehož zatížení se mění. A pokud by potřeboval vyšší přesnost (třeba pro industriální systémy) je tu ještě PTP (a pak jsou také projekty jako White Rabbit)

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.