<div dir="ltr"><div dir="ltr"><div>Ano, ma to zmysel.</div><div><br></div><div>Premyslate v obmedzeni 2 zariadeni - "server", ktory poskytuje "nieco podobne casu", neznamej prenosti, neznameho povodu, a klient, ktory ma "nieco ako priblizny cas" <br></div><div>s neznamym komunikacnym oneskorenim a bez sance si overit serioznost dat od servera.  V niektorych pripadoch to staci, ale vseobecne sa to povedat neda.<br></div><div></div><div>NTP bolo navrhnute na komplexnejsie a presnejsie pouzitia s dynamicky premenlivymi podmienkami na trase prenosu v roznych sposoboch zavislosti hierarchycky vertikalnych aj horizontalnych.<br></div><div>To, ze to nedava zmysel Vam, na tom nic nemeni.<br></div></div><div><br></div><div>"Nezmyselny cas" je v niektorych pouzitiach napr. o 1ms inde ako presny cas.</div><div>Udrzanie infrastruktury na rovnakom case napr. v pripade vypadku synchronizanie na presnejsi casovy normal je niekedy klucove <br></div><div>Napr. clusterware rebootne nod clustra (a tym ho aj vyhadzuje z clustra), ak sa objavi nod clustra, ktory ma iny cas o nejaku hodnotu, ktoru cluster uz neakceptuje.</div><div><br></div><div>Ak si zariadenia predstavite ako ovecky, tak je vyhodnejsie, aby ovecky zostali "v kosiari" a "cely kosiar s lokalnym honelnikom" sa posuval pomaly na nespravne miesto <br></div><div>( lokalny SW NTP odchadza sa od presneho casu po vypadku casoveho normalu, alebo komunikacie s nim )</div><div>Po obnoveni casoveho normalu sa "cely kosiar" dotiahne na spravne miesto - (baca da pokyny honelnikom a ti dozenu ovecky kam treba)<br></div><div>Ak by napr NTP server neposkytoval sluzby, tak sa "ovecky" rozlezu kazda inam a po obnove by sa nemuseli vratit ( vzdialia sa dalej, ako je moznost opatovnej synchronizacie )</div><div>So vsetkymi dosledkami.<br></div><div><br></div><div>Tieto casti su riesenim chyboveho stavu, ked vypadne komponent, alebo vypadne komunikacia, nie ako primarne riesenie. <br></div><div>( napriklad centrala s 2-mi datovymi centrami, 2 casovymi normalmi, vsetko redundantne ... a desiatky, alebo stovky pobociek a na kazdej pobocke desiatky, stovky, mozno aj tisicky zariadeni)</div><div>Je vyhodnejsie, ak na kazdej pobocke je lokalny SW NTP a v pripade vypadku konektivity na centralu lokalne vsetko funguje dalej, cas sa postupne stava menej presnym, ale cela pobocka je synchronizovana a napr, aj lokalne DB funguju dalej.</div><div>Po obnove konektivity sa lokalny SW NTP postupne dotiahne na spravny cas, s nim aj vsetky zariadenia na pobocke a DB sa nareplikuju na centralu. <br></div><div><br></div><div>Ak to otocime z casu na informacie vseobecne - Vam dava zmysel, ak niekto na internet (web, media, maily, ... cokolvek ) dava informacie, ktore nie su spravne, nie su pravdive, a ich zdrojom je "ja si myslim" ?</div><div>Ak tie informacie su uvedene s priznakom " ja si myslim ", tak prijimatel im priradi nejaku mieru doverihodnosti.</div><div><br></div><div>Ak by to fungovalo podla vasho navrhu, citujem:</div><div>------<br></div><div> " Poskytovat službu, vracející vědomě vadná data (i když s nějakým příznakem), je tedy podle mě opravdu špatné."</div><div>------</div><div></div><div><br></div><div>Ak informacia nie je 100% pravda, tak informaciu neposuniem dalej, nezverejnim, (...NTP server neposkytne sluzbu, neodpovie... ) ... Kolko prispevkov by ubudlo napr. aj v tejto konferencii ?</div><div></div><div><br></div><div></div><div></div><div>Dodo<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">ne 24. 7. 2022 o 13:54 Petr Labaj <<a href="mailto:labaj@volny.cz">labaj@volny.cz</a>> napísal(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Promiňte, ale to, co jste napsal - opravdu Vám to dává smysl?<br>
<br>
Pokud mám infrastrukturu, kde potřebuju jednotný čas, tak se podle toho <br>
zařídím.<br>
NTP server může běžet kde na čem, tak ho nemusím provozovat zrovna na <br>
switchi,<br>
který asi nemá ani RTC pro udržení času při výpadku napájení. Soudím <br>
podle toho,<br>
že zřejmě vrací nesmyslný čas - použil jsem to jako příklad, proč tam <br>
původnímu<br>
tazateli skočí nějaký nesmyslný čas.<br>
<br>
Poskytovat službu, vracející vědomě vadná data (i když s nějakým <br>
příznakem), je<br>
tedy podle mě opravdu špatné. Nemám přesný čas, tak nemám služby poskytovat.<br>
Čemu pomůže, že služba běží, ale dává nevalidní informace? Čemu konkrétně<br>
v tom Vašem případě, kdy potřebujete rovnaký čas? To jako že by se všichni<br>
synchronizovali na ten vadný čas? A jak to zařídit, když klient o to <br>
požádá jindy?<br>
<br>
Předpokládám, že třeba u databazového serveru byste taky nechtěl, aby <br>
když nemá<br>
zdroj platných dat, tak vrátil nějaká fake-data (byť s příznakem). Nebo <br>
mailový<br>
server pří nedostupnosti dat vracel třeba staré maily, WWW server nějaké <br>
neplatné<br>
(ale zdánlivě správné) stránky atd.<br>
<br>
PL<br>
<br>
********************<br>
<br>
Dne 24.7.2022 v 11:34 Dodo Racek napsal(a):<br>
> Su riesenia, kde nie je nutny absolutne presny cas, ale je nutny <br>
> *rovnaky* cas v celej infrastrukture.<br>
><br>
> Nerobia to len zariadenia cisco, ale routre mnohych inych vyrobcov.<br>
><br>
> Protokol NTP na to pamata, ale je potrebne trochu chapat suvislosti a <br>
> nie iba vybrat 4 Byty z komunikacie.<br>
><br>
> Dodo<br>
><br>
> Dňa ne 24. 7. 2022, 0:43 Petr Labaj <<a href="mailto:labaj@volny.cz" target="_blank">labaj@volny.cz</a>> napísal(a):<br>
><br>
>     Sakryš, to je ale chytrý server, ten Cisco switch.<br>
>     Má blbě čas, ale stejně ho vrátí a jenom nastaví nějaký parametr.<br>
><br>
>     Kdysi jsem musel napsat vlastní časový server (s protokolem rdate).<br>
>     Tak jsem to udělal jednoduše tak, že dokud neměl od nadřízeného<br>
>     serveru<br>
>     přesný čas, tak prostě službu neposkytoval a žádost odmítl.<br>
>     Rozumný klient (toho jsem psal taky) má seznam serverů. Tak když<br>
>     jeden<br>
>     službu neposkytuje, osloví dalšího.<br>
>     Nojo, no. Nejsem tak chytrý jako Cisco.<br>
><br>
>     PL<br>
><br>
>     *********************<br>
><br>
>     Dne 23.7.2022 v 23:20 Dodo Racek napsal(a):<br>
>     > Okrem precitaneho casu z paketu sledujte aj stratum.<br>
>     > Cim nizsie cislo, tym lepsie. (0- atomove hodiny, 1-<br>
>     synchronizovane<br>
>     > voci atomovym hodinam, 2- synchronizovane voci 1, atd...) na<br>
>     internete<br>
>     > bezne server bude mat stratum 2-3.<br>
>     > Server MUSI mat stratum rovnake cislo.<br>
>     > Ak serveru vypadne synchronizacia na presnejsi nadradeny, tak to<br>
>     > "oznami" klientom zmenou hodnoty v stratum. Cisla nad 10 sa<br>
>     pouzivaju<br>
>     > pre nepresny cas (lokalny oscilator bez synchronizacie), takemu<br>
>     casu<br>
>     > sa neveri.<br>
>     ><br>
>     > Ked sa nejedna o utok, ale o to, ze aj nadradeny server stratil<br>
>     presny<br>
>     > cas a oznamuje bludy, tak vam nepomoze ani 1000 nacitani a<br>
>     porovnavani.<br>
>     ><br>
>     > Ak je NTP server napr. cisco switch, alebo router, tak obycajne<br>
>     nema<br>
>     > vlastne HW hodiny. Po zapnuti, alebo reboote oznamuje klientom<br>
>     > nezmyselny cas az do chvile, kym sa nezosynchronizuje s<br>
>     nadradenym ntp<br>
>     > sevrom. To moze trvat aj 15 min. Oznamuje ale definovanym<br>
>     > (nakonfigurovanym) vysokym cislom pre stratum.<br>
>     ><br>
>     > Voci akemu NTP serveru (FQDN,IP) sa zvyknete synchronizovat?<br>
>     ><br>
>     ><br>
>     > Dodo<br>
>     ><br>
>     > Dňa so 23. 7. 2022, 21:28 Petr Zapadlo <<a href="mailto:zapik@email.cz" target="_blank">zapik@email.cz</a>> napísal(a):<br>
>     ><br>
>     >     Zdravím,<br>
>     ><br>
>     >     na většině projektů, kde je  třeba   čas, tak ho<br>
>     synchronizuji z NTP.<br>
>     >     Občas (třeba  jednou za půl roku) se stane, že ESP získá<br>
>     špatný čas.<br>
>     >     Pokusil jsem se to eliminovat  - načítám čas 3x a porovnávám -<br>
>     >     použiji<br>
>     >     dvě hodnoty, které mají minimální rozestup. (pokud se nesejdou,<br>
>     >     tak to<br>
>     >     ignoruji a zkouším znova)<br>
>     ><br>
>     >     Situace se zlepšila, přesto občas k problému dojde. Zdá se, že<br>
>     >     četnost<br>
>     >     nějak závisí i na kvalitě internetové linky.  U mě doma se to<br>
>     >     prakticky<br>
>     >     neděje (Metronet, DSL, modem Terminator) , ale u známé se to<br>
>     děje<br>
>     >     poměrně často (měsíčně) (O2, DSL, modem ZTE), u syna tak<br>
>     jednou za<br>
>     >     půl<br>
>     >     roku (kabelovka Vodafone).<br>
>     ><br>
>     >     Vypadá to, že za nějakých podmínek projde UDP stackem v ESP<br>
>     i paket,<br>
>     >     který není v pořádku - asi má i vadný checksum, ale vzhledem k<br>
>     >     četnosti<br>
>     >     to nejsem schopen nijak ověřit.  Případně projde nesmyslný paket<br>
>     >     (ale to<br>
>     >     by měl eliminovat požadavek na 2 stejné hodnoty).<br>
>     ><br>
>     >     Jak se divám do struktury NTP paketu, tak tam už žádný kontrolní<br>
>     >     mechanizmus není. (dívám se dobře?)<br>
>     ><br>
>     >     Základní kus kodu je vzat z mnohokrát opakovaného příkladu:<br>
>     ><br>
>     >     Poslání paketu:<br>
>     ><br>
>     >       memset(packetBuffer, 0, NTP_PACKET_SIZE);<br>
>     >        // Initialize values needed to form NTP request<br>
>     >        // (see URL above for details on the packets)<br>
>     >        packetBuffer[0] = 0b11100011;   // LI, Version, Mode<br>
>     >        packetBuffer[1] = 0;     // Stratum, or type of clock<br>
>     >        packetBuffer[2] = 6;     // Polling Interval<br>
>     >        packetBuffer[3] = 0xEC;  // Peer Clock Precision<br>
>     >        // 8 bytes of zero for Root Delay & Root Dispersion<br>
>     >        packetBuffer[12]  = 49;<br>
>     >        packetBuffer[13]  = 0x4E;<br>
>     >        packetBuffer[14]  = 49;<br>
>     >        packetBuffer[15]  = 52;<br>
>     ><br>
>     >        // all NTP fields have been given values, now<br>
>     >        // you can send a packet requesting a timestamp:<br>
>     >        _ntp_udp.beginPacket(timeServerIP, 123); //NTP requests<br>
>     are to<br>
>     >     port 123<br>
>     >        _ntp_udp.write(packetBuffer, NTP_PACKET_SIZE);<br>
>     >        _ntp_udp.endPacket();<br>
>     ><br>
>     ><br>
>     >     Příjem paketu:<br>
>     ><br>
>     >     _ntp_udp.read(packetBuffer, NTP_PACKET_SIZE); // read the<br>
>     packet into<br>
>     >     the buffer<br>
>     ><br>
>     >          //the timestamp starts at byte 40 of the received<br>
>     packet and is<br>
>     >     four bytes,<br>
>     >          // or two words, long. First, esxtract the two words:<br>
>     ><br>
>     >          unsigned long highWord = word(packetBuffer[40],<br>
>     >     packetBuffer[41]);<br>
>     >          unsigned long lowWord = word(packetBuffer[42],<br>
>     packetBuffer[43]);<br>
>     ><br>
>     ><br>
>     >     Jak zvýšit spolehlivost a eliminovat blbý čas?<br>
>     ><br>
>     ><br>
>     >     Díky<br>
>     ><br>
>     >     Petr_______________________________________________<br>
><br>
<br>
_______________________________________________<br>
HW-list mailing list  -  sponsored by <a href="http://www.HW.cz" rel="noreferrer" target="_blank">www.HW.cz</a><br>
<a href="mailto:Hw-list@list.hw.cz" target="_blank">Hw-list@list.hw.cz</a><br>
<a href="http://list.hw.cz/mailman/listinfo/hw-list" rel="noreferrer" target="_blank">http://list.hw.cz/mailman/listinfo/hw-list</a><br>
</blockquote></div></div>