|
Сообщение от Popeye
|
|
Таких пакетов достаточно раз в день, если все стабилизировано кварцами.
|
В сутках 86400 секунд. Мне нужен "разбег" часов не более чем 0,5 сек. 0,5 делим на 86400 получается дельта равна 0,0006% И Вы думаете это так легко обеспечить, чтобы на любых двух девайсах сети тактовая частота MCU при любой рабочей температуре отличалась не более чем на 0,0006%?
Прочитал все советы на форумах..Хочу, во-первых, сразу поблагодарить всех отвечавших.
А во-вторых, скажу, что остановился на методе попарной синхронизации иерархических уровней с организацией на каждом узле двух своих таймеров: счётчика микросекунд от момента включения и счётчика астрономического (или географического? Вообщем, как называется время, которое мы смотрим по наручным часам и по которому приходим на работу..Часы, минуты и т.п.) времени.
А вот 2-ю часть вопроса решил так, как никто мне не предложил. И это решение не зависит от того, какой длины пакет передаётся и с какой скоростью. И при этом позволяет обеспечить наилучшую точность синхронизации..
Сделал что-то похожее с протоколом RTCP, метод синхронизации в котором мне любезно описал defunct.
Но с принципиальными отличиями
1)Каждое устройство, находящиеся не на самом нижнем уровне иерархии становиться сервером географического времени для находящихся на следующем за ним иерархическом уровне устройств. Т.е. сервер времени не один - их много. Таким образом не один сервер географического времени обслуживает 200 с лишним устройств всей сети (как в случае централизованного случая с одним выделенным сервером), а несколько серверов и каждый обслуживает не более 16-ти девайсов соседнего нижнего уровня..
2)Слэйв посылая пакет хосту запоминает его ID и значение своего RTC
на момент первого переднего фронта передаваемого пакета
3)Каждый хост получая пакет от слейва в буфере приёмника, куда он будет класть этот пакет, сохраняет также значение RTC на момент первого переднего фронта принимаемого пакета
4)Хост в пакет-ответ слэйву загружает ID пакета-слэйва, ответом на который является этот пакет и значение своего RTC на момент первого переднего фронта принятого пакета, на который он отвечает
5) Слэйв, получив пакет-ответ, видит разницу своего RTC и RTC хоста на момент 1-го фронта переданного слэйвом пакета, а также видит за сколько времени эта дельта "набегает"(используя данные предыдущей синхронизации). А уж тут, как говориться, вариантов море. Можно например найти коэффициент "разбега" часов: т.е. слэйв сможет вычислить насколько убегают/отстают его часы от часов хоста в единицу своего локального времени.
В этом решении, конечно же, много важных нюансов, без которых оно работать не будет, но описание их всех займёт слишком много места (не буду злоупотреблять терпением модераторов (
))
Но факт, что проанализировав все данные и возможности железа и алгоритма я пришёл к выводу, что данное решение самое простое и в то же время самое функциональное для моей задачи.
Ещё раз благодарю всех ответивших.
Тема закрыта
?... типа самому догадливому ))) 
а вы уже и отказываетесь озгами пошевелить 
