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

[wrest]

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

А почему собственно разный offset у stratum 1/2 серверов, а?

Тут надо науку и технологию точно понимать, а я не понимаю. "Выдающийся" офсет на скриншоте в 25мс против 12-13мс у других серверов подмечен видимо у далекого (территориально) сервера 0.pool.ntp.org. Как в этом смысле устроено соглашение о времени я не знаю - просветите? Ведь программа не знает, что до сервера 3000 километров, которые свет проходит за 10мс, и что из rtt в 72мс, 20мс составляют именно эти 3000км туда и столько же обратно. Ну это домыслы мои, рад буду услышать правильную трактовку.

-- 27.02.2019, 14:49 --

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

Ну и померить температуру кристалла кварца не так уж просто, если нужны доли градуса.

Ну вы раньше не про доли писали, а про целые градусы ;) Урежьте осетра.

[Dmitriy40]

Да мне осётра не жалко, просто Вы плохо понимаете сложность и стоимость разработки устройства с такой точностью. И пока непонятно зачем так париться разработчикам, ради каких преимуществ в работе девайса - они и не будут.
Насчёт погрешности в градус. Вокруг +25°С градус погрешности даст погрешность времени в 0.04ppm (берём часовой кварц как более точный). А вот вокруг +35°С (часы на руке) та же самая погрешность в градус даст уже $((36-25)^2-(35-25)^2)\cdot0{,}04=0{,}84$ppm, в 20 раз больше. Вот вам и градус.
Да, можно принять что температура кристалла отличается от температуры корпуса и платы не более чем на треть градуса (тем более при таких слабых тепловых потоках и градиентах и малом саморазогреве кварца) и измерять лишь последнюю и это вполне будет работать при температурах вокруг какой-то точки калибровки - и только около неё.

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

Как в этом смысле устроено соглашение о времени я не знаю - просветите?

Да чего тут сложного, offset это очевидно разница между вашим временем (на устройстве) и временем сервера, полученная методом вычислений, а вовсе не со световой скоростью. Вот тут в вики в самом конце последняя таблица и формулы под ней, всё доступно и понятно. На странице про NTP есть и картинка запроса/ответа сервера. А теперь вспоминаете что (T2-T1) и (T4-T3) вовсе не обязательно равны и подвержены независимым флуктуациям из-за принципа работы сети - и получаете разброс величины t, которая в программе названа offset. При идеальном прохождении сигналов до и от NTP сервера все offset должны совпадать - ведь серверы синхронизированы между собой намного точнее (мкс и доли мкс). Грубо говоря Вы смотрите на одни и те же часы, но из разных окон - и почему-то видите немного разное смещение одних и тех же часов от своих. Не должно быть такого (при условии правильной программы) - если только не вмешивается неидеальность канала связи, о чём и толкуем.

[wrest]

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

Да чего тут сложного, offset это очевидно разница между вашим временем (на устройстве) и временем сервера, полученная методом вычислений,

Я про другое. Если вы слушаете ваши "сигналы точного времени" по радио на расстоянии 3000 километров от радиовышки
, то сигналы приходят к вам с запаздыванием в 10мс. Вопрос: если вы знаете об этом расстоянии, надо ли вам подкрутить часы на 10мс?

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

ведь серверы синхронизированы между собой намного точнее (мкс и доли мкс).

Ну вот я и спрашиваю что конкретно это значит, что серверы разнесенные на расстояние 10 световых миллисекунд, синхронизированы до микросекунд. Я просто не знаю что это такое.

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

Грубо говоря Вы смотрите на одни и те же часы, но из разных окон - и почему-то видите немного разное смещение одних и тех же часов от своих.

Ну дык если расстояние от вас до разных часов 0 и 10 световых миллисекунд (но вы не знаете этих расстояний) или это одни часы, но свет идёт до них из разных окон с разницей в 10мс, то и увидите, что часы в одном окне отстают от часов в другом на 10 миллисекунд.
В протоколе NTP же наверное предполагается, что сервер NTP физически стоит в соседней комнате, а всю задержку прохождения пакета создают сетевые устройства...

[Dmitriy40]

Вот для примера пара логов запросов к NTP серверам с компа по lan:

Используется синтаксис Text

C:\>w32tm /monitor /nowarn /computers:0.ru.pool.ntp.org,1.ru.pool.ntp.org,2.ru.pool.ntp.org,3.ru.pool.ntp.org
0.ru.pool.ntp.org[95.31.45.148:123]:
    ICMP: 10ms задержка
    NTP: +0.0061482s смещение относительно локального времени
        RefID: 'PPS [0x00535050]
        Страта: 1
