Ajanjakelu (NTP yms.)

[anders]

Keskustelu erotettu toisesta ketjusta. Alun voi lukea täältä:

Teslan valoshow

Aikamoinen valoshow:hattu: Osaisiko kukaan sanoa, millä tavalla ja millä yhteydellä noita autojen valoja on tuossa valoshowssa ohjattu toimimaan ?

lampopumput.info

NTP:n täytyy esimerkiksi adaptoitua aikaserveriin kunnon tovin ajan, jotta verkkoyhteyden viiveet ja huojunta saadaan kompensoiduksi. Tuokin vie vähintään minuutteja, usein pitempäänkin.

No kyllä one shot ntp synkka vie luokkaa muutaman sekunnin.

Kokeilee vaikka (linuxissa):

time ntpdate pool.ntp.org

Ja sntp on vielä nopeampi

edit. kokeilin, vei 2ms:

time ntpdate pool.ntp.org
-bash: ntpdate: command not found

real 0m0.002s
user 0m0.001s
sys 0m0.000s

edit2, 6ms:

time ntpdate pool.ntp.org
13 Oct 09:31:24 ntpdate[16688]: bind() fails: Permission denied

real 0m0.006s
user 0m0.005s
sys 0m0.000s

edit3:

time sudo ntpdate pool.ntp.org
13 Oct 09:33:56 ntpdate[29442]: adjust time server 78.47.168.188 offset -0.000004 sec

real 0m1.117s
user 0m0.000s
sys 0m0.004s

 

[kotte]

time ntpdate pool.ntp.org

Tuohan ei ole ntp, vaan kyselee ajan erikseen. Verkon viiveet tulevat mukaan tuossa.

Varsinainen alkuperäinen ja edelleen tarkkuusaikaasetuksissa käytettävä ntp edellyttää pitkäaikaista seurantaa molempiin suuntiin lähetettävillä paketeilla ja viiveiden sekä näiden vaihteluiden tilastollista käsittelyä. Ei tuota voi kovin paljon mitenkään nopeuttaa ilman, että tarkkuus menetetään.

 

[anders]

Tuohan ei ole ntp, vaan kyselee ajan erikseen. Verkon viiveet tulevat mukaan tuossa.

Öö onhan se NTP työkalu, kuitenkin, ja puhuu ihan sujuvaa NTP:tä verkkoon päin...

ntp/ntpdate/ntpdate.c at master · benegon/ntp

UNOFFICIAL git mirror for stable ntp from ntp.org. Contribute to benegon/ntp development by creating an account on GitHub.

github.com

Varsinainen alkuperäinen ja edelleen tarkkuusaikaasetuksissa käytettävä ntp edellyttää pitkäaikaista seurantaa molempiin suuntiin lähetettävillä paketeilla ja viiveiden sekä näiden vaihteluiden tilastollista käsittelyä. Ei tuota voi kovin paljon mitenkään nopeuttaa ilman, että tarkkuus menetetään.

NTP on muutenkin niin epätarkka, että sitä juuri voi käyttää mihinkään tarkkuutta vaativaan. Ei tuo ntpdate paljoa sitä huononna. NTP:llä saa ihmisen mittakaavassa tarkan ajan, muttei tietokoneen, ei edes lähiverkossa.

PTP tai GNSS on sitten jos oikeasti tarvitaan tarkkaa aikaa, esim TDMA:han tms. Niihin ei NTP riitä ikuna eikä silloinkaan.

Mutta joo, miksei Leonin Telsa käytä GNSS aikasynkkaa? Tai varmasti sisäisesti kyllä käyttää, mutta miksei tuo karaoke jukeboxi ole siihen synkassa?

 

[Jule]

No kyllä one shot ntp synkka vie luokkaa muutaman sekunnin.

Kokeilee vaikka (linuxissa):

time ntpdate pool.ntp.org

Ja sntp on vielä nopeampi

edit. kokeilin, vei 2ms:



edit2, 6ms:



edit3:

