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