1.ru.pool.ntp.org[212.13.97.55:123]:
    ICMP: 9ms задержка
    NTP: +0.0069651s смещение относительно локального времени
        RefID: ntp.ix.ru [194.190.168.1]
        Страта: 2
2.ru.pool.ntp.org[85.21.78.23:123]:
    ICMP: 9ms задержка
    NTP: +0.0040576s смещение относительно локального времени
        RefID: ntp0.rrze.uni-erlangen.de [131.188.3.220]
        Страта: 2
3.ru.pool.ntp.org[80.93.50.95:123]:
    ICMP: 64ms задержка
    NTP: +0.0309471s смещение относительно локального времени
        RefID: time100.stupi.se [192.36.143.130]
        Страта: 2

График флуктуаций времён для NTP stratum 1:

Используется синтаксис Text

C:\>w32tm /stripchart /computer:95.31.45.148 /period:3 /samples:20
Отслеживание 95.31.45.148 [95.31.45.148:123].
Сбор образцов 20.
Текущее время - 27.02.2019 16:15:26.
16:15:26 d:+00.0069457s o:+00.0015842s  [                           *                           ]
16:15:29 d:+00.0079452s o:+00.0017248s  [                           *                           ]
16:15:33 d:+00.0089435s o:+00.0009311s  [                           *                           ]
16:15:36 d:+00.0079058s o:+00.0015435s  [                           *                           ]
16:15:39 d:+00.0079430s o:+00.0013699s  [                           *                           ]
16:15:42 d:-00.0000544s o:-00.0130227s  [                           *                           ]
16:15:45 d:-00.0000564s o:-00.0128111s  [                           *                           ]
16:15:48 d:+00.0089438s o:+00.0006423s  [                           *                           ]
16:15:51 d:+00.0099448s o:-00.0002588s  [                           *                           ]
16:15:54 d:+00.0079437s o:+00.0011363s  [                           *                           ]
16:15:57 d:+00.0129446s o:+00.0032214s  [                           *                           ]
16:16:00 d:+00.0079265s o:+00.0013803s  [                           *                           ]
16:16:03 d:+00.0079429s o:+00.0014709s  [                           *                           ]
16:16:06 d:+00.0079412s o:+00.0009013s  [                           *                           ]
16:16:09 d:+00.0079033s o:+00.0013290s  [                           *                           ]
16:16:12 d:-00.0000738s o:-00.0123225s  [                           *                           ]
16:16:15 d:-00.0000552s o:-00.0123624s  [                           *                           ]
16:16:18 d:-00.0000709s o:-00.0121263s  [                           *                           ]
16:16:21 d:-00.0000539s o:-00.0030334s  [                           *                           ]
16:16:24 d:+00.0080000s o:-00.0040000s  [                           *                           ]

Видите как гуляет и время прохождения пакетов (d) и смещение локального времени (o)?
Это можно дальше усреднять, накапливать статистику, наворачивать хитрую математику, но флуктуации всё равно останутся, и на больших интервалах (а не минута как выше) они особо меньше так и не станут.

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

Я про другое. Если вы слушаете ваши "сигналы точного времени" по радио на расстоянии 3000 километров от радиовышки, то сигналы приходят к вам с запаздыванием в 10мс. Вопрос: если вы знаете об этом расстоянии, надо ли вам подкрутить часы на 10мс?

Надо разумеется. NTP протокол именно этим и занимается, высчитывает время прохода пакетов туда и обратно и пытается вычесть/добавить это время из показаний сервера.

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

Ну вот я и спрашиваю что конкретно это значит, что серверы разнесенные на расстояние 10 световых миллисекунд, синхронизированы до микросекунд. Я просто не знаю что это такое.

Верну Вам ваш же вопрос: ну и что тут такого, в чём проблема? Спутники GPS/ГЛОНАСС идут синхронно с точностью в тысячные ppm и ничего. И переносные эталоны частоты с коррекцией по GPS за несколько часов подстройки вполне выходят на точность $10^{-8..-9}$ (те же сотые-тысячные ppm), т.е. подстраиваются точно под время GPS с погрешностью в наносекунды.

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

В протоколе NTP же наверное предполагается,

