Кратковременная и долговременная стабильность часов

[wrest]

Dmitriy40
Джиттер существует, я не спорю. Но вы ж видите, на скриншоте джиттер (среднеквадратичное отклонение, в столбце под сигмой) у верхнего сервера намерян в 1мс, что на два порядка (а не "немного") меньше rtt.

-- 27.02.2019, 00:20 --

Pphantom в сообщении #1378596 писал(а):

еще порядок получится, если сильно повезет. Еще лучше - совершенно нереально.

Ну... если очень хорошо повезет (вот как мне на скриншоте выше) то еще порядок к вашему добавить можно, то есть до 1мс. Но я доволен и 10-ю мс.

[Pphantom]

wrest в сообщении #1378601 писал(а):

Ну... если очень хорошо повезет (вот как мне на скриншоте выше) то еще порядок к вашему добавить можно, то есть до 1мс. Но я доволен и 10-ю мс.

Судя по студенческим достижениям (а им стоит верить - у нас весьма неглупые студенты, и задача эта по некоторым причинам воспринимается многими как дело чести), повезти должно слишком хорошо. Настолько, что такое разовое везение невозможно своевременно (а не после обработки данных, полученных более традиционным образом) обнаружить и использовать в практически полезных целях.

[wrest]

Pphantom
Ну может у вас Интернет с плохим джиттером, тогда конечно
Или вы там по пустой локалке запускаете с rtt 1-2мс и все равно джиттер мешает?

[Pphantom]

wrest в сообщении #1378608 писал(а):

Ну может у вас Интернет с плохим джиттером, тогда конечно

Нет, естественно, иначе было бы понятно и неинтересно.

[realeugene]

Dmitriy40 в сообщении #1378582 писал(а):

Я на 98% уверен что внутри планшета никто никуда 1PPS сигнал не заводил и соответственно точность ограничена лагами NMEA сообщений.

Посмотрел схему шестого айфона, которая у меня завалялась. Приёмник GPS интегрирован в LTE модем - единый BGA чип. Что там куда заведено сказать сложно. Но есть отдельный проводник BB_TO_AP_GPS_TIME_MARK, у которого написано примечание: "MIS-NAMED NET. GPS_TIME_MARK ACTUALLY GOES FROM AP TO BB." То есть по отдельному проводнику между двумя GPIO в центральном процессоре и в модеме передаётся какая-то метка времени GPS, но почему-то в направлении от центрального процессора к модему.

LTE модем подключён к центральному процессору через PCIe, так что, там и просто прерывания могут идти от GPS раз в секунду запросто.

[Dmitriy40]

realeugene
Идти то прерывания конечно могут, но возникает минимум два хитрых вопроса: 1) кто сказал что они выравнены на начало секунды с точностью порядка единиц ppm? 2) зачем вообще в телефоне/планшете привязка к календарному времени? Для работы ведь этого не требуется.
Вот потому я и не вижу смысла усложнять драйвера обработкой 1PPS сигнала. Секундные прерывания может и пригодились бы, хотя NMEA сообщения великолепно и стандартно их заменяют.

wrest
GPS Time - кривая. У меня при каждом запуске смещение прыгает от -0.3с до +0.85с - чего быть ну никак не может. Да и глазом видно что секунды меняются гораздо синхроннее.
ClockSync при этом же показывает достаточно стабильные значения, +0.226±0.003с - и этому веры больше, глазом видно что разница смены секунд похожа на указанную.
NTP & GPS Clock [ROOT] - по NTP соединиться не смогла, по GPS показывает стабильно +0.2с - что совпадает с предыдущей и свидетельствует о правильной работе GPS модуля.

[EUgeneUS]

Dmitriy40 в сообщении #1378582 писал(а):

Существенно точнее оно возможно лишь если величина пингов предсказуема (пусть большая, но или предсказуемая, или точно измеримая/известная), только в этом случае его можно скомпенсировать точно. Реально же пакеты ходят разными путями и последовательные пинги могут отличаться в разы.

Пакеты, конечно, могут ходит разными путями, никто им этого не запретит.
Но непредсказуемость времени пинга, ИМХО, связана в большой степени с сегментами сети, на которых работают CSMA/CD-подобные протоколы. Там время прохождения пакета принципиально случайное.

[Dmitriy40]

EUgeneUS в сообщении #1378646 писал(а):

Но непредсказуемость времени пинга, ИМХО, связана в большой степени с сегментами сети, на которых работают CSMA/CD-подобные протоколы.

Ну да, и это тоже.

(Оффтоп)