Siis ei sen ajan hakeminen netistä vie kuin millisekunteja, mutta jos tietokoneen kello on väärässä ajassa ei ole hyvän käytännön mukaista vaan laakista päivittää sinne uutta aikaa, moni softa vetää herneen nenäänsä jos kellonaika loikkaa yhtäkkiä hetken matkaa menneisyyteen tai tulevaisuuteen, jonka takia kello säädetään taaksepäin viivästämällä jokaista millisekuntia kunnes todellinen aika on ottanut tietokoneen kiinni, tai vaihtoehtoisesti säädetään eteenpäin hyppimällä millisekunteja yli. Tuo säätö voi ottaa virheestä riippuen pitkäänkin.

 

[anders]

Siis ei sen ajan hakeminen netistä vie kuin millisekunteja, mutta jos tietokoneen kello on väärässä ajassa ei ole hyvän käytännön mukaista vaan laakista päivittää sinne uutta aikaa, moni softa vetää herneen nenäänsä jos kellonaika loikkaa yhtäkkiä hetken matkaa menneisyyteen tai tulevaisuuteen, jonka takia kello säädetään taaksepäin viivästämällä jokaista millisekuntia kunnes todellinen aika on ottanut tietokoneen kiinni, tai vaihtoehtoisesti säädetään eteenpäin hyppimällä millisekunteja yli. Tuo säätö voi ottaa virheestä riippuen pitkäänkin.

Kyllä.

Mutta tämä on aikasynkronista täysin erillinen ongelma, eikä eroa sen suhteen, tehdäänkö synkka NTP:llä, SNTP:llä, GNSS:llä tai PTP:llä.

 

[kotte]

NTP on muutenkin niin epätarkka, että sitä juuri voi käyttää mihinkään tarkkuutta vaativaan. Ei tuo ntpdate paljoa sitä huononna. NTP:llä saa ihmisen mittakaavassa tarkan ajan, muttei tietokoneen, ei edes lähiverkossa.

On alkuperäinen (ja edelleen käytetty) keskusteleva ntp varsin tarkka, jos verkko on mahdollisimman deterministinen viiveiden puolesta eikä verkossa ole järin suurta kuormaa välillä. Ntp pystyy näyttämään referenssikellojen erot tyypillisesti muutamien mikrosekunttien tasolla (mikä nyt ainakin omasta mielestäni on kertaluokkia tarkempi kuin ihmisen mittakaava). Protokollavaihto viestien tasolla menee tyypillisesti millisekunnissa, parissa, jos kone on kytketty kuidulla. Ntpdate sen sijaan ei ole sen tarkempi kuin katsoa jotakin kelloa netin kautta (tyypillisesti tuhansia kertoja epätarkempi kuin varsinainen ntp). Ntpdate on tullut mukaan myöhemmin lähinnä syystä, että bootattuun koneeseen, jossa ei ollut reaaliaikakelloa, piti saada melko tarkka alkuarvio ajalle jostakin, mistä sitten lähteä tarkentamaan. Moni tietokonehan ei kätevästi pysty pitämään kelloaan ajassa tarkemmin kuin kymmenien millisekuntien tarkkuudella (kello käy miten käy ja sitä on säädettävä jatkuvasti, jos aikaa saada kellon käymään tarkasti), mutta ntp kyllä pystyy toteamaan virheen varsin tarkasti tarkempiin referenssikelloihin netissä.

Ammattilaisilla, jotka ntp:n kehittivät, oli varmistetulla virtalähteellä ajassa pysyvä kello myös systeemikatkosten yli ja alkuarvo hommattiin jostakin muualta (radiolla, aikamerkillä ja myöhemmin GPS:llä). Toki GNSS:stä saadaan varsin tarkka aika, koska sillä saadaan myös paikka 3-d koordinaatistossa ja sen perusteella voidaan korjata radiaaltojen etenemisvirheestä aiheutunut bias.

 

[anders]

On alkuperäinen (ja edelleen käytetty) keskusteleva ntp varsin tarkka, jos verkko on mahdollisimman deterministinen viiveiden puolesta eikä verkossa ole järin suurta kuormaa välillä. Ntp pystyy näyttämään referenssikellojen erot tyypillisesti muutamien mikrosekunttien tasolla (mikä nyt ainakin omasta mielestäni on kertaluokkia tarkempi kuin ihmisen mittakaava). Protokollavaihto viestien tasolla menee tyypillisesti millisekunnissa, parissa, jos kone on kytketty kuidulla.