Не предполагается. Почитайте уж всего две вики странички (NTP и SNTP), там всё просто и понятно.

-- 27.02.2019, 16:42 --

Смешно: отрицательные значения параметра d в логах выше это типа ответ пришёл на десятки мкс раньше запроса ... На самом деле конечно нет, просто большие погрешности фиксации времени ухода и прихода пакетов, и 99% что на моей стороне, всё же винда дело такое, и близко не realtime.

[wrest]

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

Надо разумеется. NTP протокол именно этим и занимается, высчитывает время прохода пакетов туда и обратно и пытается вычесть/добавить это время из показаний сервера.

Я вам про относительность одновременности, а вы мне про хопы маршрутизации...

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

На самом деле конечно нет, просто большие погрешности фиксации времени ухода и прихода пакетов,

Ну так чего на канал-то пенять, если у вас венда тормозит?

У себя ничего подобного не наблюдаю. Всё стабильно

(Оффтоп)

C:\>w32tm /monitor /nowarn /computers:0.ru.pool.ntp.org,1.ru.po
ol.ntp.org,2.ru.pool.ntp.org,3.ru.pool.ntp.org
0.ru.pool.ntp.org[85.21.78.23:123]:
    ICMP: 3ms задержка
    NTP: +0.5979572s смещение относительно локального времени
        RefID: ntp3.rrze.uni-erlangen.de [131.188.3.223]
        Страта: 2
1.ru.pool.ntp.org[195.3.252.123:123]:
    ICMP: 11ms задержка
    NTP: +0.6079547s смещение относительно локального времени
        RefID: web.indico.ru [80.93.50.95]
        Страта: 3
2.ru.pool.ntp.org[192.36.143.130:123]:
    ICMP: ошибка IP_REQ_TIMED_OUT - нет ответа в 1000ms
    NTP: +0.5978515s смещение относительно локального времени
        RefID: 'PPS [0x00535050]
        Страта: 1
3.ru.pool.ntp.org[82.199.107.209:123]:
    ICMP: 3ms задержка
    NTP: +0.5998161s смещение относительно локального времени
        RefID: 'GNSS' [0x53534E47]
        Страта: 1

C:\>w32tm /stripchart /computer:82.199.107.209 /period:3 /sampl
es:20
Отслеживание 82.199.107.209 [82.199.107.209:123].
Сбор образцов 20.
Текущее время - 27.02.2019 17:14:38.
17:14:38 d:+00.0049702s o:+00.6061030s  [                           | *                ]
17:14:41 d:+00.0039688s o:+00.6066128s  [                           | *                ]
17:14:44 d:+00.0039627s o:+00.6070940s  [                           | *                ]
17:14:47 d:+00.0039692s o:+00.6070568s  [                           | *                ]
17:14:50 d:+00.0039700s o:+00.6075132s  [                           | *                ]
17:14:53 d:+00.0039597s o:+00.6075097s  [                           | *                ]
17:14:56 d:+00.0049718s o:+00.6071150s  [                           | *                ]
17:14:59 d:+00.0029690s o:+00.6078514s  [                           | *                ]
17:15:02 d:+00.0029717s o:+00.6084486s  [                           | *                ]
17:15:05 d:+00.0029608s o:+00.6085485s  [                           | *                ]
17:15:08 d:+00.0029679s o:+00.6091023s  [                           | *                ]
17:15:11 d:+00.0039571s o:+00.6082127s  [                           | *                ]
17:15:14 d:+00.0039693s o:+00.6088805s  [                           | *                ]
17:15:17 d:+00.0039580s o:+00.6092833s  [                           | *                ]
17:15:20 d:+00.0029686s o:+00.6096919s  [                           | *                ]
17:15:23 d:+00.0039571s o:+00.6094493s  [                           | *                ]
17:15:26 d:+00.0029692s o:+00.6101090s  [                           | *                ]
17:15:29 d:+00.0029628s o:+00.6101148s  [                           | *                ]
17:15:32 d:+00.0039697s o:+00.6100595s  [                           | *                ]
17:15:35 d:+00.0030000s o:-00.0015000s  [                           *                  ]

C:\>

[Dmitriy40]

СТО/ОТО в Ethernet, ну-ну ... Нет, это я обсуждать не намерен. Есть рабочий пример: GPS, на расстояниях в десяток тысяч км (между спутниками) часы идут синхронно с точностью в тысячные ppm.
К NTP технологии это уже не относится (хотя она вполне может это всё учитывать автоматически). К точности времени/кварцев в планшетах и телефонах тем более (а в радиотракте как раз и компенсируется время прохождения сигнала до базовой станции).

