<div dir="ltr"><div dir="ltr"><div>Myslim, ze kto chcel, tak uz pochopil, ze ked ide pouzivat nejaky standard, <br></div><div>tak musi trochu nastudovat, pochopit a zohladnit o nieco viacej suvislosti, <br></div><div>ako len "vybrat par bytov z nejakeho miesta z paketu". <br></div><div>Na tych miestach nemusi byt vzdy ta informacia, o ktorej si myslel, ze tam je ( v tomto pripade *presny cas*, aj ked "nejaky cas" tam je  )<br></div><div>Nie je to problem standardu, ale problem cloveka/uzivatela, ze nenastudoval do nutne potrebnej hlbky - aj nakopnutie "Dostuduj TU, alebo TOTO !" je velkou pomocou.<br></div><div>Studium je nutne, aj ked nebudu nevyuzite vsetky moznosti standardu. <br></div><div><br></div><div>Ak ma clovek pocit, ze jeho predstava je najidealnejsi standard - tu 
pravdepodobne ostane osamoteny, nekompatibilny s ostatnym svetom.</div><div>Ak sa niekomu nejaky standard nepaci, nemusi ho pouzit.  Moze fungovat/nefungovat podla vlastnych preferencii.</div><div><br></div><div>Myslim, ze autor prvotnej otazky nasiel smer, ktorym ma ist, aby problem vyriesil a dozvedel sa aj o niektorych certikoch po ceste.</div><div>- existuju adresy poolov NTP serverov a NTP servery<br></div><div>- nepouzit v nastaveni zdroja pool, ale servery, <br></div><div>- alebo pouzit pool a spravat sa k tomu ako ku poolu, pool rozlozit na severy a pouzit tie a nie samotnu adresu poolu</div><div>- riesit aj ostatne informacie v pakete - su dolezite<br></div><div>- synchronizovat sa na jeden *server* podla vyberu, aj ked je dostupnych viac</div><div>- podla coho zhodnotit, ci server poskytuje spravne data, alebo nie</div><div>- podla coho zhodnotit, ze server stratil istotu spravnych dat a moze poskytovat takmer spravne data, ale rovnako dobre aj uplne nespravne.<br></div><div>- ak poskytuje viacero serverov priblizne rovnake data, podla coho vybrat jeden</div><div></div><div>- existuju nestandardne stavy, ako pridanie 61 sekundy do niektorej minuty a je nutne to osetrit ( o pridavani leap sekundy min 99% ludi na planete vobec netusi )</div><div>- NTP server poskytuje data podla jeho konfiguracie a moznosti a nie podla predstavy klienta<br></div><div></div><div></div><div></div><div></div><div></div><div></div><div><br></div><div>Trvam na tom, ze ani opakovane citanie prislusnych 4 bytov nemusi pomoct, pretoze standard NTP na tych miestach NEMA vzdy to, co by sa dalo povazovat za presny cas ( ci uz je posun o milisekundy, alebo desiatky rokov )<br></div><div>Ci je na tych miestach bludny, nepresny, alebo presny cas a ak je presny, tak ako velmi je presny -> o tom informuju ine data v pakete a podla nich sa treba zariadit.</div><div>Ci sa vam to paci, alebo nie - to je nepodstatne, takto to pouzivaju to miliardy zariadeni na svete, vratane vasich ( PC, NTB, smartphone, atd. ... )</div><div>Dalsia polemika je zbytocna.<br></div><div>Mozete napisat vlastny "standard" a cas ukaze, ci bude lepsi a presadi sa voci existujucim a rozsiri sa medzi pouzivatelov.<br></div><div><br></div><div></div><div>Dodo<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">po 25. 7. 2022 o 11:39 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">Pamatujete si ještě o co v tomto vlákně šlo?<br>
Tazateli se občas vrátil špatný čas.<br>
Špatný, vadný, nikoli ujetý i nějaké milisekundy.<br>
<br>
Já jsem mu odepsal, že nejjednodušší a nejrychlejší řešení je opakované <br>
čtení.<br>
Vy jste začal polemizovat, že třeba switch Cisco může mít po startu <br>
špatný čas<br>
a tak nepomůže ani 1000-násobné opakování.<br>
Načež teď to stavíte tak, že se vlastně jedná o nějaké milisekundové <br>
odchylky,<br>
a že ty by nevadily ani nějakým synchronizacím kdoví čeho.<br>
<br>
Kdyby to byly ty milisekundy, tak to tazatel asi ani nezjistil a neměl <br>
by problém.<br>
Pokud ale něco vrací nějaké hausnumero, byť s příznakem, tak je to špatně.<br>
<br>
To hausnumero nemůže ničemu pomoct, ale může uškodit.<br>
Pokud by se na něho synchronizovaly ty Vámi zmiňované ovečky, tak by<br>
taky mohly skončit na dně Tichého oceánu.<br>
Kdyby hausnumero nedostaly, tak by jednoduše a prostě požádaly o čas<br>
alternativní přesný zdroj (a stále by zůstaly spolu na šťavnaté pastvě).<br>
<br>
PL<br>
<br>
*********************<br>
<br>
Dne 25.7.2022 v 10:19 Dodo Racek napsal(a):<br>
> Ano, ma to zmysel.<br>
><br>
> Premyslate v obmedzeni 2 zariadeni - "server", ktory poskytuje "nieco <br>
> podobne casu", neznamej prenosti, neznameho povodu, a klient, ktory ma <br>
> "nieco ako priblizny cas"<br>
> s neznamym komunikacnym oneskorenim a bez sance si overit serioznost <br>
> dat od servera.  V niektorych pripadoch to staci, ale vseobecne sa to <br>
> povedat neda.<br>
> NTP bolo navrhnute na komplexnejsie a presnejsie pouzitia s dynamicky <br>
> premenlivymi podmienkami na trase prenosu v roznych sposoboch <br>
> zavislosti hierarchycky vertikalnych aj horizontalnych.<br>
> To, ze to nedava zmysel Vam, na tom nic nemeni.<br>
><br>
> "Nezmyselny cas" je v niektorych pouzitiach napr. o 1ms inde ako <br>
> presny cas.<br>
> Udrzanie infrastruktury na rovnakom case napr. v pripade vypadku <br>
> synchronizanie na presnejsi casovy normal je niekedy klucove<br>
> Napr. clusterware rebootne nod clustra (a tym ho aj vyhadzuje z <br>
> clustra), ak sa objavi nod clustra, ktory ma iny cas o nejaku hodnotu, <br>
> ktoru cluster uz neakceptuje.<br>
><br>
> Ak si zariadenia predstavite ako ovecky, tak je vyhodnejsie, aby <br>
> ovecky zostali "v kosiari" a "cely kosiar s lokalnym honelnikom" sa <br>
> posuval pomaly na nespravne miesto<br>
> ( lokalny SW NTP odchadza sa od presneho casu po vypadku casoveho <br>
> normalu, alebo komunikacie s nim )<br>
> Po obnoveni casoveho normalu sa "cely kosiar" dotiahne na spravne <br>
> miesto - (baca da pokyny honelnikom a ti dozenu ovecky kam treba)<br>
> Ak by napr NTP server neposkytoval sluzby, tak sa "ovecky" rozlezu <br>
> kazda inam a po obnove by sa nemuseli vratit ( vzdialia sa dalej, ako <br>
> je moznost opatovnej synchronizacie )<br>
> So vsetkymi dosledkami.<br>
><br>
> Tieto casti su riesenim chyboveho stavu, ked vypadne komponent, alebo <br>
> vypadne komunikacia, nie ako primarne riesenie.<br>
> ( napriklad centrala s 2-mi datovymi centrami, 2 casovymi normalmi, <br>
> vsetko redundantne ... a desiatky, alebo stovky pobociek a na kazdej <br>
> pobocke desiatky, stovky, mozno aj tisicky zariadeni)<br>
> Je vyhodnejsie, ak na kazdej pobocke je lokalny SW NTP a v pripade <br>
> vypadku konektivity na centralu lokalne vsetko funguje dalej, cas sa <br>
> postupne stava menej presnym, ale cela pobocka je synchronizovana a <br>
> napr, aj lokalne DB funguju dalej.<br>
> Po obnove konektivity sa lokalny SW NTP postupne dotiahne na spravny <br>
> cas, s nim aj vsetky zariadenia na pobocke a DB sa nareplikuju na <br>
> centralu.<br>
><br>
> Ak to otocime z casu na informacie vseobecne - Vam dava zmysel, ak <br>
> niekto na internet (web, media, maily, ... cokolvek ) dava informacie, <br>
> ktore nie su spravne, nie su pravdive, a ich zdrojom je "ja si myslim" ?<br>
> Ak tie informacie su uvedene s priznakom " ja si myslim ", tak <br>
> prijimatel im priradi nejaku mieru doverihodnosti.<br>
><br>
> Ak by to fungovalo podla vasho navrhu, citujem:<br>
> ------<br>
>  " Poskytovat službu, vracející vědomě vadná data (i když s nějakým <br>
> příznakem), je tedy podle mě opravdu špatné."<br>
> ------<br>
><br>
> Ak informacia nie je 100% pravda, tak informaciu neposuniem dalej, <br>
> nezverejnim, (...NTP server neposkytne sluzbu, neodpovie... ) ... <br>
> Kolko prispevkov by ubudlo napr. aj v tejto konferencii ?<br>
><br>
> Dodo<br>
><br>
><br>
><br>
><br>
> ne 24. 7. 2022 o 13:54 Petr Labaj <<a href="mailto:labaj@volny.cz" target="_blank">labaj@volny.cz</a>> napísal(a):<br>
><br>
>     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<br>
>     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<br>
>     poskytovat.<br>
>     Čemu pomůže, že služba běží, ale dává nevalidní informace? Čemu<br>
>     konkrétně<br>
>     v tom Vašem případě, kdy potřebujete rovnaký čas? To jako že by se<br>
>     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).<br>
>     Nebo<br>
>     mailový<br>
>     server pří nedostupnosti dat vracel třeba staré maily, WWW server<br>
>     nějaké<br>
>     neplatné<br>
>     (ale zdánlivě správné) stránky atd.<br>
><br>
>     PL<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>