27.04.2022 14:19
EkaterinaZu 11 3400 Источник

Казалось бы, что ещё нужно для счастья? Купил железку, воткнул жесткий диск, прикрутил камеры, сервер почты, хранилище фоток итд, что ещё нужно от этой несчастной железки? Ну в принципе можно было бы и отстать, но потенциал-то есть, внутри нормальный линукс. Когда дома становится куча гаджетов, камер, телефонов, ноутбуков начинает появляться желание , дабы везде было одно время.

И в принципе можно прописать какой-то чужой сервер точного времени, но мы не ищем легких решений.

Итак приступаем. Сначала надо найти подходящий usb GPS приёмник. В моём случае попался старенький globalsat. У моего приёмника внутри оказался rs->usb pl2303 , но может оказаться ftdi итп, тут надо искать , тот что можно прикрутить. Втыкаем его в USB Synology NAS и ..... и ничего.

Логинемся на NAS по ssh , для удобства сразу становимся root ( sudo -i )

делаем 

cd /dev
ls -a

Убеждаемся , что ttyUSB устройств у нас нет.

Но это не печаль. Проверяем , что наше устройство подключилось 

lsusb
dmesg

смотрим, что происходит. По факту оказывается, что надо подгрузить модули, usbserial.ko Synology в /lib/modules положили, а вот дров на usb/com нет, ну нет и нет..

пишем в консоле uname -a , в моём случае у меня GNU/Linux synology_apollolake

идём по адресу http://www.jadahl.com/iperf-arp-scan/

и качаем модули от своего DSM , копируем в /lib/modules

в rc.local можно сразу добавить 

insmod /lib/modules/usbserial.ko > /dev/null 
insmod /lib/modules/cp210x.ko > /dev/null

или добавить скрипт в /usr/local/etc/rc.d

#!/bin/sh
case $1 in
  start)
    insmod /lib/modules/usbserial.ko > /dev/null 2>&1
    insmod /lib/modules/pl2303.ko > /dev/null 2>&1
    ;;
  stop)
    exit 0
    ;;
  *)
    exit 1
    ;;
esac

Проверяем, есть ли терерь ttyUSB0 в /dev.

В моём случае всё отлично завелось. Сразу делаем symlink для ttyUSB0 в виде gps0

в конфиг файл /etc/ntp.conf добавляем строчку

server  127.127.20.0    mode 0    prefer    iburst     minpoll 4       maxpoll 6

Этим мы укажем, что gps0 является источником точного времени для ntpd.

в строке 127.127.20.х х: это номер порта gps, в моём случае 0 и порт у меня gps0

mode 0 , это скорость ком порта 4800 , 0x10=9600, 0х20=19200, 0x30=38400, 0х40=57600, 0х50=115200 bps соответственно.

сохраняем, перезапускаем ntpd

Проверяем работу > ntpdate -d localhost

Looking for host localhost and service ntp
127.0.0.1 reversed to localhost
host found : localhost
transmit(127.0.0.1)
receive(127.0.0.1)
Server 127.0.0.1, port 123
stratum 1, precision -23, leap 00, trust 000
refid [GPS], root delay 0.000000, root dispersion 0.003693
reference time: e5fe98e9.546b9201 Mon, Apr 11 2022 15:09:13.329
originate timestamp: e5fe9928.1514e582 Mon, Apr 11 2022 15:10:16.082
transmit timestamp: e5fe9928.150ce81f Mon, Apr 11 2022 15:10:16.082
filter delay: 0.02573 0.02573 0.02573 0.02570
---- ---- ---- ----
filter offset: -0.000003 -0.000009 -0.000002 +0.000012
---- ---- ---- ----
delay 0.02570, dispersion 0.00000, offset +0.000

Всё, у нас свой сервер точного времени, осталось только везде его прописать.

И да, не забудте добавить свои сети в конфиг ntp.conf

restrict AAA.BBB.CCC.0 mask 255.255.255.0