Tehdään niin että kokeilet mihin tarkkuuteen pääset.

Tee tällainen setup, laitat kaksi RT käyttistä, esim RT-Linux hostia antamaan PPS signaalin ja katsot skoopilla eron.

Minä olen tätä kokeillut, sattuneesta syystä.

NTP:llä et yksinkertaisesti pääse edes lähiverkossa kuin tuhansiin, kymmeniin tuhansiin mikrosekunteihin, oli kyseessä kuitu tai kupari.

Puuhaan duunissa sellaisten (jokaiselle tuttujen) radioaaltojen kanssa toimivien vehkeiden kanssa, jotka vaativat tarkkudeksi muutamia mikrosekunteja, tai homma ei toimi.

PTP:llä tämä onnistuu juuri ja juuri, mutta vaatii paljon jumppaa ja optimaalisen setupin. Whiterabbit pystyvät parempaan, koska mukana SyncE.

GNSS:llä tämä onnistuu triviaalisi, mutta on haaste esimerkiksi kilometri maan alla.

Ntpdate sen sijaan ei ole sen tarkempi kuin katsoa jotakin kelloa netin kautta (tyypillisesti tuhansia kertoja epätarkempi kuin varsinainen ntp).

Mutta sehän juttelee ihan NTP:tä?

 

[kotte]

Mutta sehän juttelee ihan NTP:tä?

Eihän se juttele. Tuon tietää jo siitäkin, että ntpdate asettaa ajan aika nopeasti, tyypillisesti sekunneissa ja myös äskettäin bootatulle koneelle, josta on ollut virrat pois ja vaikka mahdollinen reaaliaikakello nollattu. Ei ntp:tä voi saada käyntiin tuollaisessa ajassa, vaan riittävä määrä molempiin suuntiin kulkevia protokollanvaihtoja vie tyypillisesti ainakin kymmenen minuuttia perussynkronointiinkin yhdelle serverille. AIkaa kuluu vielä lisää, kun protokollaan käytetään tarkoitetulla tavalla parhaan vaihtoehdon ja varaserverilistan muodostamiseen, saatavilla olevien servereiden joukosta.

Esimerkkinä siitä, mitä esimerkiksi yksi oma serverini kuuntelee on seuraava ntpd:n ilmoittama ja ylläpitämä lista. AIkalukemat ovat kolmessa viimeisessä sarakkeessa millisekunteja (tuo on Elisan verkossa; kone ei ole mitenkään erikoinen eikä verkkoyhteyskään; yleensä minkään tietokoneen kelloa ei saa käymään kovin tarkasti, joten tälläisen verkkottuneen kellon käyttö on välttämätöntä ja aikalaskelman on perustettava jälkianalyysiin; jos haluaa tarkan ajastimen, täytyy olla ulkoinen säädettävä oskillaattori, jota sitten rukataan poikkeaman perusteella kulloinkin tarvittavaan suuntaan):

ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
0.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.000
1.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.000
2.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.000
3.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.000
*194.100.49.151 194.100.49.133 2 u 503 1024 377 1.895 -0.013 0.015
-ftp.mikes.fi 194.100.49.134 2 u 1050 1024 377 1.953 -0.060 0.052
+62.241.198.253 62.237.86.234 2 u 74 1024 377 5.041 +0.045 0.036
-time.cloudflare 10.79.9.32 3 u 788 1024 377 1.373 -0.125 0.038
+time.cloudflare 10.79.9.32 3 u 883 1024 377 1.128 +0.033 0.161
ntpq> quit

 

[anders]

Eihän se juttele.

No hei kokeile itse:

time sudo ntpdate 78.47.168.188
14 Oct 21:00:07 ntpdate[1782752]: adjust time server 78.47.168.188 offset -0.000053 sec

real 0m6.124s
user 0m0.006s
sys 0m0.005s

