Dokładność zegarków kwarcowych

Jakiś czas temu w komentarzach pod wpisem u Boniego zeszło na dokładność zegarków kwarcowych. Było o tym, że są znacznie dokładniejsze od mechanicznych. Poszperałem w sieci na temat dokładności chodu zegarków, zarówno mechanicznych, jak i kwarcowych i znalazłem informacje[1], że chronometry (certyfikowane) mechaniczne, to dokładność -4/+6 sekund dziennie, natomiast kwarc (dowolny) to -15/+20 sekund miesięcznie.

Spostrzeżenie organoleptyczne było takie, że zarówno budzik Casio, zegarek naręczny MQ-24 reguluję dwa razy do roku – przy zmianie czasu. I żadnych niedokładności nie widzę, więc musi być jeszcze dokładniej w praktyce. Co prawda na sekundnik nie patrzę w żadnym z przypadków, ale różnicę rzędu minut czy też minuty mógłbym zauważyć.

Postanowiłem zrobić amatorski test dokładności mojego Casio naręcznego. Zsynchronizowałem czas na komputerze przy pomocy NTP[2], zatrzymałem zegarek z sekundnikiem rozpoczynającym minutę. W momencie zmiany minuty włączyłem zegarek naręczny. Czyli powiedzmy dokładność do jednej sekundy. Dla pewności zapisałem datę: 21 czerwca.

W trakcie testu zegarek był użytkowany – między innymi zaliczył wyjazd na wakacje. Czyli i trochę leżenia, i trochę noszenia, i trochę podgrzania na słońcu. Niemniej zegarkom kwarcowym takie rzeczy niespecjalnie powinny robić różnicę.

Przedwczoraj, czyli 24 lipca, nadszedł czas na podsumowanie testu. Ponownie sprawdziłem synchronizację czasu na komputerze i sprawdziłem różnicę czasu. Wyniosła +5 sekund w ciągu 35 dni, czyli równo 1 sekunda tygodniowo. Poniżej minuty rocznie. Nic dziwnego, że mogłem nie zauważyć różnic pomiędzy regulacjami czasu.

Podsumowując: zegarki kwarcowe są znacznie dokładniejsze od mechanicznych. Dokładność chodu zegarków przedstawia się następująco:
Zegarki mechaniczne (chronometry): -4/+6 sekund dziennie.
Zegarki kwarcowe: -15/+20 sekund miesięcznie.

[1] W wielu miejscach, generalnie zbieżne, niekiedy różniące się pojedynczymi sekundami. Nie zanotowałem niestety linków.

[2] Znaczy po prostu sprawdziłem, czy lokalny pokrywa się z czasem podawanym przez serwery NTP. Zsynchronizowany jest cały czas – to chyba już domyślne na większości systemów, z komórkami włącznie.

UPDATE 28.09.2017 sprawdziłem ponownie. +15 sekund różnicy w 99 dni. Daje sekundę w 6,6 dnia, czyli odchylenie bez zmian.

Internet rzeczy nadchodzi

Internet rzeczy jest coraz bliżej. Coraz więcej sprzętów posiada interfejsy sieciowe, przez które można nimi zarządzać, przez które mogą one wymieniać dane i… przez które można się włamać. Rozmawiałem ostatnio z ludźmi bardziej siedzącymi w temacie i wygląda to źle. Sprzęt jest słaby (w sensie mocy obliczeniowej), przez co ograniczone są implementacje bezpiecznych protokołów. Brakuje jednego wspólnego standardu zarządzania – generalnie co produkt/producent, to autorski system komunikacji, co gorsza, rzeczy są wystawiane bezpośrednio do internetu, bez ograniczenia do wydzielonej sieci lokalnej[1].

Czasem mam wrażenie, że twórcy zbyt skupili się na aspekcie elektronicznym, a zupełnie pominęli część może nie tyle programistyczną, co sieciową. Rozumiem, że SNMP nie jest jakoś bardzo powszechne w świadomości, a możliwość ustawiania danych przy jego jest jeszcze mniej znana, ale IMO nadaje się do IoT idealnie. Zresztą, nawet ustandaryzowany JSON byłby OK, a pewnie bardziej strawny dla programistów.

Gdyby już istniał standard wymiany danych, to można by zrezygnować z wystawiania rzeczy na świat. Nie mam złudzeń, sytuacja z aktualizacją rzeczy będzie wyglądać jeszcze gorzej, niż w przypadku istniejących urządzeń, a przecież z routerami czy kamerami IP już w tej chwili jest dramat. O ile o aktualizacji oprogramowania w kamerze czy routerze jeszcze ktoś pomyśli, to co z lodówką, głowicą grzejnika czy żarówką? Jakoś wątpię, by były aktualizowane, nawet, jeśli producent przewidzi taką możliwość.

Mam wizję, że rolę bramy dostępowej, czyli centrum, które uwierzytelnia użytkownika i łączy się z rzeczami pełniłby router. Po pierwsze, i tak jest na brzegu sieci, więc warto by go zabezpieczyć, zaktualizować. Po drugie, z racji miejsca ma najlepsze połączenie z zewnętrznym światem. Po trzecie, routery są/bywają stosunkowo mocnym sprzętem, szczególnie w porównaniu z rzeczami, a nawet niekoniecznie ustępują słabszym desktopom. No i zawsze można jakąś płytkę z procesorem ARM wykorzystać. Do tego parowanie certyfikatów brama-rzecz przy pierwszym uruchomieniu i jest względnie bezpiecznie, oczywiście przy wyłączeniu możliwości komunikacji z innymi hostami po parowaniu i zabezpieczeniu (aktualizowaniu) bramy.

