Budowa Lokalnego Serwera NTP z GPS

Bartosz Maciejewski do budowy swojego serwera NTP wybrał FC-NTP-MINI z AliExpress. Kompaktowe chińskie pudełko z anteną GPS, które oferuje znacznie więcej niż podstawową synchronizację czasu.
Specyfikacja Techniczna
Wsparcie Multi-GNSS:
- GPS L1 (standard amerykański)
- Beidou B1 (chińska nawigacja satelitarna)
- GLONASS L1 (rosyjski system pozycjonowania)
- QZSS L1 (japoński system regionalny)
Parametry Wydajnościowe:
- 6000 zapytań na sekundę (obsługa na poziomie enterprise!)
- Dokładność 100ns (0,0000001 sekund precyzji)
- Dokładność synchronizacji LAN: 0,5-2ms
- Pobór mocy: zaledwie 1W
- Zasilanie: DC 12V
- Zakres temperatur: -40°C do +85°C
- Rozmiar: 80 x 23,8 x 90 mm (wielkość paczki papierosów!)
Dodatowe Funkcje:
- Interfejs webowy do konfiguracji i monitoringu
- Uwierzytelnianie MD5 dla bezpiecznej dystrybucji czasu
- Wyjście NMEA0183 przez TCP (surowe dane GPS)
- Tryb BROADCAST dla efektywnej dystrybucji czasu
Konfiguracja i Pierwsze Wrażenia
Po podłączeniu do domyślnego IP (192.168.0.100), witamy się z czystym interfejsem bez zbędnych funkcji.
Status GNSS pokazuje:
Receiver: Antenna OK
Constellations in use: GPS+BeiDou+GLONASS
SVs Used: 15
GPS (używane/widoczne): 9/11
BeiDou (używane/widoczne): 3/3
GLONASS (używane/widoczne): 3/5
Migracja z ntpd do chrony
Po rozległych testach, autor przemigrował wszystkie systemy z tradycyjnego ntpd na chrony. Powody:
- Lepsza dokładność w środowiskach wirtualnych
- Szybsza synchronizacja po rozruchu
- Lepsze radzenie sobie z przerywanym połączeniem
- Przewidywalne zachowanie step/slew
Przykładowa Konfiguracja chrony.conf
# Plik dryfu zegara
driftfile /var/lib/chrony/drift
# Synchronizacja RTC z czasem systemowym
rtcsync
# FC-NTP-MINI - Lokalny serwer GPS NTP (najwyższy priorytet)
server 10.1.78.169 iburst prefer
# Zewnętrzne serwery NTP (backup)
server tempus1.gum.gov.pl iburst
server tempus2.gum.gov.pl iburst
server 0.pl.pool.ntp.org iburst
# Pozwól klientom LAN używać tego serwera NTP
allow 10.1.78.0/24
# Jeśli przesunięcie > 1 sekunda - popraw natychmiast
makestep 1.0 -1
maxupdateskew 100.0
minsamples 6
maxsamples 10
local stratum 10
Wyniki: Dramatyczna Poprawa Dokładności
Przed Dodaniem Lokalnego GPS (tylko źródła internetowe)
$ chronyc tracking
Reference ID : C292FB64 (tempus1.gum.gov.pl)
Stratum : 2
System time : 0.000000695 seconds slow of NTP time
Last offset : +0.007955262 seconds
RMS offset : 0.002647618 seconds
Root delay : 0.008763653 seconds
Dokładność: ~5-6ms
Po Dodaniu Lokalnego GPS
$ chronyc tracking
Reference ID : 0A014EA9 (FC-NTP-MINI)
Stratum : 2
System time : 0.000000009 seconds fast of NTP time
Last offset : +0.000287045 seconds
Root delay : 0.000140594 seconds
Poprawa jest oszałamiająca! Przeszliśmy z dokładności ~5-6 milisekund do zaledwie 82 mikrosekund. To ponad 60-krotna poprawa dokładności!
$ chronyc sources -v
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* FC-NTP-MINI 1 6 17 52 +3281ns[ +290us] +/- 82us
^- tempus1.gum.gov.pl 1 6 17 51 -1736us[-1736us] +/- 5537us
^- tempus2.gum.gov.pl 1 6 17 52 -2432us[-2145us] +/- 6156us
FC-NTP-MINI jest teraz oznaczony gwiazdką (*), wskazując, że to główne źródło czasu, podczas gdy serwery internetowe stały się backupem.
Strategie haszowania dla przetwarzania pakietów