sudo tcpdump -n -i any udp port 123
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
21:00:01.498106 enp0s6 Out IP 10.0.0.219.123 > 78.47.168.188.123: NTPv4, Client, length 48
21:00:01.503575 enp0s6 In IP 78.47.168.188.123 > 10.0.0.219.123: NTPv4, Server, length 48
21:00:03.498059 enp0s6 Out IP 10.0.0.219.123 > 78.47.168.188.123: NTPv4, Client, length 48
21:00:03.503460 enp0s6 In IP 78.47.168.188.123 > 10.0.0.219.123: NTPv4, Server, length 48
21:00:05.498049 enp0s6 Out IP 10.0.0.219.123 > 78.47.168.188.123: NTPv4, Client, length 48
21:00:05.503525 enp0s6 In IP 78.47.168.188.123 > 10.0.0.219.123: NTPv4, Server, length 48
21:00:07.498041 enp0s6 Out IP 10.0.0.219.123 > 78.47.168.188.123: NTPv4, Client, length 48
21:00:07.503452 enp0s6 In IP 78.47.168.188.123 > 10.0.0.219.123: NTPv4, Server, length 48

^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Mitä tuo on, jos ei silkkoa NTP:tä?

Luulen että sinulla menee nyt sekaisin käsitteet. NTP protokolla on ihan tuota mitä tuossa näkyy.

Sitten on erikseen kellon synkronointimekanismi, joka ei ole kiinni verkkoprotokollasta, jota nyt varmaan haet takaa.

Aivan samalla tavalla kellon synkronointi pitää tehdä ajan kanssa, on referenssinä NTP, PTP tai GNSS. Ainoa että sitä ei oikeasti voi tietokoneella tehdä tarkasti, jos tietokoneesta ei löydy PHC:tä:

ethtool -T em3
Time stamping parameters for em3:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)

 

[anders]

AIkalukemat ovat kolmessa viimeisessä sarakkeessa millisekunteja

PTP:llä nämä ovat nanosekunteja, ja oikeita lukuja, eivät hanska-arvioita kuten NTP:llä:

ptp4l[5374018.735]: rms 787 max 1208 freq -38601 +/- 1071 delay -14 +/- 0
ptp4l[5374019.735]: rms 1314 max 1380 freq -36204 +/- 346 delay -14 +/- 0
ptp4l[5374020.735]: rms 836 max 1106 freq -35734 +/- 31 delay -14 +/- 0
ptp4l[5374021.736]: rms 273 max 450 freq -35984 +/- 97 delay -14 +/- 0
ptp4l[5374022.736]: rms 50 max 82 freq -36271 +/- 64 delay -14 +/- 0
ptp4l[5374023.736]: rms 81 max 86 freq -36413 +/- 17 delay -14 +/- 0

phc2sys[5374168.545]: CLOCK_REALTIME phc offset -372582 s0 freq +246 delay 6649
phc2sys[5374169.545]: CLOCK_REALTIME phc offset -372832 s1 freq -4 delay 6673
phc2sys[5374170.547]: CLOCK_REALTIME phc offset 68 s2 freq +64 delay 6640
phc2sys[5374171.547]: CLOCK_REALTIME phc offset -20 s2 freq -3 delay 6687
phc2sys[5374172.547]: CLOCK_REALTIME phc offset 47 s2 freq +58 delay 6619
phc2sys[5374173.548]: CLOCK_REALTIME phc offset -40 s2 freq -15 delay 6680

Oma kone RT Linuxilla pääsee konsistentisti PTP Grandmasterini kanssa tuollaiseen n. 30-50 ns konsensukseen, hieman huonelämpötilasta riippuen. Kuitenkin reilusti alle mikrosekunnin.

edit. ja konsensus ei ole sama asia kuin tarkkuus. PTP synkronoi molemmat samansuuntaisesti pieleen. Grandmasterin tarkkuus taas riippuu monesta asiasta, mutta kolmitaajuus GNSS:nä se on kuitenkin suhteellisen tarkka. Ei kuitenkaan mikään varsinainen referenssi.

 

[kotte]

Mitä tuo on, jos ei silkkoa NTP:tä?

