Имеется сеть девайсов. Конфигурация: иерархическая звезда. Пакет чтобы дойти до девайса самого нижнего уровня делает 4 хопа. Часы реального времени находяться в корневом узле иерархии. Время доставки пакета из коревого узла в узел, находящийся на самом нижнем уровне иерархии сосавляет от 2 до 30 секунд (в зависимости от загруженности сети)

Вопрос: как обеспечить , чтобы локальные часы (реализованные на базе таймера ATmega) на всех девайсах расходились друг относительно друга не более, чем на 0,5 Сек ?

Можно пойти путем RTCP (real-time control protocol):
Завести два таймера во всех устройствах сети, один для RTC, второй - системный (независимый).
Системный таймер не привязан к реальному времени, но тикает точно (скажем с интервалом 1ms).

Далее пусть есть некий Хост (X) на котором задано точное реальное время, и Slave (S) RTC которого надо синхронизировать с Х.

Процедуру синхронизации можно сделать так:
1. S посылает синхропакет с показаниями своего системного таймера.
2. X отправляет этот пакет обратно, добавив к нему показания своего системного таймера и своего RTC.
3. S получает пакет от X, вычисляет Round-trip-delay, но основе текущего значения системного таймера и данных своего системного таймера в пришедшем пакете.

4. S делит round-trip-delay пополам, прибавляет получившееся число к значению RTC от Host'a и записывает в свой RTC.

5. S шлет к X принятый пакет, добавляя в него показания своего RTC и системного таймера.
6. X вычисляет Round-trip-delay на основе показаний своего системного таймера, прибавляет 1/2 от этого числа к показаниям RTC от S и если ошибка будет в допустимых пределах, уведомляет S о том, что синхронизация прошла успешно и расчитанную ошибку на своей стороне.

На этом процедура синхронизации заканчивается.

И так раз в сутки-час-минуту, чем чаще будете синхронизироваться тем меньше будет ошибка.

Дохтур, вас это точно интересует или вы опять бла-бла-бла? Если интересует, то можно сделать так.

1) Ввести в протокол обмена понятие широковещательного пакета, типа, "всем молчать, получить точное время". Действует только от узла до субузла.

2) Сначала синхронизируются узлы одного уровня. Погрешность 1 мс.

3) Затем каждый узел синхронизирует следующий уровень. Погрешность 2 мс.

и т.д.

Для пожарной сигнализации самое то.

Только не понятно зачем гонять "туда и обратно" значение своего системного таймера когда его можно просто запомнить "у себя"? Или это значение просто служит уникальным ID пакета?

Потом находить время следования пакета путём деления пополам "времени одного оборота" не корректно... У меня пакет "туда" может добираться 2 сек, а "обратно" - 30 сек (или наоборот)..

Потом у меня слейвов более 200 штук (на самом нижнем уровне иерархии). Так что хост "захлебнётся" от кучи запросов синхронизации от слэйвов


Мне не телесистемах предложили такие варианты с использованием счётчика времени транспорта пакета (как счётчик времени жизни в интернетовских пакетах). Проблемно сделать.. Потому что во-первых, нужно считать как время отстоя пакета в озу так и время переползания из озу одного контроллера в озу другого.. А во вторых, надо в пакете предусматривать соответсвующее поле для хранения времени транспорта... А если измениться это поле, то надо заново пересчитывать CRC.. Кроче целая куча проблем

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

А это на что:

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

На этом этапе пока всё понятно.. Более того, сам думаю в том же направлении



А вот это непонятно.

Чтобы объяснить моё недоумение приведу конкретные цифры:
- максимальное время передачи одного байта 6-10 мСек (в зависимости от количества '0' и '1' в байте - сигнал кодируется шириной импульса низкого уровня)
- максимальная длина пакета 36 байт.
- в программе девайсов есть критические секции из-за чего устройство может становиться "глухим" на время до 0,6 сек
- Даже если разброс частот тактовых генераторов во всём диапозоне рабочих температур не превосходит 1%, то при синхронизации каждые 10 секунд мы получим, что за 10 сек "небегает" 100мСек разброса - откуда 1 мС?


Вот за это спасибо... Я чёта до этого не допетрил :-) Бум знать



А почему Вы думаете, что я глупей изобретателей протокла RTCP?
А потом, но будет у меня хост до посинения уведомлять "синхронизация FAILED!!" и что? Мне от этого легче... А потом отвечать каждому из более чем 200 слэйвов? У меня пропускной способности-то не хватит не говоря уже о том, что хост тогда будет занят только тем, что отвечать на синхронизационные пакеты слэйвов