Только всё ещё хуже: хорошо если вы связаны с конечным абонентом цепочкой правильных маршрутизаторов (с полной матрицей связности каналов) и все каналы, по которым идут ваши пакеты, больше никем не заняты, и все линии передач достаточно хороши и без потерь пакетов - вот тогда пинги будут достаточно стабильны. При нарушении любого условия (включая и не указанные) пинги становятся плохо предсказуемыми, например при объединении двух потоков в одном канале возникают вопросы приоритета трафика, при загруженности маршрутизатора даже сторонним трафиком (не пересекающимся с вашим) он может дольше реагировать на приход вашего пакета и позже его отсылать дальше, где-то может работать балансировка загрузки каналов и направлять пакеты по разным путям, где-то по пути могут происходить замирания сигнала (или увеличение уровня шума, или перекрёстные наводки, или просто внешние наводки, или ...), приводящие к потерям пакетов и их перепосылке.
А ещё хуже хотя бы потому что даже обычный TCP/IP уже является протоколом с перепосылкой пакетов и уже на этом уровне могут происходить недетерминированные задержки. Даже до ближайшего маршрутизатора в локалке, где никакого другого трафика будем считать и нет! Про WiFi вообще молчу, эфир в городах прилично загажен и уже на этом отрезке потери пакетов вполне реальны. NTP правда работает по UDP, но это лишь означает что ваши пакеты теряются молча, без информации об утере, хоть и без перепосылки, да и во что ваши пакеты завернутся дальше в сети предсказать трудно. В WiFi (как и в 2G/3G/4G) вполне может быть (я просто не в курсе) перезапрос пакетов ниже уровня IP, на канальном уровне, и тогда и UDP пакеты будут ходить недетерминированно.

В общем причин джиттера задержки множество, так уж устроена сеть.

[wrest]

Dmitriy40 в сообщении #1378686 писал(а):

В общем причин джиттера задержки множество, так уж устроена сеть.

Не так страшен черт как его малюют. В обычном применении, вы пользуетесь домашним Интернетом, а не каким-то там городским вайфаем в автобусе. Вы описываете "почему может не получиться", и все описываете правильно, кроме одного: какова вероятность? вернее даже -- рапространенность таких случаев, что не получится? И главное, ниже какого джиттера не получится? Вот Pphantom выше пишет как бы о том, если я правильно расшифровал, что у его студентов джиттер задержки пакетов к NTP серверам в Интернете меньше 10мс не выходит -- с усреднениями и прочим положенным по протоколу NTP блекджеком, и каждый новый поток студентов подходит к этому снаряду и отходит всё с теми же 10мс.
Ну дык 10мс это прекрасно...

Между прочим, например apple заявляет что в apple watch абсолютная погрешность не превышает 50мс. Не в сутки или в месяц, а вообще, always (т.е. реальная погрешность в обычной жизни, думается мне, в пределах 1мс). Термостабилизрованный кварц и много собственных stratum-1 NTP серверов
Можно считать apple watch stratum-2 устройством...

[realeugene]

wrest в сообщении #1378696 писал(а):

Между прочим, например apple заявляет что в apple watch абсолютная погрешность не превышает 50мс.

В LTE SIB16 передаётся UTC границы фрейма в эфире с точностью до 10 мс.

[wrest]

realeugene в сообщении #1378710 писал(а):

В LTE SIB16 передаётся UTC границы фрейма в эфире с точностью до 10 мс.

Ну так то LTE. Сотовые каналы длинные, зашумленные, много девайсов и т.п.
Ща выйду на улицу гляну какой программка показывает джиттер.
А вайфай точнее?

upd Вышел на улицу. rtt в пределах 50, джиттер - ноль.

(скриншот)

[realeugene]

wrest в сообщении #1378714 писал(а):

А вайфай точнее?

Откуда самим файфайным базам знать точное время? Это же не сотовая сеть, администрируемая централизованно.

[Dmitriy40]

wrest
Вы немного не так поняли, Pphantom говорит чуть о другом, что на базе NTP не получить надёжного источника времени точнее 10мс (примерно). Надёжного! Вот сейчас, сегодня, вчера, завтра у Вас всё работает и даёт погрешность пусть даже 1мс, а послезавтра вдруг раз и стало 40мс, по независящим от вас причинам и обнаружите вы это лишь существенно позже (не через секунду даже). Именно поэтому он говорит "если повезёт", Вам и мне (и даже ему) обычно везёт, но это не гарантированно и следовательно не надёжно.

wrest в сообщении #1378696 писал(а):

Между прочим, например apple заявляет что в apple watch абсолютная погрешность не превышает 50мс. Не в сутки или в месяц, а вообще, always (т.е. реальная погрешность в обычной жизни, думается мне, в пределах 1мс). Термостабилизрованный кварц и много собственных stratum-1 NTP серверов

Гонят. Отключите им инет и все прочие каналы связи и посмотрите через сутки/неделю/месяц на сколько убегут.

Ну и в термостабилизированный кварц простите не верю, это сожрёт батарею за пару суток, верю в максимум термокомпенсированный кварц, но это не даст точность лучше десятых долей ppm (и для этого придётся поизвращаться). Хотя бы потому что для этого надо измерять температуру самого кристалла кварца с точностью уже до градуса. А ещё есть и тупо старение кварцев, уход частоты за год, и точно предсказать его малореально, лишь ограничить сверху (например для часового 32768Гц указано ±3ppm за первый год, потом в три-пять раз меньше).

Так что эти заявленные 50мс погрешности - очевидно лишь при хорошем инете и работающем NTP, хотя бы раз в неделю если кварц хорошо термокомпенсирован и отстроен по частоте или раз в час если он без подстройки вообще.

Насчёт 10мс устраивающей погрешности. Вот возьмём не часовой, а кварц на десяток МГц, самый обычный, у него начальная точность ±30ppm, дрейф от температуры -20°С..+70°С составит ±50ppm (в пределах +25±15°С на порядок меньше), старение за первый год ±5ppm (для более дорого кварца цифры будут ±10ppm, ±15ppm, ±3ppm). Т.е. суммарный уход может быть до 80ppm, что даст уход в 10мс уже за 2 минуты. Вот именно с таким интервалом Вам придётся опрашивать NTP сервер чтобы гарантированно не выходить за погрешность 10мс. Обычно конечно погрешности раз в 3-5 меньше и опрашивать можно раз в минут 5 (учитывая что сервер может и не ответить с первого раза). Или даже реже если хоть однажды подстроить частоту кварца (или хотя бы точно её измерить), тогда останется лишь температурный дрейф, который для комнатных температур на порядок ниже и для медленных изменений температуры хватит и несколько раз в сутки синхронизации с NTP.
Для сравнения параметры обычного часового кварца на 32768Гц: начальная точность ±20ppm, температурный дрейф 0.04ppm/°C², старение ±3ppm за первый год. Как видно он существенно точнее при небольшом изменении температуры, плюс для него известен график ухода от температуры (парабола ветвями вниз с вершиной в +25°С), что и позволяет его термокомпенсировать до долей ppm почти во всём диапазоне температур.

[wrest]

Dmitriy40 в сообщении #1378721 писал(а):

Гонят. Отключите им инет и все прочие каналы связи и посмотрите через сутки/неделю/месяц на сколько убегут.

У меня их нет, но было бы интересно.

Dmitriy40 в сообщении #1378721 писал(а):

Так что эти заявленные 50мс погрешности - очевидно лишь при хорошем инете и работающем NTP, хотя бы раз в неделю

Ну так раз в неделю это даже редко.

Dmitriy40 в сообщении #1378721 писал(а):

Ну и в термостабилизированный кварц простите не верю, это сожрёт батарею за пару суток, верю в максимум термокомпенсированный кварц,

Dmitriy40 в сообщении #1378721 писал(а):

Хотя бы потому что для этого надо измерять температуру самого кристалла кварца с точностью уже до градуса.

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

Dmitriy40 в сообщении #1378721 писал(а):

Т.е. суммарный уход может быть до 80ppm, что даст уход в 10мс уже за 2 минуты. Вот именно с таким интервалом Вам придётся опрашивать NTP сервер чтобы гарантированно не выходить за погрешность 10мс.

Вы можете программно мерить и компенсировать средний уход кварца из-за старения, в чем проблема?

[Dmitriy40]

wrest в сообщении #1378714 писал(а):

Вышел на улицу. rtt в пределах 50, джиттер - ноль.

А почему собственно разный offset у stratum 1/2 серверов, а? Кто-то где-то врёт. Или неправильно понимает числовые значения. По моему разбег offset-ов как раз и показывает реально достижимую точность для Вашего девайса и инета.

-- 27.02.2019, 14:42 --

wrest в сообщении #1378724 писал(а):

Вы можете программно мерить и компенсировать средний уход кварца из-за старения, в чем проблема?

В наличии внешнего источника точного времени (временных меток). Например NTP, или 1PPS GPS. Без такого источника любые кварцы будут уходить минимум на единицы ppm за год или десятую ppm кратковременно.
Ну и померить температуру кристалла кварца не так уж просто, если нужны доли градуса. Застабилизировать её подогревом всей схемы намного проще. И затратнее по энергии и стоимости конструктива. Именно так и делают точные источники частоты (времени). Когда не могут купить/применить рубидиевый стандарт частоты.