[wrest]

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

СТО/ОТО в Ethernet, ну-ну ...

Дык я ж говорю - ежели NTP сервер на расстоянии 3000 километров, свет до него идет 10мс... Куда от этого деться?
Если не читали -- есть древняя (я первый раз читал году примерно в 1997 не помню. Может, в 2000-м... но очень давно) "городская легенда" про e-mail, который не ходит дальше 500 миль: http://web.mit.edu/jemorris/humor/500-miles
Рекомендую...

-- 27.02.2019, 17:22 --

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

К точности времени/кварцев в планшетах и телефонах тем более (а в радиотракте как раз и компенсируется время прохождения сигнала до базовой станции).

Это относится к ловле десятков миллисекунд на нескольких минутах.
Но я согласен - дебри уже.

[Dmitriy40]

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

Дык я ж говорю - ежели NTP сервер на расстоянии 3000 километров, свет до него идет 10мс... Куда от этого деться?

Как куда? NTP запрос послать, а по получению ответа по простейшей формуле вычесть эту вычисленную задержку. Снова отошлю к русской вики про SNTP, самый конец (а лучше даже прямо вот тут посмотреть). Для сравнения: у меня пинг до ru.pool.ntp.org порядка 6мс, до us.pool.ntp.org порядка 145мс, а до au.pool.ntp.org и вовсе 340мс -- и ничему это не мешает, смещение времени так и остаётся меньше 10мс.

[wrest]

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

а до au.pool.ntp.org и вовсе 340мс -- и ничему это не мешает, смещение времени так и остаётся меньше 10мс.

А я вижу, что смещение разное. С сервером в Австралии (13.55.50.68) у меня смещение примерно на 12мс больше чем с сервером в Москве (82.199.107.209). Хотя это и не покрывается, конечно, тем, что от Москвы до Австралии 35 световых миллисекунд напрямки (по поверхности немного больше - 42мс).

[Dmitriy40]

Могу лишь повторить что скорость света тут ни при чём, другие задержки на порядки больше. Хотя корреляция задержки с расстоянием разумеется есть (из-за разного количества оборудования по пути).
С 13.55.50.68 у меня пинги 370-430мс, смещение прыгает от -8 до +23мс, среднее указать затрудняюсь, где-то около +5мс.
С 82.199.107.209 пинги 7мс, смещение за минуту плавно росло от -0.3мс до -3мс, потом прыгает 3±0.5мс.

[Pphantom]

Было очень интересно прочитать, о чем именно я писал , для определенности уточню, что изложение Dmitriy40 с моим представлением о том, что я писал, согласуется существенно лучше.

[Dmitriy40]

Добавлю чужой график работы ntpd (сервис подстройки времени по NTP серверам), сравнение WiFi vs Lan: http://www.satsignal.eu/ntp/Win-7-Wi-Fi-vs-LAN.html
У меня когда его использовал смещение удерживалось в рамках +0..+5мс, с редкими выбросами до ±20мс (очевидно выбросы были не реальной частоты, а процедуры опроса сервера), контроль был не им самим, а сторонней программой, потому и точность ниже. Без всякой коррекции время уходит практически линейно на +60мс/ч (+17ppm), это к слову о начальной точности кварцев (в компьютере в данном случае).

[wrest]

Dmitriy40
Пишут про радикальную разницу: 3мс джиттер на вайфае и 1мс на ethernet :)

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

Без всякой коррекции время уходит практически линейно на +60мс/ч (+17ppm), это к слову о начальной точности кварцев (в компьютере в данном случае).

Да, сегодняшние заезды на венде (моей) показали тихий ужос по сравнению с гаджетами.
Так что на венде я пожалуй часы мерить не буду.
Хотя надо б метроном запустить, глянуть. Может все-тки "часовой" кварц не используется для тактирования в аудио (в венде компе).

[Dmitriy40]

Угу, вот потому мне и не очень понятно влияние джиттера на точность хода и синхронизации, видимо надо смотреть спектральные параметры джиттера (почему он недостаточно случаен чтобы усредниться в ноль). А вот на первых двух картинках разницу вижу и она существенна, не в три раза, а на порядок (с 3мс до 0.2мс).

[wrest]

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

почему он недостаточно случаен чтобы усредниться в ноль)

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