Мало данных.
1. На какой технологии построена сетка? (RS485, Ethernet, ...)
2. Если RS485, то на какой скорости работает?
3. Устройства, которые обусловливают хопы, -- это ваши устройства или покупные?
4. Как вы их называете? Свитчи? Раутеры? Шлюзы?
5. Можете ли вы изменять ПО этих устройств?
6. Вы указали расхождение часов в 0.5 с, но Вы не указали время, за которое эти полсекунды могут набежать. Одно дело за 10 минут, и другое -- за сутки.
7. Какая конечная цель иметь синхронное время на слейвах? Т.е. для чего это надо? (Может задачу надо решать не в этом направлении?)

Не имея четкого представления от положении вещей, невозможно дать правильный совет.

Каналы "выход девайса - открытый коллектор; линия через подтяг.рез. к +5В". Топология подсеток "общая магистраль".. Общая топология сети "иерархическая звезда"


Нет.. Не RS485.. Несимметричная однопроводная линия...Кодирование шириной импульса..Гальван.развязки нет


Свои и программу в них моя


Да наверно нельзя их так назвать если подходить строго академически


Ответил выше


Чтобы в любой момент времени разница показаний двух любых локальных часов была не более 0,5сек


Нужно включать два и более реле с рассинхронизацией во времени не более чем 1 Сек (передаём соответствующим девайсам во сколько времени нужно включить управляемое ими реле и... они включают синхронно.. с расхождением во времени не более 1 сек).
Железо дорабатывать/изменять/добавлять НЕЛЬЗЯ

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


Подпрограмма, которая принимает ваш пакет, может легко учесть время, затраченное на приём. Ещё легче это может сделать узел, который передаёт пакет со временем.


Передавайте два пакета с временным разрывом в 0,6 с. Один из них гарантированно будет принят.


Вы мух от котлет отделяйте всё-же. У меня речь идёт об ошибке передачи времени от узла к узлу или от узлу к устройству, а не об ошибке хранения времени в конкретном устройстве.

Да и эту 1 мс я взял с потолка, если постараться, то можно довести до 1-10 мкс, смотря по тому какие у вас фронты сигналов в линии передачи.

Вот это видимо самый критичный момент во всей проге, ну такого, 0,6сек просто быть не должно,
покажите чем у Вас все это время занят проц...

Прочитал все советы на форумах..Хочу, во-первых, сразу поблагодарить всех отвечавших.
А во-вторых, скажу, что остановился на методе попарной синхронизации иерархических уровней с организацией на каждом узле двух своих таймеров: счётчика микросекунд от момента включения и счётчика астрономического (или географического? Вообщем, как называется время, которое мы смотрим по наручным часам и по которому приходим на работу..Часы, минуты и т.п.) времени.

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

Сделал что-то похожее с протоколом RTCP, метод синхронизации в котором мне любезно описал defunct.

Но с принципиальными отличиями

1)Каждое устройство, находящиеся не на самом нижнем уровне иерархии становиться сервером географического времени для находящихся на следующем за ним иерархическом уровне устройств. Т.е. сервер времени не один - их много. Таким образом не один сервер географического времени обслуживает 200 с лишним устройств всей сети (как в случае централизованного случая с одним выделенным сервером), а несколько серверов и каждый обслуживает не более 16-ти девайсов соседнего нижнего уровня..
2)Слэйв посылая пакет хосту запоминает его ID и значение своего RTC на момент первого переднего фронта передаваемого пакета
3)Каждый хост получая пакет от слейва в буфере приёмника, куда он будет класть этот пакет, сохраняет также значение RTC на момент первого переднего фронта принимаемого пакета
4)Хост в пакет-ответ слэйву загружает ID пакета-слэйва, ответом на который является этот пакет и значение своего RTC на момент первого переднего фронта принятого пакета, на который он отвечает
5) Слэйв, получив пакет-ответ, видит разницу своего RTC и RTC хоста на момент 1-го фронта переданного слэйвом пакета, а также видит за сколько времени эта дельта "набегает"(используя данные предыдущей синхронизации). А уж тут, как говориться, вариантов море. Можно например найти коэффициент "разбега" часов: т.е. слэйв сможет вычислить насколько убегают/отстают его часы от часов хоста в единицу своего локального времени.

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

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

Ещё раз благодарю всех ответивших.

Тема закрыта