Re: příjem NTP ESP8266/32
Petr Labaj
labaj na volny.cz
Neděle Červenec 24 13:54:04 CEST 2022
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_______________________________________________
>
Další informace o konferenci Hw-list