Комментарии (11)


  1. Gordon01
    27.04.2022 14:31
    #24302146

    Спасибо за статью, очень интересно! Добро пожаловать на хабр. Написал в личку предложения по улучшению.

    В моём случае всё отлично завелось. Сразу делаем symlink для ttyUSB0 в виде gps0

    Это не пропадет после перезагрузки?


    1. rstepanov
      27.04.2022 17:03
      #24302598

      Это не пропадет после перезагрузки?

      И после обновления системы тоже - что будет?


  1. redneko
    27.04.2022 14:33
    #24302156
    +2

    Одна проблема - точность временных интервалов доставки пакетов через USB стек нивелирует точность самого GPS. Более правильное решение - работать через железный RS-232, дергая одну из ног выходом PPS приёмника.

    С развитием технологий уже перестает хватать точности обычного NTP и приходится мигрировать на PTP. Один из примеров - SMPTE 2210.


    1. Gordon01
      27.04.2022 14:42
      #24302178

      Ага, получается непредсказуемый джиттер вносит еще и сам USB-UART конвертер? Особенно если это какой-нибудь китайский CH***?

      Более правильное решение - работать через железный RS-232, дергая одну из ног выходом PPS приёмника.

      То есть юзать только дискретный PPS и вообще не читать NMEA-данные?


      1. redneko
        27.04.2022 14:50
        #24302206

        Конвертер тупой, вряд-ли он может вносить существенный джиттер. Вносит сам USB - конвертер оправил пачку данных, а дальше ждем пока у системы появится свободное время обработать прерывание, вычитать данные из буфера, передать их в userspace и обработать текст протокола. С парсингом NMEA, насколько помню проблем нет, но для максимальной точности желательно учитывать длину соединительного провода и время передачи самих сообщений на такой небольшой скорости интерфейса - это всё вносит фиксированную задержку. Таких проблем как раз и нет при использовании PPS, но само ядро еще должно быть собрано с его поддержкой, а в случае NAS это маловероятно.


        1. Gordon01
          27.04.2022 15:02
          #24302256

          Конвертер тупой, вряд-ли он может вносить существенный джиттер

          Да не совсем, это целый контроллер, со своими многоуровневыми буферами. Спецификации задержек в даташите я не нашел.

          но для максимальной точности желательно учитывать длину соединительного провода и время передачи самих сообщений на такой небольшой скорости интерфейса - это всё вносит фиксированную задержку

          Это точно в пределах погрешности)

          Таких проблем как раз и нет при использовании PPS, но само ядро еще должно быть собрано с его поддержкой, а в случае NAS это маловероятно.

          А как в этом случае решается "проблема" no-realtime обработки этого всего со стороны ядра?


    1. gbg
      27.04.2022 14:50
      #24302204

      Так в USB есть изохронный режим - будет какое-то запаздывание, но фиксированное. А вот как потом точно по времени ловить момент перехода ноги RS232 между состояниями - не поделитесь?


      1. redneko
        27.04.2022 14:55
        #24302224
        +1

        Изохронный режим есть, но используется в основном для передачи аудиотрафика и ограничен по битрейту. Интересно стало даже теперь в каком режиме работают конвертеры интерфейсов.

        Ловить - через Kernel PPS. Интерфейс в ядре есть, gpsd умеет им пользоваться.

        Вот ссылочка, думаю будет полезна - https://habr.com/ru/company/ruvds/blog/509890/


        1. gbg
          27.04.2022 15:02
          #24302250

          FT232 (к примеру), да и сама STM32, работают в BULK. Ну и за неимением лучшего (аппаратного RS232 в большинстве современных девайсов), некий колхоз с участием USB-Audio выглядит приемлемым способом ввести в компьютер что-то низкочастотное и критичное по времени.


        1. Gordon01
          27.04.2022 15:57
          #24302432
          +2

          Кстати, хорошая статья, там раскрывается вопрос "ради чего это все".

          • PPS ±5 μSec

          • Интерфейс USB 2.0 ±100 μSec (100000 nSec)

          • NTP по сети ~±30 mSec


  1. uyrij
    30.04.2022 11:14
    #24309064

    Интересно, но .... И главное, зачем, если есть интернет?