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í
×

dnes 05:55 | Zajímavý projekt

Dle příspěvku na blogu zaměstnanců CZ.NIC byl spuštěn ostrý provoz služby Honeypot as a Service (HaaS). Zapojit se může kdokoli. Stačí se zaregistrovat a nainstalovat HaaS proxy, která začne příchozí komunikaci z portu 22 (běžně používaného pro SSH) přeposílat na server HaaS, kde honeypot Cowrie (GitHub) simuluje zařízení a zaznamenává provedené příkazy. Získat lze tak zajímavé informace o provedených útocích. K dispozici jsou globální statistiky.

Ladislav Hagara | Komentářů: 0
dnes 04:44 | Komunita

Před týdnem společnost Feral Interactive zabývající se vydáváním počítačových her pro operační systémy macOS a Linux oznámila, že pro macOS a Linux vydají hru Rise of the Tomb Raider. Včera společnost oznámila (YouTube), že pro macOS a Linux vydají také hru Total War Saga: Thrones of Britannia. Verze pro Windows by měla vyjít 19. dubna. Verze pro macOS a Linux krátce na to.

Ladislav Hagara | Komentářů: 0
včera 21:33 | Nová verze

Byla vydána nová major verze 7.10 svobodného systému pro řízení vztahů se zákazníky (CRM) s názvem SuiteCRM (Wikipedie). Jedná se o fork systému SugarCRM (Wikipedie). Zdrojové kódy SuiteCRM jsou k dispozici na GitHubu pod licencí AGPL.

Ladislav Hagara | Komentářů: 0
včera 16:44 | Nová verze

Byla vydána nová verze 0.30 display serveru Mir (Wikipedie) a nová verze 2.31 nástrojů snapd pro práci s balíčky ve formátu snap (Wikipedie). Z novinek Miru vývojáři zdůrazňují vylepšenou podporu Waylandu nebo možnost sestavení a spouštění Miru ve Fedoře. Nová verze snapd umí Mir spouštět jako snap.

Ladislav Hagara | Komentářů: 0
včera 14:00 | Komunita

Na Indiegogo běží kampaň na podporu Sway Hackathonu, tj. pracovního setkání klíčových vývojářů s i3 kompatibilního dlaždicového (tiling) správce oken pro Wayland Sway. Cílová částka 1 500 dolarů byla vybrána již za 9 hodin. Nový cíl 2 000 dolarů byl dosažen záhy. Vývojáři přemýšlejí nad dalšími cíli.

Ladislav Hagara | Komentářů: 1
včera 11:11 | Nasazení Linuxu

Před dvěma týdny se skupina fail0verflow (Blog, Twitter, GitHub) pochlubila, že se jim podařilo dostat Linux na herní konzoli Nintendo Switch. O víkendu bylo Twitteru zveřejněno další video. Povedlo se jim na Nintendo Switch rozchodit KDE Plasmu [reddit].

Ladislav Hagara | Komentářů: 3
včera 05:55 | Komunita

Byla vydána vývojová verze 3.2 softwaru Wine (Wikipedie), tj. softwaru, který vytváří aplikační rozhraní umožňující chod aplikací pro Microsoft Windows také pod GNU/Linuxem. Z novinek lze zdůraznit například podporu HID gamepadů. Aktuální stabilní verze Wine je 3.0, viz verzování. Nejistá je budoucnost testovací větve Wine Staging s řadou experimentálních vlastností. Současní vývojáři na ni již nemají čas. Alexandre Julliard, vedoucí projektu Wine, otevřel v diskusním listu wine-devel diskusi o její budoucnosti.

Ladislav Hagara | Komentářů: 2
18.2. 16:55 | Komunita

Do 22. března se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 14. května do 14. srpna 2018, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 49
17.2. 15:44 | Komunita

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice dnes slaví 6 let od svého oficiálního vzniku. Nadace byla představena 28. září 2010. Formálně ale byla založena až 17. února 2012. Poslední lednový den byl vydán LibreOffice 6.0. Dle zveřejněných statistik byl za dva týdny stažen již cca milionkrát.

Ladislav Hagara | Komentářů: 1
17.2. 04:44 | Bezpečnostní upozornění

CSIRT.CZ upozorňuje, že byla vydána nová verze 1.2.3 svobodného routovacího démona Quagga (Wikipedie) přinášející několik bezpečnostních záplat. Při nejhorší variantě může dojít až k ovládnutí běžícího procesu, mezi dalšími možnostmi je únik informací z běžícího procesu nebo odepření služby DoS. Konkrétní zranitelnosti mají následující ID CVE-2018-5378, CVE-2018-5379, CVE-2018-5380 a CVE-2018-5381.

Ladislav Hagara | Komentářů: 0
Který webový vyhledávač používáte nejčastěji?
 (2%)
 (28%)
 (62%)
 (2%)
 (3%)
 (1%)
 (1%)
 (1%)
Celkem 379 hlasů
 Komentářů: 34, poslední 14.2. 18:44
    Rozcestník

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

    27.9.2017 21:20 | Přečteno: 2917× | Linuxové drobty | Výběrový blog | poslední úprava: 24.10.2017 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.2017 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.
    KERNEL ULTRAS video channel >>>
    Marián Kyral avatar 29.9.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 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.2017 19:13 Vantomas | skóre: 26 | 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.2017 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.