Re: příjem NTP ESP8266/32
Dodo Racek
dodoracek na gmail.com
Neděle Červenec 24 13:33:00 CEST 2022
a po case sa NTP klient dosynchronizuje na "najpresnejsi" server
root na tatry:/etc# ntpq -c peers
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
*a1.vnet.cx .GPS. 1 u 94 128 377 29.470 -1.106
0.420
+a11.vnet.cx 217.30.75.147 2 u 32 128 377 30.849 -0.743
0.223
-inter.tyjo.eu 217.31.202.100 2 u 94 128 377 30.739 -0.392
0.228
-herbrand.noumic 193.190.230.37 2 u 219 256 377 48.897 -1.323
0.309
-ntp.cz.altrosky 80.79.25.111 3 u 202 256 377 29.016 -1.343
0.196
+81.2.248.189 (h 195.113.144.201 2 u 71 128 377 32.606 -0.765
0.171
-vps.poljakovi.c 195.113.144.238 2 u 80 128 377 30.958 -0.728
0.304
root na tatry:/etc#
Porovnajte si riadky, ktore zacinaju "*" z minuleho vypisu a z terajsieho.
* ako prvy znak vo vypise znamena, ze klient sa synchronizjue na tento
server.
Dodo
ne 24. 7. 2022 o 13:20 Dodo Racek <dodoracek na gmail.com> napísal(a):
> 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/f9bd9585/attachment.htm>
Další informace o konferenci Hw-list