caxapa.ru :: Ах, время, времечко! NTP, UTC и прочий зоопарк

Dingo (12.12.2018 10:48 - 10:52, просмотров: 6599) MBedder

Ах, время, времечко! NTP, UTC и прочий зоопарк Коснулось, надо сделать часы, синхронизируемые по NTP. Посмотрел сейчас в исходники ARM GCC и не смог понять, что есть что. Структура struct tm хранит почти человекопонятный формат с полями YY, HH, ... struct timeval { time_t tv_sec; suseconds_t tv_usec; }; - второе поле что за попугаи - доли секунд или микросекунды? В чём базово тикает и хранится время? Если верить исходникам, то time_t = long = signed long = signed 32 bit. Я понимаю, что NTP и Unix Time используют разные точки за начало отсчёта, но NTP в добавок использует беззнаковое смещение от начала эпохи. Есть ещё тип clock_t, который, рукалицо, использует беззнаковый тип! Каша в голове. Собственно,

в чём должно тикать время системы,

что первично, а что вторично

и как NTP c UTC согласовать без лишних неоднозначностей (без лишней головной боли)?

PS: Пожалуйста, перенесите топик туда, где ему место.

Ответить

- Кстати, надо смотреть не на NTP, а на SNTP. Там вообще всё просто, как 5 копеек. - SciFi(12.12.2018 12:00)
  - Помогите ещё разложить октет LI.VN.MODE по полям? От одного сервера получал 0x1C и 0x24. Кому не сложно, а то у меня ерунда какая-то, хотя всё вроде предельно просто... - Dingo(13.12.2018 11:12)
    - 0x1C = 00 011 100, LI = 0, VN = 3, MODE = 4. 0x24 = 00 100 100, LI = 0, VN = 4, MODE = 4. - SciFi(13.12.2018 11:18)
      - А по описанию стандарта чуть ли не обратный порядок бит выходит. Там 01.234.567, а по факту 76.543.210 , при чём порядок полей как раз соответствует описанию. - Dingo(13.12.2018 12:02)
        
        Вы путаетесь в индейцах? В сетевых стандартах, как и при письме на бумаге, играют большие индейцы. То есть старшие разряды вначале. - SciFi(13.12.2018 12:06)
        
        Спасибо за разъяснения. - Dingo(13.12.2018 12:51)
    - Вин7 на запрос 0xdb получает 0x1C, Dingo(47 знак., 13.12.2018 11:18)
  - До 2038 года-> Точнее, подразумевается, что в девайсе есть счётчик эпох. - Dingo(12.12.2018 12:03, ссылка)
    - ЕМНИП, в SNTP написано, что если старший бит перевернулся, то это 2038 и дальше. Короче, нет там этой проблемы. Опять же, к тому времени или осёл, или эмир того... - SciFi(12.12.2018 12:09)
      - Ну как нет проблемы, чтобы однозначно сравнивать время, переменные должны быть знаковыми. Нужно переписывать там, где это не учтено. - VLLV(12.12.2018 12:54)
      - Про осла и эмира напомнило Millennium bug Codavr(155 знак., 12.12.2018 12:14 - 12:17)
        
        Дык оно и сейчас так. Время от времени повелители времени вставляют лишнюю секунду (чтобы от астрономического времени не отставать). Клевещут, весь тырнет лихорадит, когда такое происходит. Ещё спейс шаттл не запускали под новый год, патамушта хз SciFi(27 знак., 12.12.2018 12:19)
- Если не нужно точнее секунды, то time_t - самое оно. В современном newlib это int64_t, хватит до конца света. Или можно всё ручками, никто не заставляет использовать стандартную библиотеку. - SciFi(12.12.2018 10:51)
  - По поводу newlib Dingo(442 знак., 12.12.2018 11:40 - 11:42)
  - Нужно точнее секунды. Тут разные подходы: кто-то считает доли секунды (fixed point), кто-то микросекунды и отдельно тип с разрешением в наносекунды. Хотя 32.32 даёт разрешение чуть больше 200 пикосекунд.(Здесь я на стороне NTP) - Dingo(12.12.2018 10:58 - 11:00)
    - Непонятно, вот считаете вы пикосекунды, и тут приходит синхронизация NTP, у которой точность миллисекунды, и что делать? - VLLV(12.12.2018 11:15)
      - Ничего, считаем по своим часам, если в пределах ошибки. Что не отменяет типа данных с разрешением в доли наносекунд. А если ещё вспомнить про эпохи, то можно оперировать значительно большими временными промежутками, чем UTC. - Dingo(12.12.2018 11:24)
        
        Тогда о какой синхронизации идет речь? - VLLV(12.12.2018 11:42)
        
        Скорее всего вы описываете ситуацию, когда источник точнее, но с большой девиацией и/или с более грубой разрешающей способностью. Dingo(36 знак., 12.12.2018 11:56)
    - Откуда у вас наносекунды? Космос какой-то. Ну и, возвращаясь к первому вопросу, очевидно, "suseconds_t tv_usec" - это микросекунды. - SciFi(12.12.2018 11:09)
      - ~100 мксек меня устроят. А пикосекунды это 1/(2^32). Dingo(307 знак., 12.12.2018 11:18)
        
        Не надо молиться на эти штуки. Кстати, в стандарте Си этого нет. Я бы вообще использовал сишную библиотеку только с точностью до секунды, а остальное всё сам. Там ничего хитрого нет от слова совсем. - SciFi(12.12.2018 11:39)
        
        Ну не так все просто, я вот о чем... ну эти все микросекунды для чего то были сделаны? - Тут бабах, пришла синхронизация секунд. Что делать с микросекундами? Оставлять? - это при том, что секунды поменялись? Обнулить? - съедет функциональность, VLLV(98 знак., 12.12.2018 11:49)
        
        Если интересно, почитайте по теме. Где-то было упоминание, что время должно идти непрерывно, то есть просто подкрутить часы нельзя, можно подкручивать только скорость хода. Как я думаю: пока будем ждать, может наберём и статистику/замеры для Dingo(27 знак., 12.12.2018 11:53)
        
        Да знаю. Причём, в каком-то мануале по безопасному программированию натыкался на явный запрет использования time.h . (Вроде даже MISRA C) Dingo(132 знак., 12.12.2018 11:48)
        
        В моём понимании time.h нужен только для перевода времени из time_t в читаемый человеком формат и обратно. И там неопределённость: time_t - это int32_t или int64_t. Если отказаться - невелика потеря, код для перевода гуглится мгновенно. Больше SciFi(16 знак., 12.12.2018 11:56)
        
        Я работал с time.h без проблем, пока не стал придумывать упрощенную упаковку даты :) - VLLV(12.12.2018 11:52)

Средства и методы разработки