Re: příjem NTP ESP8266/32

[Petr Labaj]

Pamatujete si ještě o co v tomto vlákně šlo?
Tazateli se občas vrátil špatný čas.
Špatný, vadný, nikoli ujetý i nějaké milisekundy.

Já jsem mu odepsal, že nejjednodušší a nejrychlejší řešení je opakované 
čtení.
Vy jste začal polemizovat, že třeba switch Cisco může mít po startu 
špatný čas
a tak nepomůže ani 1000-násobné opakování.
Načež teď to stavíte tak, že se vlastně jedná o nějaké milisekundové 
odchylky,
a že ty by nevadily ani nějakým synchronizacím kdoví čeho.

Kdyby to byly ty milisekundy, tak to tazatel asi ani nezjistil a neměl 
by problém.
Pokud ale něco vrací nějaké hausnumero, byť s příznakem, tak je to špatně.

To hausnumero nemůže ničemu pomoct, ale může uškodit.
Pokud by se na něho synchronizovaly ty Vámi zmiňované ovečky, tak by
taky mohly skončit na dně Tichého oceánu.
Kdyby hausnumero nedostaly, tak by jednoduše a prostě požádaly o čas
alternativní přesný zdroj (a stále by zůstaly spolu na šťavnaté pastvě).

PL

*********************

Dne 25.7.2022 v 10:19 Dodo Racek napsal(a):
> Ano, ma to zmysel.
>
> Premyslate v obmedzeni 2 zariadeni - "server", ktory poskytuje "nieco 
> podobne casu", neznamej prenosti, neznameho povodu, a klient, ktory ma 
> "nieco ako priblizny cas"
> s neznamym komunikacnym oneskorenim a bez sance si overit serioznost 
> dat od servera.  V niektorych pripadoch to staci, ale vseobecne sa to 
> povedat neda.
> NTP bolo navrhnute na komplexnejsie a presnejsie pouzitia s dynamicky 
> premenlivymi podmienkami na trase prenosu v roznych sposoboch 
> zavislosti hierarchycky vertikalnych aj horizontalnych.
> To, ze to nedava zmysel Vam, na tom nic nemeni.
>
> "Nezmyselny cas" je v niektorych pouzitiach napr. o 1ms inde ako 
> presny cas.
> Udrzanie infrastruktury na rovnakom case napr. v pripade vypadku 
> synchronizanie na presnejsi casovy normal je niekedy klucove
> 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.
>
> 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
> ( lokalny SW NTP odchadza sa od presneho casu po vypadku casoveho 
> normalu, alebo komunikacie s nim )
> Po obnoveni casoveho normalu sa "cely kosiar" dotiahne na spravne 
> miesto - (baca da pokyny honelnikom a ti dozenu ovecky kam treba)
> 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 )
> So vsetkymi dosledkami.
>
> Tieto casti su riesenim chyboveho stavu, ked vypadne komponent, alebo 
> vypadne komunikacia, nie ako primarne riesenie.
> ( 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)
> 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.
> 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.
>
> 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" ?
> Ak tie informacie su uvedene s priznakom " ja si myslim ", tak 
> prijimatel im priradi nejaku mieru doverihodnosti.
>
> Ak by to fungovalo podla vasho navrhu, citujem:
> ------
>  " Poskytovat službu, vracející vědomě vadná data (i když s nějakým 
> příznakem), je tedy podle mě opravdu špatné."
> ------
>
> 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 ?
>
> Dodo
>
>
>
>
> ne 24. 7. 2022 o 13:54 Petr Labaj <labaj na volny.cz> napísal(a):
>
>     Promiňte, ale to, co jste napsal - opravdu Vám to dává smysl?
>
>     Pokud mám infrastrukturu, kde potřebuju jednotný čas, tak se podle
>     toho
>     zařídím.
>     NTP server může běžet kde na čem, tak ho nemusím provozovat zrovna na
>     switchi,
>     který asi nemá ani RTC pro udržení času při výpadku napájení. Soudím
>     podle toho,
>     že zřejmě vrací nesmyslný čas - použil jsem to jako příklad, proč tam
>     původnímu
>     tazateli skočí nějaký nesmyslný čas.
>
>     Poskytovat službu, vracející vědomě vadná data (i když s nějakým
>     příznakem), je
>     tedy podle mě opravdu špatné. Nemám přesný čas, tak nemám služby
>     poskytovat.
>     Čemu pomůže, že služba běží, ale dává nevalidní informace? Čemu
>     konkrétně
>     v tom Vašem případě, kdy potřebujete rovnaký čas? To jako že by se
>     všichni
>     synchronizovali na ten vadný čas? A jak to zařídit, když klient o to
>     požádá jindy?
>
>     Předpokládám, že třeba u databazového serveru byste taky nechtěl, aby
>     když nemá
>     zdroj platných dat, tak vrátil nějaká fake-data (byť s příznakem).
>     Nebo
>     mailový
>     server pří nedostupnosti dat vracel třeba staré maily, WWW server
>     nějaké
>     neplatné
>     (ale zdánlivě správné) stránky atd.
>
>     PL
>