-
- Кстати, надо смотреть не на 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)
- Вы путаетесь в индейцах? В сетевых стандартах, как и при письме на бумаге, играют большие индейцы. То есть старшие разряды вначале. - SciFi(13.12.2018 12:06)
- А по описанию стандарта чуть ли не обратный порядок бит выходит. Там 01.234.567, а по факту 76.543.210 , при чём порядок полей как раз соответствует описанию. - Dingo(13.12.2018 12:02)
- Вин7 на запрос 0xdb получает 0x1C, Dingo(47 знак., 13.12.2018 11:18)
- 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)
- До 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)
- ЕМНИП, в SNTP написано, что если старший бит перевернулся, то это 2038 и дальше. Короче, нет там этой проблемы. Опять же, к тому времени или осёл, или эмир того... - SciFi(12.12.2018 12:09)
- Помогите ещё разложить октет LI.VN.MODE по полям? От одного сервера получал 0x1C и 0x24. Кому не сложно, а то у меня ерунда какая-то, хотя всё вроде предельно просто... - Dingo(13.12.2018 11:12)
- Если не нужно точнее секунды, то 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)
- Тогда о какой синхронизации идет речь? - VLLV(12.12.2018 11:42)
- Ничего, считаем по своим часам, если в пределах ошибки. Что не отменяет типа данных с разрешением в доли наносекунд. А если ещё вспомнить про эпохи, то можно оперировать значительно большими временными промежутками, чем UTC. - Dingo(12.12.2018 11:24)
- Откуда у вас наносекунды? Космос какой-то. Ну и, возвращаясь к первому вопросу, очевидно, "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)
- Да знаю. Причём, в каком-то мануале по безопасному программированию натыкался на явный запрет использования 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)
- Не надо молиться на эти штуки. Кстати, в стандарте Си этого нет. Я бы вообще использовал сишную библиотеку только с точностью до секунды, а остальное всё сам. Там ничего хитрого нет от слова совсем. - SciFi(12.12.2018 11:39)
- ~100 мксек меня устроят. А пикосекунды это 1/(2^32). Dingo(307 знак., 12.12.2018 11:18)
- Непонятно, вот считаете вы пикосекунды, и тут приходит синхронизация NTP, у которой точность миллисекунды, и что делать? - VLLV(12.12.2018 11:15)
- Кстати, надо смотреть не на NTP, а на SNTP. Там вообще всё просто, как 5 копеек. - SciFi(12.12.2018 12:00)