Projekti: Stratum 1 NTP-palvelin (GNSS, Raspberry Pi)

[jase]

TLDR; GPS-kelloihn synkronoitu NTP-palvelin Rasperry Pi:llä, ei ehkä originellein projekti.

Pikku puuhastelut vähän eskaloitui ja tilasin Aliexpressistä "lautasantennin" ja Mikroe:ltä u-blox NEO-M9N GNSS-vastaanottimen. Kaapin pohjalta löytyi og Raspberry Pi 1 Model B, joka sai luvan toimittaa palvelimen virkaa. Koko komeus sitten PoE-splitterin kanssa IP65 asennuskoteloon. Kirjoitushetkellä homma on vielä testaus ja validointi -vaiheessa, eli työpöydän nurkalla, mutta loppusijoituspaikka tulee olemaan kylmässä varastossa ja antenni pääsee katolle maston nokkaan.

Näistäkin asemista antenni näkee 22 satelliittia

NTP-verrokki
Aluksi konffasin Chronyn käyttämään Mikesin NTP-palvelimia, Chronystä taas datat Telegrafilla InfluxDB:hen, josta niitä voi Grafanalla analysoida. Tällä perus netin yli NTP -setupilla päästiin Chronyn mukaan noin 19us poikkeamaan ja hajontaa oli 213us. Tämä vastaa aika hyvin muita laitteita, joissa minulla on jo sama konffi pyörimässä. Raspberry Pi ei olekaan ihan surkea, mikä on jo itsessään yllätys.

PPS synkronointi
GNSS-moduuli UARTilla kiinni ja PPS-signaali GPIO-pinniin. GPSD osaa kaivaa nyt sarjaporttiin tulevasta NMEA-datasta päivämäärän ja tasasekunnit tahdistetaan PPS (pulse per second) signaaliin jonka U-blox generoi. Tässä meidän täytynee vain luottaa siihen että U-blox osaa asiansa ja PPS signaali on tosiaankin hyvin lähellä satelliittien kelloa. Tuloksena vaatimattomat tuhat kertaa tarkempi kello, poikkeama on enää vain 12ns, mutta hajonta pysyy varsin isona. Tämähän todennäköisesti aiheutuu Raspberry Pin CPU kuormasta, 700MHz ARM ei mahdottomiin pysty. Tätä ehkä voisi parantaa kääntämällä kernelin sopivammilla asetuksilla, mutta se jäänee toistaiseksi tekemättä.

Ylikellotus, piitahnaa kovalevyn väliin
Peruspalikat kun saatiin toimimaan niin sitten vähän optimoimaan. U-bloxin manuaalista löytyi iso läjä konfiguroitavaa. Esimerkiksi laitteen sisäisen navigaatiotilan saa asetettua stationaryksi eli satelliittidataa analysoidaan sillä olettamalla, että antenni pysyy kokoajan paikallaan. Tällä ei varsinaisesti ole vaikutusta kelloon, mutta sijannin paikkavirhe puolittui noin +- 1.5 metrin luokkaan. Jännemmät asetuksen löytyivät sitten PPS:n asetuksista, josta sen taajuutta pystyy nostamaan. Kokeilin ensin 10 Hz:ä ja se vähensi hajontaa merkittävästi, nostinkin pian taajuutta 32 Hz:iin. Nyt poikkeamaa on keskimäärin 11ns ja hajonta alle 700ns, eli kokoajan pysytään mikrosekunnin sisällä.

Sijannin hajontaa 24h aikana

Parannettavaa
Jotta tästä voisi merkittävästi parantaa pitäisi ainakin Raspberry vaihtaa johonkin toiseen. Ilmeisesti kaikki Raspit pois lukien CM4 ja 5 eivät tue hardware timestampingia verkkopiirissä, jolla saisi (ilmeisesti) hajontaa vähennettyä sitten kun kelloa rupeaa tarjoamaan lähiverkon muillekin laitteille. Chronyn esimerkkisivulla oli käytetty Intelin i210 verkkokortin GPIO pinniä PPS-signaalin seuraamiseen, tällöin jokainen pulssi aikaleimataan ja kun se lopulta käsitellään prosessorilla voidaan vähentää matkalla tapahtuneet viiveet. Näin päästään +-20ns hajontaan.

