Re: příjem NTP ESP8266/32
Dodo Racek
dodoracek na gmail.com
Pondělí Červenec 25 10:19:23 CEST 2022
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
>
> ********************
>
> Dne 24.7.2022 v 11:34 Dodo Racek napsal(a):
> > Su riesenia, kde nie je nutny absolutne presny cas, ale je nutny
> > *rovnaky* cas v celej infrastrukture.
> >
> > Nerobia to len zariadenia cisco, ale routre mnohych inych vyrobcov.
> >
> > Protokol NTP na to pamata, ale je potrebne trochu chapat suvislosti a
> > nie iba vybrat 4 Byty z komunikacie.
> >
> > Dodo
> >
> > Dňa ne 24. 7. 2022, 0:43 Petr Labaj <labaj na volny.cz> napísal(a):
> >
> > Sakryš, to je ale chytrý server, ten Cisco switch.
> > Má blbě čas, ale stejně ho vrátí a jenom nastaví nějaký parametr.
> >
> > Kdysi jsem musel napsat vlastní časový server (s protokolem rdate).
> > Tak jsem to udělal jednoduše tak, že dokud neměl od nadřízeného
> > serveru
> > přesný čas, tak prostě službu neposkytoval a žádost odmítl.
> > Rozumný klient (toho jsem psal taky) má seznam serverů. Tak když
> > jeden
> > službu neposkytuje, osloví dalšího.
> > Nojo, no. Nejsem tak chytrý jako Cisco.
> >
> > PL
> >
> > *********************
> >
> > Dne 23.7.2022 v 23:20 Dodo Racek napsal(a):
> > > Okrem precitaneho casu z paketu sledujte aj stratum.
> > > Cim nizsie cislo, tym lepsie. (0- atomove hodiny, 1-
> > synchronizovane
> > > voci atomovym hodinam, 2- synchronizovane voci 1, atd...) na
> > internete
> > > bezne server bude mat stratum 2-3.
> > > Server MUSI mat stratum rovnake cislo.
> > > Ak serveru vypadne synchronizacia na presnejsi nadradeny, tak to
> > > "oznami" klientom zmenou hodnoty v stratum. Cisla nad 10 sa
> > pouzivaju
> > > pre nepresny cas (lokalny oscilator bez synchronizacie), takemu
> > casu
> > > sa neveri.
> > >
> > > Ked sa nejedna o utok, ale o to, ze aj nadradeny server stratil
> > presny
> > > cas a oznamuje bludy, tak vam nepomoze ani 1000 nacitani a
> > porovnavani.
> > >
> > > Ak je NTP server napr. cisco switch, alebo router, tak obycajne
> > nema
> > > vlastne HW hodiny. Po zapnuti, alebo reboote oznamuje klientom
> > > nezmyselny cas az do chvile, kym sa nezosynchronizuje s
> > nadradenym ntp
> > > sevrom. To moze trvat aj 15 min. Oznamuje ale definovanym
> > > (nakonfigurovanym) vysokym cislom pre stratum.
> > >
> > > Voci akemu NTP serveru (FQDN,IP) sa zvyknete synchronizovat?
> > >
> > >
> > > Dodo
> > >
> > > Dňa so 23. 7. 2022, 21:28 Petr Zapadlo <zapik na email.cz>
> napísal(a):
> > >
> > > Zdravím,
> > >
> > > na většině projektů, kde je třeba čas, tak ho
> > synchronizuji z NTP.
> > > Občas (třeba jednou za půl roku) se stane, že ESP získá
> > špatný čas.
> > > Pokusil jsem se to eliminovat - načítám čas 3x a porovnávám -
> > > použiji
> > > dvě hodnoty, které mají minimální rozestup. (pokud se nesejdou,
> > > tak to
> > > ignoruji a zkouším znova)
> > >
> > > Situace se zlepšila, přesto občas k problému dojde. Zdá se, že
> > > četnost
> > > nějak závisí i na kvalitě internetové linky. U mě doma se to
> > > prakticky
> > > neděje (Metronet, DSL, modem Terminator) , ale u známé se to
> > děje
> > > poměrně často (měsíčně) (O2, DSL, modem ZTE), u syna tak
> > jednou za
> > > půl
> > > roku (kabelovka Vodafone).
> > >
> > > Vypadá to, že za nějakých podmínek projde UDP stackem v ESP
> > i paket,
> > > který není v pořádku - asi má i vadný checksum, ale vzhledem k
> > > četnosti
> > > to nejsem schopen nijak ověřit. Případně projde nesmyslný
> paket
> > > (ale to
> > > by měl eliminovat požadavek na 2 stejné hodnoty).
> > >
> > > Jak se divám do struktury NTP paketu, tak tam už žádný
> kontrolní
> > > mechanizmus není. (dívám se dobře?)
> > >
> > > Základní kus kodu je vzat z mnohokrát opakovaného příkladu:
> > >
> > > Poslání paketu:
> > >
> > > memset(packetBuffer, 0, NTP_PACKET_SIZE);
> > > // Initialize values needed to form NTP request
> > > // (see URL above for details on the packets)
> > > packetBuffer[0] = 0b11100011; // LI, Version, Mode
> > > packetBuffer[1] = 0; // Stratum, or type of clock
> > > packetBuffer[2] = 6; // Polling Interval
> > > packetBuffer[3] = 0xEC; // Peer Clock Precision
> > > // 8 bytes of zero for Root Delay & Root Dispersion
> > > packetBuffer[12] = 49;
> > > packetBuffer[13] = 0x4E;
> > > packetBuffer[14] = 49;
> > > packetBuffer[15] = 52;
> > >
> > > // all NTP fields have been given values, now
> > > // you can send a packet requesting a timestamp:
> > > _ntp_udp.beginPacket(timeServerIP, 123); //NTP requests
> > are to
> > > port 123
> > > _ntp_udp.write(packetBuffer, NTP_PACKET_SIZE);
> > > _ntp_udp.endPacket();
> > >
> > >
> > > Příjem paketu:
> > >
> > > _ntp_udp.read(packetBuffer, NTP_PACKET_SIZE); // read the
> > packet into
> > > the buffer
> > >
> > > //the timestamp starts at byte 40 of the received
> > packet and is
> > > four bytes,
> > > // or two words, long. First, esxtract the two words:
> > >
> > > unsigned long highWord = word(packetBuffer[40],
> > > packetBuffer[41]);
> > > unsigned long lowWord = word(packetBuffer[42],
> > packetBuffer[43]);
> > >
> > >
> > > Jak zvýšit spolehlivost a eliminovat blbý čas?
> > >
> > >
> > > Díky
> > >
> > > Petr_______________________________________________
> >
>
> _______________________________________________
> 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/7b894872/attachment.htm>
Další informace o konferenci Hw-list