Adaugare Disk: Difference between revisions
No edit summary Tag: Reverted |
No edit summary Tag: Reverted |
||
| Line 1: | Line 1: | ||
== Configurarea Raspberry Pi ca server NTP folosint NEO-7M == | == Configurarea Raspberry Pi ca server NTP folosint NEO-7M == | ||
Un server NTP asigura sincronizarea corecta a orei pentru toate dispozitivele dintr-o retea, prevenind erori in loguri, autentificari sau servicii care depind de timp precis. Folosind un modul GPS cu PPS, un Raspberry Pi poate deveni o sursa Stratum‑1 foarte stabila | Un server NTP asigura sincronizarea corecta a orei pentru toate dispozitivele dintr-o retea, prevenind erori in loguri, autentificari sau servicii care depind de timp precis. Folosind un modul GPS cu PPS, un Raspberry Pi poate deveni o sursa Stratum‑1 foarte stabila si independenta de internet. Acest proiect prezinta configurarea unui astfel de server NTP simplu si fiabil pentru uz local. | ||
=== Configurare UART | === Configurare UART si activare PPS === | ||
Pe Raspberry Pi, consola seriala este activa implicit, ceea ce blocheaza utilizarea interfetei UART pentru modulul GPS. Pentru a putea folosi portul serial | Pe Raspberry Pi, consola seriala este activa implicit, ceea ce blocheaza utilizarea interfetei UART pentru modulul GPS. Pentru a putea folosi portul serial si semnalul PPS, este necesara dezactivarea consolei si activarea manuala a suportului UART si PPS. | ||
==== Dezactivarea consolei seriale ==== | ==== Dezactivarea consolei seriale ==== | ||
| Line 22: | Line 22: | ||
</code> | </code> | ||
==== Activarea modulului | ==== Activarea modulului PPS ==== | ||
Incarcam modulul PPS executand: | Incarcam modulul PPS executand: | ||
| Line 37: | Line 37: | ||
Aceasta indica kernelului ca semnalul PPS este conectat la GPIO 18. | Aceasta indica kernelului ca semnalul PPS este conectat la GPIO 18. | ||
Dupa ce efectuam aceste modificari, oprim | Dupa ce efectuam aceste modificari, oprim sistemul in vederea conectarii modului de GPS NEO-7M. | ||
=== Conectarea modului GPS === | === Conectarea modului GPS === | ||
Dupa dezactivarea consolei seriale | Dupa dezactivarea consolei seriale si activarea suportului PPS, interfata UART a Raspberry Pi devine libera pentru comunicarea cu modulul GPS. Conectarea se face direct pe pinii GPIO, folosind alimentarea de 5V, masa comuna si liniile de date RX/TX, plus semnalul PPS. | ||
==== Schema de conectare ==== | ==== Schema de conectare ==== | ||
[[File:GPIOtoGPS.jpg|800px|none|Pagina | [[File:GPIOtoGPS.jpg|800px|none|Pagina GPIOtoGPS]] | ||
* Conectam pinul de 5V al Raspberry Pi la pinul de alimentare al modulului GPS. | * Conectam pinul de 5V al Raspberry Pi la pinul de alimentare al modulului GPS. | ||
* Conectam GND la masa modulului GPS. | * Conectam GND la masa modulului GPS. | ||
* Conectam TX0 de pe Raspberry Pi la RX al modulului GPS (Pi transmite → GPS | * Conectam TX0 de pe Raspberry Pi la RX al modulului GPS (Pi transmite → GPS primeste). | ||
* Conectam RX0 de pe Raspberry Pi la TX al modulului GPS (GPS transmite → Pi | * Conectam RX0 de pe Raspberry Pi la TX al modulului GPS (GPS transmite → Pi primeste). | ||
* Conectam GPIO 18 la pinul PPS al modulului GPS, conform configurarii din config.txt | * Conectam GPIO 18 la pinul PPS al modulului GPS, conform configurarii din config.txt | ||
| Line 68: | Line 68: | ||
</code> | </code> | ||
Acest rezultat confirma faptul ca Pi-ul primeste date | Acest rezultat confirma faptul ca Pi-ul primeste date GPS de la modulul NEO-7M | ||
Daca totul este configurat corect, ar trebui sa apara siruri NMEA. In cazul in care nu apare asemenator mai sus, verificati conexiunile RX/TX si setarile UART. | Daca totul este configurat corect, ar trebui sa apara siruri NMEA. In cazul in care nu apare asemenator mai sus, verificati conexiunile RX/TX si setarile UART. | ||
| Line 100: | Line 100: | ||
  |   | ||
 START_DAEMON="true" |  START_DAEMON="true" | ||
 DEVICES="/dev/serial0 /dev/ |  DEVICES="/dev/serial0 /dev/pps0" | ||
 GPSD_OPTIONS="-n" |  GPSD_OPTIONS="-n" | ||
 USBAUTO="false" |  USBAUTO="false" | ||
| Line 112: | Line 112: | ||
* GPSD_OPTIONS -> Porneste gpsd chiar daca nu exista clienti conectati. Fara "-n", gpsd asteapta un client inainte sa initializeze modulul GPS. | * GPSD_OPTIONS -> Porneste gpsd chiar daca nu exista clienti conectati. Fara "-n", gpsd asteapta un client inainte sa initializeze modulul GPS. | ||
* USBAUTO -> Dezactiveaza detectarea automata a dispozitivelor GPS USB; necesar cand folosim un modul pe UART. | * USBAUTO -> Dezactiveaza detectarea automata a dispozitivelor GPS USB; necesar cand folosim un modul pe UART. | ||
* GPSD_SOCKET -> | * GPSD_SOCKET -> Defineste socket-ul UNIX prin care aplicatiile (cgps, chrony etc.) comunica cu gpsd. | ||
Repornim serviciul executand: | Repornim serviciul executand: | ||
| Line 168: | Line 168: | ||
===== refclock SHM (NMEA) ===== | ===== refclock SHM (NMEA) ===== | ||
NMEA este fluxul de timp citit din GPS prin gpsd | NMEA este fluxul de timp citit din GPS prin gpsd si expus catre Chrony printr-un segment SHM (shared memory). Acest semnal conhine ora completa, dar are o intarziere naturala de aproximativ 200 ms si o precizie relativ slaba. Îl folosim cu noselect pentru ca nu vrem ca NMEA sa fie sursa principala de timp; rolul lui este doar sa ofere context temporal pentru PPS, astfel incat impulsul PPS sa poata fi „legat” corect de ora GPS. | ||
===== refclock PPS ===== | ===== refclock PPS ===== | ||
PPS este semnalul hardware de precizie foarte mare (sub‑microsecunda), generat o data pe secunda de modulul GPS. Spre deosebire de NMEA, PPS nu conhine ora, ci doar impulsul exact, motiv pentru care il „blocam” pe GPS (lock GPS) pentru a-i oferi contextul temporal. Îl marcam ca prefer deoarece PPS trebuie sa fie sursa principala de sincronizare, fiind cea mai precisa | PPS este semnalul hardware de precizie foarte mare (sub‑microsecunda), generat o data pe secunda de modulul GPS. Spre deosebire de NMEA, PPS nu conhine ora, ci doar impulsul exact, motiv pentru care il „blocam” pe GPS (lock GPS) pentru a-i oferi contextul temporal. Îl marcam ca prefer deoarece PPS trebuie sa fie sursa principala de sincronizare, fiind cea mai precisa referinta disponibila. | ||
Dupa salvarea noii configuratii restartam chrony | Dupa salvarea noii configuratii restartam chrony | ||
| Line 189: | Line 189: | ||
==== Configurarea serverului pentru acces LAN ==== | ==== Configurarea serverului pentru acces LAN ==== | ||
Dupa ce serverul NTP | Dupa ce serverul NTP functioneaza corect pe GPS + PPS si a devenit stratum 1, urmatorul pas este sa il facem disponibil in reteaua locala. Practic, permitem dispozitivelor din LAN sa foloseasca acest server ca sursa principala de timp. Chrony nu raspunde implicit catre retea, asa ca trebuie sa activam explicit accesul pentru subnetul nostru. | ||
<code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | <code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | ||
| Line 197: | Line 197: | ||
</code> | </code> | ||
Dupa restart, Chrony asculta pe toate | Dupa restart, Chrony asculta pe toate interfetele pentru UDP 123, fiind gata sa raspunda clienhilor din LAN. | ||
<code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | <code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | ||
| Line 205: | Line 205: | ||
</code> | </code> | ||
Cu aceste setari, configurarea serverului NTP este completa. Sistemul | Cu aceste setari, configurarea serverului NTP este completa. Sistemul functioneaza acum ca un server stratum 1 bazat pe GPS + PPS, stabil, autonom si gata sa ofere timp precis intregii retele. Practic, in acest punct serverul este complet operational si pregatit sa serveasca LAN‑ul | ||
== Configurarea clientului NTP Ubuntu == | == Configurarea clientului NTP Ubuntu == | ||
Clientul NTP din | Clientul NTP din retea va folosi serverul nostru stratum 1 ca sursa principala de timp. Pe Ubuntu, Chrony este usor de configurat si poate inlocui rapid pool‑urile implicite cu serverul nostru local. | ||
==== Instalare Chrony ==== | ==== Instalare Chrony ==== | ||
| Line 218: | Line 218: | ||
==== Verificare stare initiala ==== | ==== Verificare stare initiala ==== | ||
Inainte de modificari, clientul | Inainte de modificari, clientul foloseste pool‑urile Ubuntu. | ||
<code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | <code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | ||
| Line 231: | Line 231: | ||
==== Editare configuratie Chrony ==== | ==== Editare configuratie Chrony ==== | ||
Pentru ca acest client sa foloseasca serverul nostru NTP din LAN, trebuie sa inlocuim pool‑urile implicite Ubuntu cu adresa serverului local. Configuratia este simpla: comentam sursa initiala | Pentru ca acest client sa foloseasca serverul nostru NTP din LAN, trebuie sa inlocuim pool‑urile implicite Ubuntu cu adresa serverului local. Configuratia este simpla: comentam sursa initiala si adaugam serverul nostru stratum 1. | ||
<code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | <code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | ||
| Line 248: | Line 248: | ||
==== Urmarirea sincronizarii ==== | ==== Urmarirea sincronizarii ==== | ||
Dupa restart, clientul nu se sincronizeaza instant; are nevoie de cateva interogari pentru a valida sursa | Dupa restart, clientul nu se sincronizeaza instant; are nevoie de cateva interogari pentru a valida sursa si a stabili offset‑ul. Folosim <b>watch</b> pentru a vedea in timp real cum trece de la starea initiala, nesincronizata, la sincronizarea completa cu serverul nostru. | ||
<code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | <code class="mw-code mw-highlight plainlinks" style="display:block"><!-- | ||
| Line 261: | Line 261: | ||
</code> | </code> | ||
În aceasta faza, clientul vede serverul, dar inca nu il | În aceasta faza, clientul vede serverul, dar inca nu il foloseste ca sursa activa. | ||
Asteptam in acest ecran pana cand apare sincronizarea completa — se vede clar momentul in care clientul „prinde” serverul nostru. | Asteptam in acest ecran pana cand apare sincronizarea completa — se vede clar momentul in care clientul „prinde” serverul nostru. | ||
| Line 278: | Line 278: | ||
== Concluzii == | == Concluzii == | ||
Pentru aceasta constructie am folosit un Raspberry Pi 1 deoarece ofera un consum de energie extrem de redus, zgomot electric minim | Pentru aceasta constructie am folosit un Raspberry Pi 1 deoarece ofera un consum de energie extrem de redus, zgomot electric minim si un mediu stabil, cu un singur nucleu. Aceste caracteristici il fac surprinzator de potrivit pentru sarcini de sincronizare a timpului, chiar daca modelele mai noi de Raspberry Pi ofera mai multa putere de procesare. | ||
Configuratia poate fi imbunatatita prin utilizarea unui Raspberry Pi echipat cu un HAT pentru SSD. Înlocuirea cardului micro‑SD elimina degradarea mediului de stocare | Configuratia poate fi imbunatatita prin utilizarea unui Raspberry Pi echipat cu un HAT pentru SSD. Înlocuirea cardului micro‑SD elimina degradarea mediului de stocare si asigura o performanta mai constanta pe termen lung. | ||
Precizia poate fi imbunatatita | Precizia poate fi imbunatatita si prin trecerea de la modulul NEO‑7M la un receptor dedicat pentru aplicatii de timing. Modulele din seria T sunt proiectate special pentru sincronizare si ofera un semnal PPS mai curat si mai stabil. | ||
Merita mentionat | Merita mentionat si faptul ca unele echipamente comerciale NTP sunt construite chiar pe hardware Raspberry Pi. Acest lucru face comparatia noastra si mai relevanta, deoarece platforma de baza este similara, iar diferentele de performanta provin in principal din alegerea componentelor si optimizarea firmware‑ului, nu din arhitecturi fundamental diferite. | ||
În comparatia cu echipamentele comerciale NTP, rezultatele au fost foarte apropiate. Unitatile dedicate au mentinut un jitter in jur de 0,2 milisecunde, in timp ce sistemul nostru a avut o medie intre 0,4 | În comparatia cu echipamentele comerciale NTP, rezultatele au fost foarte apropiate. Unitatile dedicate au mentinut un jitter in jur de 0,2 milisecunde, in timp ce sistemul nostru a avut o medie intre 0,4 si 0,6 milisecunde — valori care se incadreaza confortabil in limitele acceptabile pentru sincronizare. | ||
Și rezultatele privind capacitatea de procesare au fost similare. Echipamentele comerciale au gestionat aproximativ 20 pâna la 30 de mii de cereri NTP pe minut, in timp ce sistemul nostru a sustinut intre 15 | Și rezultatele privind capacitatea de procesare au fost similare. Echipamentele comerciale au gestionat aproximativ 20 pâna la 30 de mii de cereri NTP pe minut, in timp ce sistemul nostru a sustinut intre 15 si 18 mii, demonstrând ca o solutie cu cost redus poate atinge performante apropiate de cele ale unui appliance dedicat. | ||
Per ansamblu, acest proiect arata ca, prin alegeri hardware bine gândite | Per ansamblu, acest proiect arata ca, prin alegeri hardware bine gândite si o configurare corecta, un sistem compact si accesibil poate oferi o acuratete a timpului foarte apropiata de cea a echipamentelor NTP profesionale. | ||
Combinatia dintre Chrony | Combinatia dintre Chrony si PPS bazat pe GNSS ofera o sursa de timp stabila si predictibila, potrivita pentru o gama larga de aplicatii. | ||
Cu imbunatatiri incrementale, aceasta platforma poate fi rafinata | Cu imbunatatiri incrementale, aceasta platforma poate fi rafinata si mai mult si adaptata unor medii de sincronizare mai pretentioase. | ||
Revision as of 06:28, 21 February 2026
Configurarea Raspberry Pi ca server NTP folosint NEO-7M
Un server NTP asigura sincronizarea corecta a orei pentru toate dispozitivele dintr-o retea, prevenind erori in loguri, autentificari sau servicii care depind de timp precis. Folosind un modul GPS cu PPS, un Raspberry Pi poate deveni o sursa Stratum‑1 foarte stabila si independenta de internet. Acest proiect prezinta configurarea unui astfel de server NTP simplu si fiabil pentru uz local.
Configurare UART si activare PPS
Pe Raspberry Pi, consola seriala este activa implicit, ceea ce blocheaza utilizarea interfetei UART pentru modulul GPS. Pentru a putea folosi portul serial si semnalul PPS, este necesara dezactivarea consolei si activarea manuala a suportului UART si PPS.
Dezactivarea consolei seriale
Pentru dezactivarea consolei seriale editam fisierul /boot/firmware/cmdline.txt de unde stergem segmentul care contine consola, de obicei ceva de forma:
console=serial0,115200
Lasam restul liniei pe un singur rand, exact cum era.
Verificarea activarii UART
Editam fisierul /boot/firmware/config.txt unde ne asiguram ca exista:
[all]
enable_uart=1
Activarea modulului PPS
Incarcam modulul PPS executand:
echo 'pps-gpio' >> /etc/modules
Pentru configurarea pinului PPS (GPIO 18) editam din nou fisierul /boot/firmware/config.txt iar in partea de jos adaugam:
dtoverlay=pps-gpio,gpiopin=18
Aceasta indica kernelului ca semnalul PPS este conectat la GPIO 18.
Dupa ce efectuam aceste modificari, oprim sistemul in vederea conectarii modului de GPS NEO-7M.
Conectarea modului GPS
Dupa dezactivarea consolei seriale si activarea suportului PPS, interfata UART a Raspberry Pi devine libera pentru comunicarea cu modulul GPS. Conectarea se face direct pe pinii GPIO, folosind alimentarea de 5V, masa comuna si liniile de date RX/TX, plus semnalul PPS.
Schema de conectare

- Conectam pinul de 5V al Raspberry Pi la pinul de alimentare al modulului GPS.
- Conectam GND la masa modulului GPS.
- Conectam TX0 de pe Raspberry Pi la RX al modulului GPS (Pi transmite → GPS primeste).
- Conectam RX0 de pe Raspberry Pi la TX al modulului GPS (GPS transmite → Pi primeste).
- Conectam GPIO 18 la pinul PPS al modulului GPS, conform configurarii din config.txt
Test pentru UART si PPS
Dupa conectarea modulului GPS si configurarea UART/PPS, putem verifica functionarea celor doua interfete direct din sistem.
Test UART (NMEA)
Pentru a verifica daca modulul GPS transmite date NMEA prin UART:
cat /dev/serial0
to be added
to be added
to be added
Acest rezultat confirma faptul ca Pi-ul primeste date GPS de la modulul NEO-7M Daca totul este configurat corect, ar trebui sa apara siruri NMEA. In cazul in care nu apare asemenator mai sus, verificati conexiunile RX/TX si setarile UART.
Instalare unelte PPS si testare
Pentru testarea semnalului PPS, instalati pachetul necesar:
- apt install pps-tools
Dupa instalare, verificam semnalul PPS:
ppstest /dev/pps0
to be added
to be added
to be added
Un rezultat corect va afisa impulsuri detectate la fiecare secunda.
Configurare gpsd
Instalam pachetele necesare pentru gestionarea modulului GPS:
- apt install gpsd gpsd-clients
Startup config pentru gpsd
Editam fisierul de configurare gpsd:
# nano /etc/default/gpsd
START_DAEMON="true"
DEVICES="/dev/serial0 /dev/pps0"
GPSD_OPTIONS="-n"
USBAUTO="false"
GPSD_SOCKET="/var/run/gpsd.sock"
- START_DAEMON -> Porneste automat serviciul gpsd la boot. Daca este "false", gpsd nu se lanseaza singur.
- DEVICES -> Aceasta linie indica gpsd sa deschida doua dispozitive simultan
- /dev/serial0 → fluxul NMEA provenit de pe UART (datele GPS clasice: GGA, RMC, sateliti etc.)
- /dev/pps → semnalul PPS hardware folosit pentru sincronizare precisa la nivel de secunda
- GPSD_OPTIONS -> Porneste gpsd chiar daca nu exista clienti conectati. Fara "-n", gpsd asteapta un client inainte sa initializeze modulul GPS.
- USBAUTO -> Dezactiveaza detectarea automata a dispozitivelor GPS USB; necesar cand folosim un modul pe UART.
- GPSD_SOCKET -> Defineste socket-ul UNIX prin care aplicatiile (cgps, chrony etc.) comunica cu gpsd.
Repornim serviciul executand:
- service gpsd restart
Testare gpsd
Testam functionarea modulului GPS:
# cgps -s
to be added
Configurarea serverului NTP
Acest server foloseste un modul GPS cu suport PPS pentru a furniza timp de inalta precizie, transformand sistemul intr-o sursa NTP stratum 1. In pasii urmatori configuram Chrony astfel incat sa foloseasca exclusiv GPS si PPS ca referinte de timp.
Instalare Chrony
Inainte de instalare ne asiguram ca sistemul foloseste un singur serviciu NTP (Chrony va deveni sursa principala).
- apt install chrony
Verificarea surselor NTP initiale
# chronyc sources
to be added
# chronyc tracking
to be added
chronyc sources afiseaza sursele NTP publice pe care sistemul le foloseste implicit, inainte de configurarea GPS‑ului. chronyc tracking arata ca sistemul functioneaza momentan ca stratum 3, fiind doar un client NTP obisnuit.
Editare configuratie Chrony
In aceasta etapa eliminam sursele NTP publice si configuram Chrony sa foloseasca exclusiv GPS (NMEA) si PPS ca referinte de timp. Ajustam parametrii de corectie initiala si stabilim PPS ca sursa principala, astfel incat serverul sa poata functiona ca stratum 1. Rezultatul final este un server NTP autonom, sincronizat direct din semnal GPS cu precizie sub‑microsecunda.
# nano /etc/chrony/chrony.conf
#pool 2.debian.pool.ntp.org iburst
makestep 0.1 -1
initstepslew 1.0 GPS
# GPS serial time (NMEA)
refclock SHM 0 delay 0.2 refid GPS poll 4 noselect
# PPS precise time
refclock PPS /dev/pps0 refid PPS lock GPS poll 4 prefer
2.debian.pool.ntp.org este serverul NTP public folosit initial de catre chrony makestep permite corectii mari de timp atunci cand diferenta este prea mare pentru slew. Modificam din initialul "1.0 3" pentru a permite corectii oricand, cu limita mai mica. initstepslew corecteaza timpul la boot daca diferenta fata de GPS este mai mare de 1 secunda.
refclock SHM (NMEA)
NMEA este fluxul de timp citit din GPS prin gpsd si expus catre Chrony printr-un segment SHM (shared memory). Acest semnal conhine ora completa, dar are o intarziere naturala de aproximativ 200 ms si o precizie relativ slaba. Îl folosim cu noselect pentru ca nu vrem ca NMEA sa fie sursa principala de timp; rolul lui este doar sa ofere context temporal pentru PPS, astfel incat impulsul PPS sa poata fi „legat” corect de ora GPS.
refclock PPS
PPS este semnalul hardware de precizie foarte mare (sub‑microsecunda), generat o data pe secunda de modulul GPS. Spre deosebire de NMEA, PPS nu conhine ora, ci doar impulsul exact, motiv pentru care il „blocam” pe GPS (lock GPS) pentru a-i oferi contextul temporal. Îl marcam ca prefer deoarece PPS trebuie sa fie sursa principala de sincronizare, fiind cea mai precisa referinta disponibila.
Dupa salvarea noii configuratii restartam chrony
- service chrony restart
Verificarea surselor NTP adaugate
# chronyc sources
to be added
# chronyc tracking
to be added
Dupa aplicarea configuratiei, Chrony incepe sa renunte la sursele NTP publice si sa foloseasca exclusiv GPS si PPS. In primele secunde, chronyc sources poate arata doar GPS, iar PPS apare abia dupa ce semnalul devine stabil. Pe masura ce PPS este validat si blocat pe GPS, chronyc tracking trece automat de la stratum 3 la stratum 1, confirmand ca serverul functioneaza acum ca o sursa autonoma de timp de inalta precizie.
Configurarea serverului pentru acces LAN
Dupa ce serverul NTP functioneaza corect pe GPS + PPS si a devenit stratum 1, urmatorul pas este sa il facem disponibil in reteaua locala. Practic, permitem dispozitivelor din LAN sa foloseasca acest server ca sursa principala de timp. Chrony nu raspunde implicit catre retea, asa ca trebuie sa activam explicit accesul pentru subnetul nostru.
# nano /etc/chrony/chrony.conf
allow 192.168.1.0/24
Dupa restart, Chrony asculta pe toate interfetele pentru UDP 123, fiind gata sa raspunda clienhilor din LAN.
# netstat -tulnp
to be added
Cu aceste setari, configurarea serverului NTP este completa. Sistemul functioneaza acum ca un server stratum 1 bazat pe GPS + PPS, stabil, autonom si gata sa ofere timp precis intregii retele. Practic, in acest punct serverul este complet operational si pregatit sa serveasca LAN‑ul
Configurarea clientului NTP Ubuntu
Clientul NTP din retea va folosi serverul nostru stratum 1 ca sursa principala de timp. Pe Ubuntu, Chrony este usor de configurat si poate inlocui rapid pool‑urile implicite cu serverul nostru local.
Instalare Chrony
Instalam Chrony pe client pentru a putea sincroniza timpul cu serverul NTP din LAN.
# apt install chrony
Verificare stare initiala
Inainte de modificari, clientul foloseste pool‑urile Ubuntu.
# chronyc sources
to be added
# chronyc tracking
to be added
Editare configuratie Chrony
Pentru ca acest client sa foloseasca serverul nostru NTP din LAN, trebuie sa inlocuim pool‑urile implicite Ubuntu cu adresa serverului local. Configuratia este simpla: comentam sursa initiala si adaugam serverul nostru stratum 1.
# nano /etc/chrony/chrony.conf
#pool ntp.ubuntu.com iburst
#pool ntp.ubuntu.com iburst
#pool ntp.ubuntu.com iburst
#pool ntp.ubuntu.com iburst
server 192.168.1.23 iburst
Restartam chrony pentru aplicarea noilor configuratii
- service chrony restart
Urmarirea sincronizarii
Dupa restart, clientul nu se sincronizeaza instant; are nevoie de cateva interogari pentru a valida sursa si a stabili offset‑ul. Folosim watch pentru a vedea in timp real cum trece de la starea initiala, nesincronizata, la sincronizarea completa cu serverul nostru.
# watch -n1 "chronyc sources; echo; chronyc tracking"
to be added
to be added
to be added
to be added
to be added
to be added
În aceasta faza, clientul vede serverul, dar inca nu il foloseste ca sursa activa. Asteptam in acest ecran pana cand apare sincronizarea completa — se vede clar momentul in care clientul „prinde” serverul nostru.
# watch -n1 "chronyc sources; echo; chronyc tracking"
to be added
to be added
to be added
to be added
to be added
to be added
Acum chronyc sources arata serverul stratum 1 ca sursa selectata, iar chronyc tracking confirma ca acest client a devenit stratum 2.
Concluzii
Pentru aceasta constructie am folosit un Raspberry Pi 1 deoarece ofera un consum de energie extrem de redus, zgomot electric minim si un mediu stabil, cu un singur nucleu. Aceste caracteristici il fac surprinzator de potrivit pentru sarcini de sincronizare a timpului, chiar daca modelele mai noi de Raspberry Pi ofera mai multa putere de procesare.
Configuratia poate fi imbunatatita prin utilizarea unui Raspberry Pi echipat cu un HAT pentru SSD. Înlocuirea cardului micro‑SD elimina degradarea mediului de stocare si asigura o performanta mai constanta pe termen lung.
Precizia poate fi imbunatatita si prin trecerea de la modulul NEO‑7M la un receptor dedicat pentru aplicatii de timing. Modulele din seria T sunt proiectate special pentru sincronizare si ofera un semnal PPS mai curat si mai stabil.
Merita mentionat si faptul ca unele echipamente comerciale NTP sunt construite chiar pe hardware Raspberry Pi. Acest lucru face comparatia noastra si mai relevanta, deoarece platforma de baza este similara, iar diferentele de performanta provin in principal din alegerea componentelor si optimizarea firmware‑ului, nu din arhitecturi fundamental diferite.
În comparatia cu echipamentele comerciale NTP, rezultatele au fost foarte apropiate. Unitatile dedicate au mentinut un jitter in jur de 0,2 milisecunde, in timp ce sistemul nostru a avut o medie intre 0,4 si 0,6 milisecunde — valori care se incadreaza confortabil in limitele acceptabile pentru sincronizare.
Și rezultatele privind capacitatea de procesare au fost similare. Echipamentele comerciale au gestionat aproximativ 20 pâna la 30 de mii de cereri NTP pe minut, in timp ce sistemul nostru a sustinut intre 15 si 18 mii, demonstrând ca o solutie cu cost redus poate atinge performante apropiate de cele ale unui appliance dedicat.
Per ansamblu, acest proiect arata ca, prin alegeri hardware bine gândite si o configurare corecta, un sistem compact si accesibil poate oferi o acuratete a timpului foarte apropiata de cea a echipamentelor NTP profesionale.
Combinatia dintre Chrony si PPS bazat pe GNSS ofera o sursa de timp stabila si predictibila, potrivita pentru o gama larga de aplicatii. Cu imbunatatiri incrementale, aceasta platforma poate fi rafinata si mai mult si adaptata unor medii de sincronizare mai pretentioase.