Как реализовать точное время в сети из AVR с числом хопов не менее 4-х?
Имеется сеть девайсов. Конфигурация: иерархическая звезда. Пакет чтобы дойти до девайса самого нижнего уровня делает 4 хопа. Часы реального времени находяться в корневом узле иерархии. Время доставки пакета из коревого узла в узел, находящийся на самом нижнем уровне иерархии сосавляет от 2 до 30 секунд (в зависимости от загруженности сети)
Вопрос: как обеспечить , чтобы локальные часы (реализованные на базе таймера ATmega) на всех девайсах расходились друг относительно друга не более, чем на 0,5 Сек ?
Aheir писал(а):Возможна ли широковещательная рассылка?
Возможна... Но не чаще чем раз, примерно, в 10 Сек..
И при том время доставки этого широковещательного синхронизирующего пакета до самых периферийных узлов будет колебаться от 2 до 30 сек...
Потому что это время зависит с какого раза каждое устройство сможет захватить канал связи и сколько времени пакет находился в отстое в ОЗУ из-за того, что процессор был занят другой работой
ARV писал(а):по-моему, надо изучить протокол синхронизации времени интернета - и использовать заложенные там алгоритмы и приемы
Не стоит. Также не стоит использовать встроенные таймеры - есть ИС часов реального времени. Если требуется высокая точность, тогда нужно использовать эталонные часы или приёмник ГСЧВ для синхронизации локальных часов. Вспомните наши старые системы: первичные часы - вторичные часы.
Питаюсь копытными. Как исчезающий вид занесён в Красную книгу МСОП. Почему до сих пор не занесены в Красную книгу инженеры и учёные РФ?
ARV писал(а):странноватое ТЗ... не сеть, а тормоз какой-то - задержки до 30 сек... или девайсы тормоза...
А Вы попробуйте опросить мегой8 64 девайса (тоже сделанные на Меги8) и посмотрите сколько времени это у Вас займёт.
При том, что мега занимается не только приёмом/передачей. А ещё оцифровывает и ведёт логи показаний датчиков и генерит времянки для исплнительных устройств
и что, все эти логи-опросы настолько критично привязаны ко времени? т.е. миллисекунда-другая задержки недопустима? может, стоит пересмотреть физическую топологию сети или логическую (или обе вместе)? может, интерфейс сети следует поменять? это я к тому, что возможно, следует поискать решение "в обход"
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Согласен с ARV. Вообще-то не имеет смысл забивать сеть (я имею в виду промавтоматику) постоянно передаваемыми данными. Периферия должна работать самостоятельно, откликаться по командам и запросам с ведущего, самостоятельно выходить на связь только в экстренных случаях. Иначе, мы всё пытаемся взвалить на центр сети, забить каналы ненужной информацией и т.д. Кстати, в зависимости от времени и скорости тех процесса, даже в случае требований непрывного получения данный от периферии, есть возможность квантования по времени, что также позволит разгрузить сеть.
Вывод: пересмотреть организацию сети и необходимость непрерывного обмена данными.
Питаюсь копытными. Как исчезающий вид занесён в Красную книгу МСОП. Почему до сих пор не занесены в Красную книгу инженеры и учёные РФ?
ARV писал(а):и что, все эти логи-опросы настолько критично привязаны ко времени? т.е. миллисекунда-другая задержки недопустима?
Но почему же? Я же писал: не более 0,5 Сек между любыми двумя девайсами в сети (т.е. полчается допустим разбег аж в 125 мС на уровень - откуда Вы взяли 1-2мС?)
Прочитал все советы на форумах..Хочу, во-первых, сразу поблагодарить всех отвечавших.
А во-вторых, скажу, что остановился на методе попарной синхронизации иерархических уровней с организацией на каждом узле двух своих таймеров: счётчика микросекунд от момента включения и счётчика астрономического (или географического? Вообщем, как называется время, которое мы смотрим по наручным часам и по которому приходим на работу..Часы, минуты и т.п.) времени.
А вот 2-ю часть вопроса решил так, как никто мне не предложил. И это решение не зависит от того, какой длины пакет передаётся и с какой скоростью. И при этом позволяет обеспечить наилучшую точность синхронизации..
Сделал что-то похожее с протоколом RTCP, метод синхронизации в котором мне любезно описал defunct.
Но с принципиальными отличиями
1)Каждое устройство, находящиеся не на самом нижнем уровне иерархии становиться сервером географического времени для находящихся на следующем за ним иерархическом уровне устройств. Т.е. сервер времени не один - их много. Таким образом не один сервер географического времени обслуживает 200 с лишним устройств всей сети (как в случае централизованного случая с одним выделенным сервером), а несколько серверов и каждый обслуживает не более 16-ти девайсов соседнего нижнего уровня..
2)Слэйв посылая пакет хосту запоминает его ID и значение своего RTC на момент первого переднего фронта передаваемого пакета
3)Каждый хост получая пакет от слейва в буфере приёмника, куда он будет класть этот пакет, сохраняет также значение RTC на момент первого переднего фронта принимаемого пакета
4)Хост в пакет-ответ слэйву загружает ID пакета-слэйва, ответом на который является этот пакет и значение своего RTC на момент первого переднего фронта принятого пакета, на который он отвечает
5) Слэйв, получив пакет-ответ, видит разницу своего RTC и RTC хоста на момент 1-го фронта переданного слэйвом пакета, а также видит за сколько времени эта дельта "набегает"(используя данные предыдущей синхронизации). А уж тут, как говориться, вариантов море. Можно например найти коэффициент "разбега" часов: т.е. слэйв сможет вычислить насколько убегают/отстают его часы от часов хоста в единицу своего локального времени.
В этом решении, конечно же, много важных нюансов, без которых оно работать не будет, но описание их всех займёт слишком много места (не буду злоупотреблять терпением модераторов (:-)))
Но факт, что проанализировав все данные и возможности железа и алгоритма я пришёл к выводу, что данное решение самое простое и в то же время самое функциональное для моей задачи.
Ещё раз благодарю всех ответивших.
Тема закрыта
Последний раз редактировалось Дон Амброзио Сб мар 08, 2008 11:07:50, всего редактировалось 1 раз.
Дон Амброзио писал(а):на момент первого переднего фронта передаваемого пакета
Так практически никогда в автоматике не делается. В автоматике системы живут и работают по времени (в случае необходимости) первичных эталонных часов, вероятно имеющими синхронизацию от приёмника ГСЧВ.
И ещё раз повторюсь, насколько необходима связь с гражданским временем в промышленной системе автоматики? В подавляющем большинстве случаев она не требуется.
Питаюсь копытными. Как исчезающий вид занесён в Красную книгу МСОП. Почему до сих пор не занесены в Красную книгу инженеры и учёные РФ?
В автоматике системы живут и работают по времени (в случае необходимости) первичных эталонных часов, вероятно имеющими синхронизацию от приёмника ГСЧВ.