Na koniec taka refleksja, chociaż może to tylko moje odchylenie – czy naprawdę potrzebujemy wszystkiego zautomatyzowanego i podłączonego do internetu? Rozumiem proste timery załączające urządzenia np. do grzania wody czy czy termostaty elektroniczne do sterowania ogrzewaniem, ale czy włączanie żarówek przez internet jest tak naprawdę potrzebne? Albo czy lodówka musi informować, że mleko/piwo się skończyło?

W przypadku ogrzewania z jednej strony pewnie wystarczy automatyzacja na poziomie „w dni powszednie włączaj ogrzewanie o 6:30, w weekendy o 8:00”, z drugiej jednak, przy synchronizacji ze smartfonem, można by ustawić, żeby ogrzewanie załączało się zawsze pół godziny przed budzikiem, po prostu. No i zależy, czy mieszkanie, czy dom. IMO w domu sterowanie żaluzjami i trochę bardziej zaawansowana automatyka mogą mieć sens i ekonomiczny (konkretne oszczędności), i nie widać na pierwszy rzut oka, gdzie się światło świeci. W każdym razie ja wolę jednak bardziej manualne sterowanie i do IoT się nie spieszę.

[1] Co też nie do końca jest rozwiązaniem, ponieważ przy domyślnych danych (IP, login, hasło) atakujący jest w stanie wykonać atak z lokalnej przeglądarki użytkownika – wystarczy prosty JS…

Obudź sobie Linuksa

Mało kto wie, ale komputer może się sam włączyć o zadanej godzinie. Zupełnie sam, bez pomocy zewnętrznych źródeł, magic packet i Wake-On-LAN. Wykorzystać można do tego rtcwake. Można to wykorzystać do oszczędzania energii (i zużycia sprzętu), a przy tym nie musieć włączać komputera ręcznie, nie czekać na jego uruchomienie, ogólnie – mieć wrażenie, że działa on cały czas.

W szczególności można zrobić z komputera budzik (włączy się o zadanej godzinie i np. odtworzy zadany utwór albo stację radiową) czy też do maszynki przyjmującej backupy (nie musi być włączona cały czas, wystarczy włączyć ją na czas transferu backupu i wyłączyć po ich przesłaniu). Automagiczne włączanie przydać się może także w firmie, gdzie Linux pełni rolę serwera NAS i wydruku – nic nie stoi na przeszkodzie, by wyłączał się po pracy (np. 18:00), a uruchamiał przed przyjściem pierwszych pracowników (np. 7:00).

Wszystko to można osiągnąć za pomocą programu rtcwake będącego częścią util-linux z odpowiednimi parametrami.

Na początek warto jednak pamiętać, że wyłączenie wyłączeniu nierówne. Program rtcwake obsługuje m.in. następujące tryby wyłączenia (wybierane przełącznikiem -m):

  • standby – stan ACPI S1. Minimalne oszczędności energii, błyskawiczny powrót do działającego systemu. Tryb domyślny.
  • mem – stan ACPI S3 (Suspend-to-RAM). Wyłączone jest wszystko, poza pamięcią RAM. Duże oszczędności energii, bardzo szybkie wybudzanie.
  • disk – ACPI state S4 (Suspend-to-disk). Wyłączenie wszystkiego, stan maszyny zapisywany jest na dysku. Stosunkowo wolne wybudzanie z uwagi na konieczność odczytu zawartości pamięci RAM z dysku.
  • off -ACPI state S5 (Poweroff). Wyłączenie systemu. Nie jest oficjalnie wspierane prze ACPI, ale zwykle działa.

Niestety, rtcwake posiada jedną poważną wadę – nie pozwala na podanie czasu wybudzenia w „ludzki” sposób. Można jedynie podać za ile sekund ma nastąpić wybudzenie albo czas w postaci Unix time. Mało wygodne. Oczywiście można to obejść przy pomocy skryptów (patrz linki).

Ja chwalę sobie tryb mem i używam często wieczorem, żeby rano mieć włączony komputer. Przy okazji często budzę się dźwiękiem włączanego komputera (nie, nie ustawiam muzyki). Skryptów nie używam, po prostu usypiam kompa na ten sam okres czasu, osiem godzin, przy pomocy polecenia:

rtcwake -s 28800 -m mem

Da się oczywiście zrobić więcej/lepiej ale… jakoś nie mam potrzeby.

Więcej o rtcwake AKA warto przeczytać:

  1. http://czytelnia.ubuntu.pl/index.php/2012/05/23/automatycznie-wybudzanie-z-hibernacji-budzik/ – dobry opis po polsku, dobry skrypt
  2. http://blog.loleksy.pl/2014/01/28/reuse-an-old-laptop-or-netbook-as-a-vps-backup-solution/ – skrypt do backupu z wykorzystaniem rtcwake