Re: příjem NTP ESP8266/32

Pondělí Červenec 25 14:26:17 CEST 2022

Myslim, ze kto chcel, tak uz pochopil, ze ked ide pouzivat nejaky standard,
tak musi trochu nastudovat, pochopit a zohladnit o nieco viacej suvislosti,
ako len "vybrat par bytov z nejakeho miesta z paketu".
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  )
Nie je to problem standardu, ale problem cloveka/uzivatela, ze nenastudoval
do nutne potrebnej hlbky - aj nakopnutie "Dostuduj TU, alebo TOTO !" je
velkou pomocou.
Studium je nutne, aj ked nebudu nevyuzite vsetky moznosti standardu.

Ak ma clovek pocit, ze jeho predstava je najidealnejsi standard - tu
pravdepodobne ostane osamoteny, nekompatibilny s ostatnym svetom.
Ak sa niekomu nejaky standard nepaci, nemusi ho pouzit.  Moze
fungovat/nefungovat podla vlastnych preferencii.

Myslim, ze autor prvotnej otazky nasiel smer, ktorym ma ist, aby problem
vyriesil a dozvedel sa aj o niektorych certikoch po ceste.
- existuju adresy poolov NTP serverov a NTP servery
- nepouzit v nastaveni zdroja pool, ale servery,
- alebo pouzit pool a spravat sa k tomu ako ku poolu, pool rozlozit na
severy a pouzit tie a nie samotnu adresu poolu
- riesit aj ostatne informacie v pakete - su dolezite
- synchronizovat sa na jeden *server* podla vyberu, aj ked je dostupnych
viac
- podla coho zhodnotit, ci server poskytuje spravne data, alebo nie
- podla coho zhodnotit, ze server stratil istotu spravnych dat a moze
poskytovat takmer spravne data, ale rovnako dobre aj uplne nespravne.
- ak poskytuje viacero serverov priblizne rovnake data, podla coho vybrat
jeden
- 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 )
- NTP server poskytuje data podla jeho konfiguracie a moznosti a nie podla
predstavy klienta

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 )
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.
Ci sa vam to paci, alebo nie - to je nepodstatne, takto to pouzivaju to
miliardy zariadeni na svete, vratane vasich ( PC, NTB, smartphone, atd. ...
)
Dalsia polemika je zbytocna.
Mozete napisat vlastny "standard" a cas ukaze, ci bude lepsi a presadi sa
voci existujucim a rozsiri sa medzi pouzivatelov.

Dodo

po 25. 7. 2022 o 11:39 Petr Labaj <labaj na volny.cz> napísal(a):

> 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
> >
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20220725/ae40c6a2/attachment-0001.htm>