Onkos muilla BBS:läisillä GNSS tai rubidium-synkronoituja NTP-palvelimia? Minkälaisiin tarkkuuksiin olette päässet?

 

[zepi]

Linux kerneliin voisi kääntää mukaan jotain realtime-patsejä, saisiko latensseja alaspäin? En tiedä miten nuo saa raspille jonkun normidistron kylkeen mutta ainakin geneeriselle armille jollain linux from scratch-tyylisellä jutulla voisi onnistua.

 

[jase]

Linux kerneliin voisi kääntää mukaan jotain realtime-patsejä, saisiko latensseja alaspäin? En tiedä miten nuo saa raspille jonkun normidistron kylkeen mutta ainakin geneeriselle armille jollain linux from scratch-tyylisellä jutulla voisi onnistua.

Joo tuosta NO_HZ optiosta oli siellä täällä mainintoja, sitä voisi kokeilla tai ainakin tarkistaa mikä asetus siellä oletuksena on. Tuo Raspberry Os:n kernelihän on kohtuu helppo ristikääntää PC:llä. Kertaalleen sen jo tein kun tappelin RTC:n kanssa, lopulta ihan turhaan.

Raspberry Pi Documentation - The Linux kernel

The official documentation for Raspberry Pi computers and microcontrollers

www.raspberrypi.com

 

[jase]

No niin, kernelin asetuksia vähän tunkkasin:

• Dynticks (aka NO_HZ) pois
• Preemption Model: No Forced Preemption (Server)
• Timer Interrupt Frequency 100Hz -> 1000Hz
• CPU frequency scaling pois, ei se RPi1 sitä tainnut oikein tukeakaan
• RTC UIE emulation on dev interface, jotta pystyy Chronyllä seuraamaan RTC:n driftiä

Spoileri: Kernel config diff

32c32
< CONFIG_LOCALVERSION=""
---
> CONFIG_LOCALVERSION="-jitter-hacks"
84c84
< CONFIG_NO_HZ=y
---
> # CONFIG_NO_HZ is not set
100,102c100,102
< CONFIG_PREEMPT_VOLUNTARY_BUILD=y
< # CONFIG_PREEMPT_NONE is not set
< CONFIG_PREEMPT_VOLUNTARY=y
---
> CONFIG_PREEMPT_NONE_BUILD=y
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT_VOLUNTARY is not set
110c110
< # CONFIG_IRQ_TIME_ACCOUNTING is not set
---
> CONFIG_IRQ_TIME_ACCOUNTING=y
363c363
< CONFIG_HZ_100=y
---
> # CONFIG_HZ_100 is not set
368,369c368,369
< # CONFIG_HZ_1000 is not set
< CONFIG_HZ=100
---
> CONFIG_HZ_1000=y
> CONFIG_HZ=1000
414,434c414
< CONFIG_CPU_FREQ=y
< CONFIG_CPU_FREQ_GOV_ATTR_SET=y
< CONFIG_CPU_FREQ_GOV_COMMON=y
< CONFIG_CPU_FREQ_STAT=y
< # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
< CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y
< # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
< # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
< # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
< CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
< CONFIG_CPU_FREQ_GOV_POWERSAVE=y
< CONFIG_CPU_FREQ_GOV_USERSPACE=y
< CONFIG_CPU_FREQ_GOV_ONDEMAND=y
< CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
< 
< #
< # CPU frequency scaling drivers
< #
< CONFIG_CPUFREQ_DT=y
< CONFIG_CPUFREQ_DT_PLATDEV=y
< CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
---
> # CONFIG_CPU_FREQ is not set
5730c5710
< # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
---
> CONFIG_RTC_INTF_DEV_UIE_EMUL=y
6785d6764
< CONFIG_PM_OPP=y

Näkeehän se jo silmällä että parani.

• System time: -10.4 ns -> -6.3 ns
• RMS offset: 103ns -> 85 ns

Varmaan tuo NO_HZ oli se mistä suurin muutos tuli, siitä kun oli muuallakin puhetta.

Tämän osalta alkaa olemaan homma paketissa. Seuraavaksi voisi laittaa lähiverkon laitteet käyttämään tuota, katsotaan tuleeko siitä merkittävää CPU kuormaa, joka pilaisi hienot käppyrät.