Re: příjem NTP ESP8266/32

Dodo Racek dodoracek na gmail.com
Neděle Červenec 24 13:20:12 CEST 2022 

Adresy, ktore pouzivate, su adresy poolov a k tym sa ntp klient sprava (ma
spravat) trochu inak ako ku NTP serverom.

DNS na tieto poolove adresy vrati mnozstvo adries napr:
dodo na tatry:~$ nslookup 0.cz.pool.ntp.org
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: 0.cz.pool.ntp.org
Address: 80.79.25.111
Name: 0.cz.pool.ntp.org
Address: 81.27.192.20
Name: 0.cz.pool.ntp.org
Address: 217.30.75.147
Name: 0.cz.pool.ntp.org
Address: 46.105.218.141

dodo na tatry:~$ nslookup 1.cz.pool.ntp.org
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: 1.cz.pool.ntp.org
Address: 162.159.200.1
Name: 1.cz.pool.ntp.org
Address: 94.124.107.190
Name: 1.cz.pool.ntp.org
Address: 147.251.48.140
Name: 1.cz.pool.ntp.org
Address: 89.221.216.187

dodo na tatry:~$ nslookup 2.cz.pool.ntp.org
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: 2.cz.pool.ntp.org
Address: 109.248.43.233
Name: 2.cz.pool.ntp.org
Address: 37.187.104.44
Name: 2.cz.pool.ntp.org
Address: 162.159.200.123
Name: 2.cz.pool.ntp.org
Address: 213.192.54.227
Name: 2.cz.pool.ntp.org
Address: 2a00:e140::123
Name: 2.cz.pool.ntp.org
Address: 2001:718:801:230::8c
Name: 2.cz.pool.ntp.org
Address: 2001:41d0:a:382c::1
Name: 2.cz.pool.ntp.org
Address: 2a02:8300:8000:4:214:5eff:fe7e:4bfc

Ak nastavim NTP klienta na tieto 3 poolove adresy, tak NTP klient rozlozi
poolove adresy na IP adresy - teda jednotlive servery  a zobrazi napr takto:

dodo na tatry:~$ ntpq -c peer
     remote           refid      st t when poll reach   delay   offset
 jitter
==============================================================================
 0.cz.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000
0.000
 1.cz.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000
0.000
 2.cz.pool.ntp.o .POOL.          16 p    -   64    0    0.000    0.000
0.000
 ntp44.kashra-se 192.168.100.15   2 u    1   64   17   52.245   -0.565
0.686
-a1.vnet.cx      .GPS.            1 u   11   64   17   30.496    3.162
0.101
-a11.vnet.cx     217.30.75.147    2 u    9   64   17   31.375    2.772
0.271
-ntp1.karneval.c 195.113.144.201  2 u   11   64   17   29.866    1.055
0.417
-pyrrha.fi.muni. 195.141.190.190  2 u    6   64   17   34.248    4.376
0.349
-inter.tyjo.eu   217.31.202.100   2 u    7   64   17   49.948   12.178
8.797
+ntp.axfone.eu   195.113.144.238  2 u    9   64   17   29.208    2.510
0.486
+netopyr.hanacke 94.124.107.175   3 u   11   64   17   34.056    2.276
0.501
-time.cloudflare 10.114.8.177     3 u    8   64   17   31.601   -2.957
0.284
 time.cloudflare 10.114.8.177     3 u    6   64   17   35.804   -1.573
0.568
*herbrand.noumic 193.190.230.37   2 u    8   64   17   49.280    2.238
0.533
+ntp.cz.altrosky 195.171.43.12    2 u    8   64   17   29.264    2.043
0.499
 mail.jabu.cz    81.25.28.124     2 u    4   64   17   35.352    1.091