Yksinkertaistettu versio ntp:n perusperiaatteesta: lähetetään kaiku ja arvioidaan viive (2 x kulunut aika). Ilman ennakkoon kerättyjä kattavampia ntp-palvelintilastoja tuo on entistä enemmän arvailua, eli useamman ntp-palvelimen tilatollinen seuraaminen on välttämätöntä, jotta paikallinen kello (tai usemapi sellainen) on mahdollista "rukata" pitämään aikaa mahdollisimman tarkasti. Käytännössähän tarkan ajanpito perustuu aina keskenään algoritmisesti toisiina synkronoituihin eri tarkkuuteen pystyviin aikanormaaleihin, joista epätarkempia tarkennetaan ("rukataan") tilastollisesti todettujen poikkeamien perusteella. Kiinteää vaihe-eroa ei kuitenkaan pysty kokonaan poistamaan, koska välisen informaatiokanavan viivettä ei pysty täysin ennustamaan tai kompensoimaan.

PTP:llä nämä ovat nanosekunteja, ja oikeita lukuja, eivät hanska-arvioita kuten NTP:llä:

Ilman muuta ptp (tai pntp) pystyvät paljon parempaan tarkkuuteen (LAN-ympäristössä), mutta käyttötilanteessa, kun aika välittyy WAN-perustaisen yhteyden kautta ei monia epävarmuustekijöitä yksinkertaisesti ole mahdollista elimonoida kuin osittain ja oikeastaan ei liene juuri muuta mahdollisuutta kuin käyttää tilastollista analyysia suureen joukkoon palvelimia, joiden käytöksen johdonmukaisuutta (pitkälti tuntemattoman välisen verkkoyhteyden päässä) tarkkaillaan tailstollisesti. Tuotahan ntp yrittää juuri tehdä.

Tarkka kellojen synkronointi edellyttää välissä olevan varsin tarkasti ennustettavaa signaalin etenemistietä (jollainen voi olla dedikoitu kuitu tai suora radiokanava Omegan tai GNSS-satelliitin tyyliin). Myös absoluuttinen aikaero on lisäksi mahdollista ennnustaa esimerkiksi pituudeltaan tarkasti tunnettua kuitua pitkin tai useamman GNSS-satelliitin välityksellä, jolloin etäisyystiedoista ja rata-aikatauluista on mahdollista laskea radiosignaalin absoluuttisen etenemisviiveen odotusarvo (jopa kullekin vastaanotetulle satelliittisignaalille erikseen tilastollisen luotettavuuden lisäämiseksi).

 

[Harrastelija]

Voisi ehkä lisätä että it laitteiden omat kellot/oskillaattorit ovat huonoja. Jos ptp tms yhteys menetetään niin hetkessä esim PC oma kello lähtee huiteleen omia aikojaan. Toki pitää suhteuttaa tarpeeseen että onko iso heitto minuutin, sekunnin, ms tai jopa ns luokassa.
Eli vaaditaan koko ajan synkronoinnin ylläpitoa jotta PC:n kello pysyy tahdissaan.

Yleensä jos vaaditaan parempaa paikallista tarkkuutta osillaattori on jossain vakiolämpötilassa ”uunissa” yms. PC:t pyritään kuitenkin tekemään niin halvalla ettei sinne mitään kalliimpaa komponenttia laiteta. Ei edes servereissä ole.

On olemassa esim verkkokortteja joista löytyy PHC. Eivät ole hinnat alkaen malleja.

Ja pitää erottaa että kellonaika ja synkronointi ovat hieman eri asioita. Tarkka kellonaika vaatii kylläkin tarkan synkronoinnin.

 

[anders]

Yksinkertaistettu versio ntp:n perusperiaatteesta: lähetetään kaiku ja arvioidaan viive (2 x kulunut aika). Ilman ennakkoon kerättyjä kattavampia ntp-palvelintilastoja tuo on entistä enemmän arvailua, eli useamman ntp-palvelimen tilatollinen seuraaminen on välttämätöntä, jotta paikallinen kello (tai usemapi sellainen) on mahdollista "rukata" pitämään aikaa mahdollisimman tarkasti. Käytännössähän tarkan ajanpito perustuu aina keskenään algoritmisesti toisiina synkronoituihin eri tarkkuuteen pystyviin aikanormaaleihin, joista epätarkempia tarkennetaan ("rukataan") tilastollisesti todettujen poikkeamien perusteella. Kiinteää vaihe-eroa ei kuitenkaan pysty kokonaan poistamaan, koska välisen informaatiokanavan viivettä ei pysty täysin ennustamaan tai kompensoimaan.