Koncepcja haszowania jest prosta — funkcja haszująca zamienia klucz (np. adres IP) na wartość liczbową, która następnie służy jako indeks w tablicy. Dzięki spłaszczeniu dużej przestrzeni kluczy do mniejszej tablicy haszującej, wyszukiwanie rekordów staje się szybką operacją dostępu do tablicy.
Jednak wraz ze wzrostem zbioru danych pojawiają się wyzwania, takie jak kolizje (gdy różne klucze są mapowane na ten sam indeks) i zapełnianie tablicy. Dlatego opracowano szereg strategii i technik przeznaczonych do efektywnego radzenia sobie z tego rodzaju sytuacjami.
Jedną z podstawowych technik rozwiązywania kolizji jest łańcuchowanie, w którym wszystkie rekordy przypisane do tego samego indeksu są umieszczane w łańcuchu (zwykle w postaci listy połączonej). Nowe rekordy są dodawane na końcu każdego łańcucha, ułatwiając operacje wstawiania, ale potencjalnie spowalniając wyszukiwanie przy głębokich łańcuchach.
Jedną z ciekawszych technik haszowania, zwłaszcza w kontekście sprzętu sieciowego, jest cuckoo hashing. W tej metodzie każdy klucz ma dwie możliwe lokalizacje w dwóch oddzielnych tablicach. Podczas wstawiania klucz jest umieszczany w swojej głównej lokalizacji, o ile jest wolna. W przeciwnym razie klucz podmieniany jest z kluczem zajmującym tę lokalizację, który jest następnie próbowany w swojej alternatywnej lokacji. Ten proces migracji może utworzyć łańcuch przemieszczeń, ale w praktyce są one krótkie.
Wielką zaletą cuckoo hashingu jest zapewnienie stałego czasu wyszukiwania w najgorszym przypadku. Gdy szukany jest dany klucz, sprawdzane są tylko dwie lokalizacje (po jednej w każdej tablicy), co umożliwia wydajną realizację w sprzęcie sieciowym.
Oprócz zapewniania szybkich wyszukiwań, ważnym wymaganiem dla haszowania w sieciach jest ograniczenie zajmowanej pamięci. Filtry Blooma są jedną z technik służących temu celowi — pozwalają one szybko stwierdzić, czy dany rekord nie znajduje się w zbiorze, eliminując potrzebę szukania go w głównej strukturze danych.
W sprzęcie sieciowym techniki haszowania są często wdrażane z wykorzystaniem otwartego adresowania z ograniczoną pojemnością wiaderka. Każde wiadro/wiersz może pomieścić z góry określoną liczbę wpisów (np. 4), co pozwala na równoległe sprawdzanie tych lokalizacji pamięci w pojedynczym cyklu zegara.
Inna powszechna strategia to haszowanie wielokrotne (d-way lub d-left), gdzie zamiast jednej funkcji haszującej wykorzystywanych jest kilka, dając każdemu kluczowi zbiór potencjalnych lokalizacji. Umożliwia to sprawdzanie wszystkich kandydujących pozycji w ramach kilku równoległych operacji dostępu do pamięci.
Ostatnim przykładem są implementacje potokowe i równoległe. W architekturach ASIC operacje haszowania są rozdzielane na etapy potoku, a obliczenia i dostępy do pamięci są replikowane w celu obsługi wielu pakietów jednocześnie.
Podstawy CI/CD w Gitlab
Przewodnik pokazujący, jak skonfigurować GitLab Runnera oraz stworzyć podstawową pipeline CI/CD. Materiał wyjaśnia krok po kroku instalację i konfigurację, a także przedstawia przykładowy plik .gitlab-ci.yml. Idealny dla osób zaczynających przygodę z automatyzacją procesów w GitLabie.
Przeglądaj API w terminalu
Openapi-tui to terminalowy interfejs użytkownika umożliwiający przeglądanie, eksplorowanie i uruchamianie API zgodnych ze specyfikacją OpenAPI v3.0 i v3.1. Dzięki temu narzędziu łatwo porównasz różne API, sprawdzisz dostępne endpointy, wykonasz zapytania oraz przeglądniesz historię wywołań – wszystko bez opuszczania terminala. openapi-tui wspiera też zaawansowane funkcje, takie jak filtrowanie, obsługa webhooków, wiele serwerów oraz możliwość importu i zapisu zapytań i odpowiedzi.
Szablony Jinja2 i role w Ansible
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj