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

[Theoristos]

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

Малореализуемо и неясно что это конкретно, но допустим что есть. То есть, есть какой-то разъем, на котором очень стабильный мегагерц. И что, как этим поверять системные часы гаджета?

Вот как. Задам встречный вопрос.
Какими умениями и возможностями вы обладаете в плане программирования Android-устройств и построении электронных схем?
Как вообще, по вашему мнению, должна выглядеть подходящая процедура определения миллисекундных расхождений "на кратких (5 минут)" интервалах времени?

[wrest]

Theoristos в сообщении #1378439 писал(а):

Какими умениями и возможностями вы обладаете в плане программирования Android-устройств и построении электронных схем?

Программирование - никакими.
Электронные схемы - теоретическими (т.е. можно сказать - никакими).

[Theoristos]

О. С этого надо было начинать вопрос.
Увы, далеко не всегда осознают, что одной хотелки недостаточно, к ней должна прикладываться умелка. Или хотя бы суровая сумма денег для найма умельщиков.
Иначе, всё богатство вариантов работы с проблемой сужается до классического "идите на рынок и купите гуся" (с).

[wrest]

Theoristos в сообщении #1378439 писал(а):

Как вообще, по вашему мнению, должна выглядеть подходящая процедура определения миллисекундных расхождений "на кратких (5 минут)" интервалах времени?

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

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

P.S. Кстати, вы натолкнули меня на вот какую мысль, спасибо! Вероятно, все происходит так. Приложение метронома формирует, условно говоря, wav-файл, и отправляет его на системное аудио-устройство, и таким образом стабильность (и точность) тут зависит от аудио-устройства, стабильности и точности тактирования цап-а на выходе. Приложение-анализатор, в свою очередь, получает wav-файл (т.е. отсчеты с расставленными временными метками) от системного аудиоустройства и таким же образом выходит, что точность и стабильность зависят тут опять же не от системных часов телефона, а от стабильности и точности тактирования ацп в аудио-входе.

-- 26.02.2019, 09:02 --

Theoristos в сообщении #1378446 писал(а):

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

Ну это конечно банальщина, и она бы сошла за разумный совет, если бы сам совет у вас был :)
И потом, мы на форуме. Он же для общения, почему б не порассуждать?

[wrest]

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

Вот для примера, пишут что в Samsung Galaxy S4 установлен чип Wolfson WM5102
А в даташите на этот чип указано (http://www.farnell.com/datasheets/1728639.pdf), что тактироваться он может так:

Цитата:

Flexible clocking, derived from MCLKn, BCLKn or SLIMbus
2 low-power FLLs support reference clocks down to 32kHz

Интересно что это значит и как он тактируется, так сказать, в реальном железе (смартфоне).

[realeugene]

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

Интересно что это значит и как он тактируется, так сказать, в реальном железе (смартфоне).

Это значит, что в зависимости от настройки чипа драйвером он может тактоваться от клоков нескольких шин, вниз по частоте вплоть до частоты часового кварца. Другие клоки обычно менее точные, чем часовой кварц, если они не залочены на сотовую сеть или GPS. Откуда именно берётся клок для аудиочипа в конкретном смартфоне зависит от фантазий инженеров, его разработавших.

[Dmitriy40]

Более правильная дока: https://statics.cirrus.com/pubs/proDatasheet/WM5102_v4.2.pdf. Про систему тактирования страницы 224-250 и 326-329. Фактически у чипа есть два входа тактирования (вряд ли в смартфонах есть ещё другой источник цифрового аудиопотока или точный опорник на шине SLIM) и какая там частота на них и каков её источник - зависит от подключения чипа в схеме телефона.

Обычно кварц 32768Гц (когда присутствует в девайсе) намного точнее всех прочих и именно от него берут системное время (которое метки времени каждые сколько-то мс, но не календарь). Но не тактирование процессора или радиотракта - ни там ни там особой точности задающего генератора просто не нужно, вполне достаточно кратковременной (на интервалах в доли секунд) стабильности, а последний вообще подстраивается по сигналам базовой станции. Впрочем, даже и метки времени могут брать от менее стабильного источника (кварца), например ради постоянства количества процессорного времени в каждом тике, а критичные ко времени функции синхронизировать уже с календарём (кварцем 32768Гц) чисто программно. Ввод/вывод звука к таковым не относится, для звука погрешность в сотни ppm пофиг, её услышит один из миллиона с музыкальным слухом, массовые телефоны не для них разрабатываются. Потому откуда берётся опорная частота для звука в телефоне - вопрос.
Программы-метроному кстати вполне могут пользоваться неточным опорным источником частоты (для звука) и непрерывно переизмерять его реальную частоту по внешним сигналам (GPS, NTP). Забавно было бы отключить и GPS и интернет на одном из девайсов и после этого запустить программу и сравнить точность генерации/анализа.

Я выше предложил как это (точность тактирования звукового тракта) можно проверить: записать на максимально доступной дискретизации звук сигналов точного времени с радио и потом глазками посмотреть сколько именно отсчётов проходит между фронтами. Если писать лишь 5 сигналов в конце часа, то при дискретизации 44100Гц теоретически можно получить точность 0.5с/сутки, реально из-за всяких искажений на порядок хуже. Но можно непрерывно писать и час, получив погрешность в десятые доли мс на интервале в час - а это уже доли ppm или мс/сутки. По идее в этот процесс записи ни GPS ни NTP ни GSM ни другие методы коррекции хода времени вмешиваться не должны, но при желании это тоже можно проверить: играть на фоне (чтобы не заглушать сигналы точного времени) чистый синус частотой в кГц, тогда любой сбой синхронизации будет виден как ступенька на записанном звуке этого синуса или как изменение количества тиков на период синуса если коррекция была плавной.

Но зачем все эти заморочки так и не понятно. Вы же вывели что девайсы совпадают с точностью в единицы ppm, куда уж лучше. А на больших интервалах NTP гарантированно спасёт. Если хочется лучшей точности именно на секундных интервалах, то купите GPS с 1PPS выходом (вроде можно найти дешевле 1000р), подключите его через кондёр (и резисторный делитель) к звуковому входу и получите секундные импульсы с погрешностью дискретизации звука (сами 1PPS импульсы имеют точность или 1ppm, или 0.06ppm, зависит от GPS девайса). Ничего лучше в бытовых условиях не придумать. Если конечно не брать рубидиевые источники за 200$ с ebay.

[wrest]

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

Но зачем все эти заморочки так и не понятно. Вы же вывели что девайсы совпадают с точностью в единицы ppm, куда уж лучше.

Мне стало интересно почему системные часы в планшете на андроиде спешат по полсекунды в сутки (там чего-то в андроиде не так с синхронизацией по ntp - то ли она выключена и я не знаю где включить, то ли редко делается, короче часы спешат), но при этом при запуске на них программы-метронома программа часовой анализатор на айфоне показывает ноль (в пределах одной десятой на самом деле но одна десятая и пять - большая разница) отклонения в сутки. Как так? Моя теория -- "аудиочип" тактируется не тем источником, которым тактируются системные часы в этом планшете.

-- 26.02.2019, 16:19 --

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

Если хочется лучшей точности именно на секундных интервалах, то купите GPS с 1PPS выходом (вроде можно найти дешевле 1000р), подключите его через кондёр (и резисторный делитель) к звуковому входу и получите секундные импульсы с погрешностью дискретизации звука (сами 1PPS импульсы имеют точность или 1ppm, или 0.06ppm, зависит от GPS девайса). Ничего лучше в бытовых условиях не придумать. Если конечно не брать рубидиевые источники за 200$ с ebay.

При этом возможны несколько исходов.
1. Все гаджеты покажут ноль суточного отклонения. Что это будет значить? Вышеозначенный вопрос остается.
2. Не все гаджеты покажут ноль суточного отклонения. Что это будет значить и почему тогда они не показывают отклонения друг у друга?

То есть -- при любом исходе появятся новые вопросы. Смысл тогда покупать чего-то?

-- 26.02.2019, 16:42 --

Dmitriy40
Касательно периодической синхронизации с GPS и NTP. В теории всё замечательно. Наносекунды у GPS, десятки миллисекунд у NTP.

На практике же по-другому, потому что это еще зависит от программистов приложений.

Вот сейчас установил программу (android) GPS Time
И еще установлена программа (android) Clock Sync

GPS Time говорит что системные часы спешат на 2,077 секунды, а Clock Sync говорит что системные часы спешат на 1,254 секунды. Ну и кому верить?

Разное системное время на скриншоте потому, что эти программы не могут работать одновременно в сплите, тыкаешь на одну - работает одна, тыкаешь на другую - работает другая. Можно считать что
это просто два разных скриншота.

[Dmitriy40]

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

Как так? Моя теория -- "аудиочип" тактируется не тем источником, которым тактируются системные часы в этом планшете.

А доступ к NTP в это время отключен? А то программа-метроном вполне может измерять реальную частоту аудиочипа и корректировать щелчки метронома. Т.е. Ваше предположение не выполнится. Запишите звук щелчков метронома на том же девайсе в течении минут и просмотрите глазками сколько именно отсчётов проходит между щелчками - должно быть ровно 44100 или 48000 или сколько там выставили дискретизацию звука, вот тогда будет уверенность что аудиочип тактируется очень точно (если при этом отклонение показывает ноль).
А системное время по моему и не обязано идти точно по календарному, кому надо точнее - сам синхронизируется с внешним источником ("часовой" кварц в микросхеме календаря, сигнал базовой станции в GSM). Конечно это создаёт кучу проблем, но лишь для очень малого круга приложений.

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

Ну и кому верить?

Вообще говоря - никому. C GPS ошибка может быть до полусекунды -- это не 1PPS сигнал, это лишь NMEA сообщение о текущем времени, оно идёт каждую секунду, но не обязательно точно по границам секунд, да и доли секунды там указываются не очень понятно для какого момента (плюс буферизация потока). Я не верю что в смартфонах используется именно 1PPS сигнал, это просто не нужно для навигации.
Если Clock Sync работает по NTP (а других способов в общем и нет), то её погрешность будет немногим меньше времени пинга до NTP сервера (запустите пинг и проверьте сколько реально). И тогда верить лучше ей, в пределах указанной точности.
Ну и 0.8с вполне различимо на слух - поймайте сигналы точного времени по радио и сравните кто точнее.

-- 26.02.2019, 20:21 --

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

1. Все гаджеты покажут ноль суточного отклонения. Что это будет значить?

Что они все идут точно. По крайней мере те программы и аппаратные блоки, которые использовались для сравнения.

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

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

Это глюки в программах. В нормальной ситуации такого быть не должно.

[realeugene]

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

C GPS ошибка может быть до полусекунды -- это не 1PPS сигнал, это лишь NMEA сообщение о текущем времени, оно идёт каждую секунду, но не обязательно точно по границам секунд

Гугление мне подсказывает, что GPS приёмники часто (но не всегда) выдают 1 pps сигнал UTC-синхронизированным, т. е. точно по границе секунд.

[wrest]

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

Если Clock Sync работает по NTP (а других способов в общем и нет), то её погрешность будет немногим меньше времени пинга до NTP сервера (запустите пинг и проверьте сколько реально). И тогда верить лучше ей, в пределах указанной точности.

Да, тут я согласен. NTP это понятная технология, приложение само посылает запрос, само его получает так что "контролирует". Пинг, всё-тки, учитывается протоколом и потому должно быть не немного, а существенно точнее пинга. А вот как устроено gps мне непонятно, может чип там только nmea текстовое гонит и всё, я не в курсе.
Ну и опыт с айфоном показывает следующее. Когда б я не запустил приложение, которое показывает разницу ntp и системного времени, разница обычно в миллисекундах. Причем, с несколькими сеоверами на самом деле (приложение: http://emeraldsequoia.com/et/ ). Это на айфоне 6s. На айфоне 4s бывает поболее, т.е синхронизиркется заметно реже. Приложений которые показывают разницу системного времени и gps, для айфона я не нашел.

[Dmitriy40]

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

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

Пинг, всё-тки, учитывается протоколом и потому должно быть не немного, а существенно точнее пинга.

Существенно точнее оно возможно лишь если величина пингов предсказуема (пусть большая, но или предсказуемая, или точно измеримая/известная), только в этом случае его можно скомпенсировать точно. Реально же пакеты ходят разными путями и последовательные пинги могут отличаться в разы. Их разумеется сглаживают накоплением статистики и аппроксимируют (чем собственно NTP и занимается), но чтобы получить именно существенно лучше точность надо чтобы случайный разброс значений был мал. Для WiFi разброс обычно заметно больше (у меня для Lan разброс 5-6мс с очень редкими всплесками до 10-11мс, для WiFi разброс 6-11мс, причём всплески до 15-27мс каждые десяток запросов), для 2G/3G/4G думаю ещё больше (лень идти мерить). Так что точность 0.01с реальна, но уже близка к пределу.

[wrest]

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

Реально же пакеты ходят разными путями и последовательные пинги могут отличаться в разы.

Да с чего бы им разными путями-то ходить?

-- 26.02.2019, 23:21 --

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

Так что точность 0.01с реальна, но уже близка к пределу.

Усреднение же. Не ну правда, вот rtt у меня от 25 до 100мс, несколько серверов опрашиваются, разница в показаниях пара мс...

Но и 10мс тож неплохо вообще-то.

[Dmitriy40]

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

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

Реально же пакеты ходят разными путями и последовательные пинги могут отличаться в разы.

Да с чего бы им разными путями-то ходить?

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

[Pphantom]

У нас каждый очередной курс, доживший до астрометрической практики, стабильно интересуется вопросом о том, может ли NTP заменить хронометры/ГНСС (со сравнительно сложной процедурой сверки и прочими шаманскими действиями по определению поправки часов), и стабильно же получает примерно один и тот же результат: до 0.1 с все нормально (за вычетом разовых неудачных случаев, которые иногда все же встречаются), еще порядок получится, если сильно повезет. Еще лучше - совершенно нереально.