Mutta tämä menee varsinaisen NTP:n, network time protocol, skoopin ulkopuolelle?

Samalla tavalla vaihetta ja taajuutta rukataan PTP ja GNSS synkronoinnissa, tarkemmin vain.

Pointti ja argumentti oli, että mainittu ntpdate juttelee 100% rfc 5905 mukaista NTP:tä. Kuinka se muuten edes voisi toimia, edes teoriassa?

Ilman muuta ptp (tai pntp) pystyvät paljon parempaan tarkkuuteen (LAN-ympäristössä), mutta käyttötilanteessa, kun aika välittyy WAN-perustaisen yhteyden kautta ei monia epävarmuustekijöitä yksinkertaisesti ole mahdollista elimonoida kuin osittain ja oikeastaan ei liene juuri muuta mahdollisuutta kuin käyttää tilastollista analyysia suureen joukkoon palvelimia, joiden käytöksen johdonmukaisuutta (pitkälti tuntemattoman välisen verkkoyhteyden päässä) tarkkaillaan tailstollisesti. Tuotahan ntp yrittää juuri tehdä.

Nimenomaan NTP on WAN käytössä oikea työkalu.

Se ei vaan ole kovin tarkka, ja LAN käytössä on parempiakin. Jopa SW pohjainen PTP lyö sen 6-0, tarkkuudessa, ja ennen kaikkea deterministisuudessa.

Tarkka kellojen synkronointi edellyttää välissä olevan varsin tarkasti ennustettavaa signaalin etenemistietä (jollainen voi olla dedikoitu kuitu tai suora radiokanava Omegan tai GNSS-satelliitin tyyliin). Myös absoluuttinen aikaero on lisäksi mahdollista ennnustaa esimerkiksi pituudeltaan tarkasti tunnettua kuitua pitkin tai useamman GNSS-satelliitin välityksellä, jolloin etäisyystiedoista ja rata-aikatauluista on mahdollista laskea radiosignaalin absoluuttisen etenemisviiveen odotusarvo (jopa kullekin vastaanotetulle satelliittisignaalille erikseen tilastollisen luotettavuuden lisäämiseksi).

Aivan. Siksi GNSS -aika hakkaa muut mennen tullen, paitsi paikallisen tarkan (rubidium tai h-maser tms, jopa tarkka tuplauunikide) referenssin.

Sitten mennään jo Allen kuvaajan puolelle, jos puhutaan milloin ja millä tarkastelujaksolla GNSS vs vaikka paikallinen tarkka kello on tarkempi.

 

[kotte]

Mutta tämä menee varsinaisen NTP:n, network time protocol, skoopin ulkopuolelle?

Omasta mielestäni noihin protokolliin kuuluvat myös palvelut, joista protokollat ovat osa. Toki jokin TCP tai UDP on protokolla, mutta ei kovin hyödyllinen ilman palveluita, joihin tuolla yhdistetään. NTP pelkkänä protokollana on varsin yksinkertainen sovellus UDP:n päälle liimattuna ilman palveluita, joita se tukee tai joihin se tukeutuu.

Nimenomaan NTP on WAN käytössä oikea työkalu.

Se ei vaan ole kovin tarkka, ja LAN käytössä on parempiakin. Jopa SW pohjainen PTP lyö sen 6-0, tarkkuudessa, ja ennen kaikkea deterministisuudessa.

Noin, on, eli NTP ei yritä mallintaa tiedonvälitykseen liittyviä osia, joista on mahdotonta saada tarkkaa tietoa ja siten mallintaakaan tarkasti. PTP lähtee ajatuksesta, että toimitaankin ympäristössä, missä kaikki on periaatteessa mahdollista mallintaa ja mallinnetaan riittävästi, kun kaikki on periaatteessa omassa hallinnassa. Erikoisesti tuetut käyttöjärjestelmäympäristöt ja prosessoriarkkitehtuurit tunnetaan riittävän tarkasti ohjelmistopohjaisen kellon ylläpitämiseksi (mitä varten tuettuihin käyttöjärjestelmäympäristöihin on järjestetty erikoinen tuki).