0.639
 81.2.248.189 (h 195.113.144.201  2 u    5   64   17   32.725    2.453
0.561
 vps.poljakovi.c 195.113.144.238  2 u   67   64    7   31.720    2.197
0.821
 ntp31.kashra-se 192.168.100.15   2 u   64   64    3   42.600   -1.472
0.328

Vsimnite si, ze to, co je nastavene ako pool ma stratum 16, jednotlive
servery maju stratum nizsie.
Prvy stlpec je adresa servera ( reverse DNS z IP adries, ktore boli ziskane
requestom na IP adresu z FQDN poolu )
Druhy stlpec (refid) je IP adresa, ktoru pouziva server ako svoju
referencnu ( na ktoru sa server synchronizuje - a v jednom pripade tam je
.GPS. )

Prvy znak ("znamienko") v riadku pred menom servera hovori o tom, ako sa
sprava NTP klient k serveru

Pozrite si "Tally codes" napriklad tu:
https://linux.die.net/man/8/ntpq

A v tom manuale najdete aj popis ostatnych stlpcov vypisu.

V prvom kroku nepouzite poolove adresy ako definicie adries serverov ( to
je prva chyba konfiguracie), ale pouzite realne adresy napr. 3 vybranych
rozdielnych serverov. Dajte si pozor, aby neboli synchronizovane na ten
isty zdroj => tak budu nezavisle.

Pri spracovani si vyberte podla dasich parametrov ( stratum, delay, offset
jitter... ) si vyberte jeden server a synchronizujte sa iba na tento server
( pokial navrati vyssi stratum, ako daval v minulosti ). Ked vrati vyssi
stratum, znovu zbehnite proces vyberu jedneho serevera na synchronizaciu zo
vsetkych nakonfigurovanych.

Konkretnemu serveru verte len vtedy, ak v pravidelnych otazkach ( napr 10
po sebe v intervaloch napr. po 64 sekund ) vrati cas, ktory sedi s
predpokladanym (ocakavanym) casom a ostatne parametre neuleteli.

Treba si uvedomit, ze cas (cislo) v pakete je cas, ktory bol v case
skaldania paketu na serveri. Delay, offset, jitter su dynamicke hodnoty,
vznikajuce "po cesete", ktore mozu lietat aj 4 rady - napr. oneskorenie od
1 ms kludne do 10 sekund.
Aj ked vo vasej aplikacii to je jedno, pri vybere servera, ktory si
vyberiete na synchronizaciu si vyberajte taky, ktory ma tie hodnoty
priblizne rovnake
v kazdej odpovedi na request. Aj ked ma napr. stratum o :1: horsi.

Dodo


ne 24. 7. 2022 o 11:40 Petr Zapadlo <zapik na email.cz> napísal(a):

> Pool funguje na úrovni DNS, takže žádné průměry ani nečekám. Ale při
> každém DNS dotazu na konkrétní pool dostávám různou IP adresu, viz níže
> vždy trojice IP adres:
>
>
> 37.187.104.44 (pool 0)
> 5.1.56.123        (pool 1)
> 217.30.75.147 (pool 2)
>
> 82.113.53.41
> 213.32.40.221
> 37.187.104.44
>
> 46.105.218.141
> 162.159.200.123
> 51.89.33.100
>
> Petr
>
>
> Dne 24. 07. 22 v 11:26 Dodo Racek napsal(a):
>
> A este jedna rada.
> NTP klient sice pooluje vsetky nastavene servey, ale  synchronizuje sa len
> na jeden, ktory si vyberie podla ostatnych parametrov v komunikacii
> (stratum, delay, jitter...)
>
> Nerobi priemery, ani nahodne, ci pravidelne zmeny  vyberu servera.
>
>
>
> Dodo
>
> Dňa ne 24. 7. 2022, 11:18 Dodo Racek <dodoracek na gmail.com> napísal(a):
>
>> Ak sa da, tak si logujte datum a cas z vaseho pocitania casu a co chcete
>> nastavit. Napriklad na sd kartu ako rotacny log, alebo na log server.
>>
>> Podla zalogovanych hodnot, ktore chcete nastavit sa mozno bude dat
>> odhadnut ktorym smerom patrat.
>> Napr. Sedia minuty a sekundy, ale nezedia hodiny -> problem casove
>> pasmo... atd.
>>
>> Dodo
>>
>>
>> Dňa ne 24. 7. 2022, 10:22 Petr Zapadlo <zapik na email.cz> napísal(a):
>>
>>> Zdravím,
>>>
>>> odečítá se od 1970 (unix time stamp), samotného mě přkvapilo jak málo se
>>> z toho paketu vlastně využije. Ale přesnostně mi to bohatě stačí (ani
>>> minuta není pro mě kritická míra). Podívám se co dalšího by v tom paketu
>>> bylo ještě využitelného - minimálně kontrola Stratum by stála za úvahu.
>>>
>>> Zatím jsem udělal to, že jsem dopsal důslednou kontrolu délek paketu a
>>> jeho čtení. Tak uvidím co to bude dělat, problém je v tom, že mi bude
>>> dost dlouho trvat než ověřím, že to skutečně bylo řešení.
>>>
>>> Petr
>>>
>>> Dne 24. 07. 22 v 8:47 Miroslav Mraz napsal(a):
>>> > Tohle zřejmě někdo převzal přímo z arduina -
>>> > https://www.arduino.cc/reference/en/libraries/ntpclient/. Je to
>>> > napsané celé blbě. Autor zřejmě netuší, že existuje něco jako
>>> > stdint.h, zcela zbytečně používá u členských dat this-> (vy to tam už
>>> > nemáte) - zřejmě je zvyklý na python nebo javascript. Z přijatého
>>> > paketu jen převezme počet sekund od nějakého data. Nebudu zkoumat,
>>> > jestli to má být rok 1900 (jak tam píše) nebo spíš 1970 (unix
>>> > timestamp), podstatné je, že spoustu informací z toho paketu prostě
>>> > zahodí. Chtělo by to paket podrobně prozkoumat a pokud v něm budou
>>> > blbosti, tak ho prostě ignorovat.
>>> >
>>> > Mrazík
>>> >
>>> > On 24. 07. 22 5:34, Petr Zapadlo wrote:
>>> >> Zdravím, odpovím tak nějak hromadně všem v jedné zprávě.
>>> >>
>>> >> Ne, read návratový kod neošetřuje - dobrý nápad - read by mělo vrátit
>>> >> počet byte paketu - zkusím kontrolovat, to by mohlo pomoci na nějaké
>>> >> fake pakety.
>>> >>
>>> >> Interní čas počítám a synchro dělám jednou za 12 hodin a při startu,
>>> >> nejede mi tam nic kritického abych musel implementovat časový fázový
>>> >> závěs (jestli se rybičkám rozsvítí o vteřinu dřív anebo později je
>>> >> jedno :-)).
>>> >>
>>> >> Jako časový server používám  české pooly NTP serverů:
>>> >>
>>> >> String ntp_hosts[NUM_NTP]
>>> >> ={"0.cz.pool.ntp.org","1.cz.pool.ntp.org","2.cz.pool.ntp.org"};
>>> >>
>>> >> Prakticky to znamená, že každé čtení jde proti jinému NTP serveru.
>>> >>
>>> >> Celé jsou to zkoušel ve vlaku LEO Express do Prahy - Leoš má dost
>>> >> blbou wifi, takže o výpadky tam není nouze, stejně tak o latenci
>>> >> paketů jdoucí až >15s,  měl jsem upravenou synchronizaci aby to šlo
>>> >> co pár vteřin a ani jednou to nezablblo. Říkal jsem si, že blbější
>>> >> situace už nenastane :-) (A nastala)
>>> >>
>>> >> 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
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.czHw-list na list.hw.czhttp://list.hw.cz/mailman/listinfo/hw-list
>
> _______________________________________________
> 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/20220724/64005b67/attachment.htm>

Další informace o konferenci Hw-list