PTP Grandmaster za 103 dolary
Malcolm Frazier
Komercyjne grandmastery PTP z synchronizacją GPS kosztują od kilku tysięcy dolarów wzwyż. Autor tego projektu zbudował funkcjonalny odpowiednik za 103 USD w nowych częściach, używając Raspberry Pi CM4 i modułu GPS SR1723U10.
Kluczowa obserwacja: PHY BCM54210PE w CM4 ma pełne wsparcie dla IEEE 1588v2 hardware timestamping. Timestamps powstają bezpośrednio w warstwie PHY, przed dotknięciem stosu sieciowego kernela. To eliminuje jitter wynikający z schedulingu i obsługi przerwań – i robi realną różnicę w wynikach.
Ukończony grandmaster osiąga średnio 6 ns odchylenia od czasu GPS (max 18 ns). Klienci PTP w tej samej sieci:
- CM4 z BCM54210PE: ±66 ns niepewności
- RK1 (Rockchip GMAC, timestamping na warstwie MAC): ±291 ns
Dla porównania – LAN NTP z tego samego grandmastera daje ±79–172 µs, a WAN NTP publiczne poole ±40–82 ms. Każda warstwa to mniej więcej 1000x gorsze wyniki.
Grandmaster podpięty do konsumenckiego routera TP-Link zamiast bezpośrednio do switcha Turing Pi: path delay skoczył z 2,6 µs do 480 µs, a offsety klientów wahały się w zakresie ±700 µs. To 180-krotna różnica tylko przez jeden dodatkowy hop przez software-owy routing. Jeśli wdrażasz PTP w środowisku produkcyjnym, hardware switch z sprzętowym forwarding to nie opcja – to wymóg.
Zanim zaczniesz bawić się tym stackiem (SatPulse + ptp4l + chrony), zapamiętaj dwa problemy nieudokumentowane w oficjalnych przewodnikach:
BCM54210PE SYNC_OUT pin bug – przy każdym bootowaniu sterownik inicjalizuje pin SYNC_OUT jako wyjście zamiast wejście. SatPulse nie odbiera wówczas sygnału PPS i grandmaster jest nieoperacyjny. Fix: wymusić toggling stanu pinu przed startem SatPulse przez ExecStartPre w systemd.
Ubuntu 22.04 nie ma PHC – wsparcie dla PTP w kernelu raspi pojawiło się, ale nie trafiło do Ubuntu 22.04. Bez /dev/ptp0 cały stack odpada. Wymagany jest Ubuntu 24.04 z kernelem 6.8.0-raspi.
Test holdover (10 godzin bez sygnału GPS) pokazał drift do 15 ms – akceptowalny w środowiskach laboratoryjnych i wielu scenariuszach przemysłowych. Klienci PTP przez całe 10 godzin pozostali zsynchronizowani z grandmasterem, nie przełączając się na WAN NTP.
Jeśli jednak potrzebujesz gwarancji dokładności przy zaniku GPS lub zaniku zasilania, potrzebujesz sprzętu z TCXO lub OCXO. CM4 ma standardowy kryształ bez kompensacji temperaturowej – i tu kończy się oszczędność.
Skrypty Pythona, które nie wstydzą się produkcji
Bite Code!
Większość skryptów, które widzimy w środowiskach produkcyjnych, to prowizorki — działają, ale przy pierwszym problemie są niemożliwe do debugowania. Kilka prostych zasad zmienia to diametralnie.
Sekrety i konfiguracja: hierarchia ma znaczenie
Nigdy nie przekazuj tokenów jako argumentów CLI — lądują w historii shella. Właściwy przepływ to: zmienna środowiskowa → OS keyring (biblioteka keyring) → getpass jako ostateczność. Przy kolejnym uruchomieniu token jest już w keyring i użytkownik nie musi nic robić.
Konfigurację ładuj zawsze w tej samej kolejności priorytetu (od najwyższego):
- argument CLI przekazany ręcznie
- zmienna środowiskowa
- lokalny plik konfiguracyjny
- wartość domyślna
Argparse obsługuje to elegancko: default=int(os.getenv("YOUR_SCRIPT_RETRY", 3)). Env var nadpisuje default, CLI nadpisuje env var. Zero niejednoznaczności.
Print vs log: rozdziel te dwie rzeczy
print() jest dla użytkownika skryptu. Logging jest dla dewelopera — czyli Ciebie za trzy miesiące, gdy coś się posypie o 2 w nocy.
Kluczowy trick: domyślnie ustaw poziom logowania na 9999, czyli de facto wyłączony. Logi włącza użytkownik przez zmienną środowiskową:
YOUR_SCRIPT_LOG_LEVEL=ERROR python script.py
Bez tego skrypt jest czysty. Z tym — pełna widoczność. Nie decydujesz za użytkownika, gdzie zapisać logi — jeśli potrafi ustawić env var, potrafi też zrobić przekierowanie w shellu.
Koniecznie: czysty exit i obsługa crashy
Stack trace wyrzucony prosto na terminal to antywzorzec. Użytkownik nie wie, co z tym zrobić, a Ty ujawniasz szczegóły implementacji. Zamiast tego użyj sys.excepthook:
def on_crash(exctype, value, tb):
if logging.getLogger().isEnabledFor(logging.ERROR):
logging.error("Uncaught exception", exc_info=(exctype, value, tb))
else:
print("Nieoczekiwany błąd. Ustaw LOG_LEVEL=ERROR, żeby zobaczyć szczegóły.")
sys.excepthook = on_crash
Domyślnie użytkownik widzi czytelny komunikat. Developer włącza logi i dostaje pełny traceback. sys.exit("komunikat") zamiast wyjścia bez kodu — automatycznie zwraca kod 1, co pozwala skryptom powłoki podejmować decyzje.
Jedna rzecz, którą możesz wdrożyć dziś: dodaj sys.excepthook do każdego skryptu używanego przez innych. To pięć linii kodu, które eliminują kategorię zgłoszeń "skrypt się wysypał i nie wiem dlaczego".
Generator konfigu NetFlow
Narzędzie służy do sprawdzania obsługi NetFlow oraz generowania konfiguracji telemetryki przepływów dla różnych platform sieciowych, m.in. Cisco, Fortinet, Check Point, Meraki i VMware. Może pomóc w przygotowaniu urządzeń do analiz bezpieczeństwa, ale ponieważ konfiguracje pochodzą ze źródeł społecznościowych i nie są oficjalnie zatwierdzone, przed wdrożeniem trzeba zweryfikować je w dokumentacji producenta. Projekt jest hobbystyczny i udostępniany bez gwarancji ani wsparcia.
Sprawdź MTU na ścieżce
FryguyPA
MTU Path Test to narzędzie diagnostyczne do sprawdzania maksymalnego rozmiaru pakietów na kolejnych odcinkach trasy do jednego lub wielu adresów. Wysyła podwójne testy ICMP — z ustawioną flagą DF oraz z możliwością fragmentacji — dzięki czemu pomaga wykryć problemy z dużymi pakietami, ustalić miejsce fragmentacji i sprawdzić, czy ruch nadal dociera do celu. Narzędzie jest dostępne w wersjach Python, Bash, PowerShell i Go, więc można używać go na macOS, Linuxie oraz Windowsie, także na komputerach bez dodatkowych środowisk uruchomieniowych. Wyniki są prezentowane w formie drzewa trasy, a opcjonalnie zapisywane do osobnych plików logów.
Meta usunęła IPv4 z infrastruktury edge
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