Siksi GNSS -aika hakkaa muut mennen tullen, paitsi paikallisen tarkan (rubidium tai h-maser tms, jopa tarkka tuplauunikide) referenssin.omassa hallinnassa. Lisäksi tunnetaan alustana olevan tietokoneen arkkitehtuuri ja käyttöjärjestelmä sen verran yksityiskohtaisesti, että tiedetään ohjelmistopohaisen kellon mahdollisuudet ja rajat melko tarkkaan (ja lisäksi käyttöjärjestelmän kello-osuus tunnetaan ja tiedetään tarkoitusta varten toteutetuksi)

Noin on, mutta tuohon voisi vielä lisätä, että GNSS-systeemin kello luottaa maailmanaikaan, jota puolestaan pidetään yllä hajautetusti. Joukko vakiintuneen näytön perusteella tunnustettuja aikalaboratoirioita koordinoi keskenään mainitun kaltaisia kaikkein tarkimpia atomi- tms. kellojaan ja valvoo toistensa suorituskykyä. GNSS-operaattorit sen jälkeen synkronoivat omia master-kellojaan tuohon huippulaboratorioiden yhteisesti ylläpitämään maailmanaikaan.

 

[anders]

Omasta mielestäni noihin protokolliin kuuluvat myös palvelut, joista protokollat ovat osa. Toki jokin TCP tai UDP on protokolla, mutta ei kovin hyödyllinen ilman palveluita, joihin tuolla yhdistetään. NTP pelkkänä protokollana on varsin yksinkertainen sovellus UDP:n päälle liimattuna ilman palveluita, joita se tukee tai joihin se tukeutuu.

Mutta NTP on kuitenkin se protokolla, ei implementaatio.

Implementaatioita Linuxissa on esim ntpd, chrony, systemd ja mainittu ntpdate. Kaikilla eronsa ja vahvuutensa.

Puhut nyt varmaan ntpd:stä, joka ei kuitenkaan ole ntp:n synonyymi.

Noin, on, eli NTP ei yritä mallintaa tiedonvälitykseen liittyviä osia, joista on mahdotonta saada tarkkaa tietoa ja siten mallintaakaan tarkasti. PTP lähtee ajatuksesta, että toimitaankin ympäristössä, missä kaikki on periaatteessa mahdollista mallintaa ja mallinnetaan riittävästi, kun kaikki on periaatteessa omassa hallinnassa. Erikoisesti tuetut käyttöjärjestelmäympäristöt ja prosessoriarkkitehtuurit tunnetaan riittävän tarkasti ohjelmistopohjaisen kellon ylläpitämiseksi (mitä varten tuettuihin käyttöjärjestelmäympäristöihin on järjestetty erikoinen tuki).

Toki PTP tukeutuu pääosin hw-kelloon, ei ohjelmistopohjaiseen.

 

[kotte]

Toki PTP tukeutuu pääosin hw-kelloon, ei ohjelmistopohjaiseen.

Yleistietokoneella tosiaan on rajoituksensa tarkkuuskellon simuloijana. Ntp/ntpd-tuoteperheistä ja siihen liittyvistä apuohjelmista sekä suhteesta ptp-protokolliin ja tuotteisiin lienee vaihdettu jo näkemyksiä riittävästi. Vetäköön mahdollinen lukija itse omat näkemyksensä näistä ja omasta puolestani jätän mahdollisen käsitteidenkin oikeellisuuspainotuksen tälle, jos asian tähdelliseksi näkee.

 

[fraatti]

Kelloa sitä tarvitaan tähänkin

Ultravakaa kellosignaali auttaa tunnistamaan GPS-häirinnän​

Ultravakaa kellosignaali auttaa tunnistamaan GPS-häirinnän

etn.fi

 

[fraatti]

Suomalainen kello rikkoi tarkkuusennätyksen – Sekunnin uusi määritelmä nyt askeleen lähempänä​

VTT Mikesin tutkimusryhmä kehitti luotettavan optisen kellon, jolla on poikkeuksellisen pieni systemaattinen epävarmuus.

Suomalainen kello rikkoi tarkkuusennätyksen – Sekunnin uusi määritelmä nyt askeleen lähempänä

VTT Mikesin tutkimusryhmä kehitti luotettavan optisen kellon, jolla on poikkeuksellisen pieni systemaattinen epävarmuus.

www.tekniikkatalous.fi