[kvv_spb 0]

Здравствуйте, подскажите плз. как лучше реализовать,

применительно к передачи E1 трафика поверх Ethernet:

приходят Ethernet пакеты

Задача на приёмной стороне выделить тактовую из этих пакетов.

восстановление планируется делать на FPGA Cyclone3.

[Mahagam 0]

эзернет - вещь пакетная. а прохождение пакетов через свитчи и прочие езернет-устройства и даже к "несущей" частоте эзернета не дадут привязаться.

как мне видится - только большой буфер и динамическая регулировка частоты.

[_pv 52]

Задача на приёмной стороне выделить тактовую из этих пакетов.

восстановление планируется делать на FPGA Cyclone3.

ieee 1588

 

эзернет - вещь пакетная. а прохождение пакетов через свитчи и прочие езернет-устройства и даже к "несущей" частоте эзернета не дадут привязаться.

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

[zltigo 0]

ieee 1588

Вы совсем не поняли о чем речь :(

 

 

Здравствуйте, подскажите плз. как лучше реализовать,

Никак. Обычно мирятся с проскальзываниями (выбрасывая/дублируя отсчеты). При этом канал сигнализации выделяют из потока и инкапсулируют в IP фреймы. Или используют глобальную синхронизацию GPS (это совершенно отдельная хорошо оплачиваемая тема), либо городите, как Вам тут уже намекали, подстройку ведомого по анализу проскальзований.

[kvv_spb 0]

как говорят RFC (5087,4553,5086,4197) тактовую можно выжелить несколькими способами(как я себе это понял):

выбелю 2 из них:

согласно RFC4197:

1.общая линия синхронизации <-- в моём случае недоступна=> вариант отпадает.

2 . В этом сценарии синхросигналы могут явно передаваться PE на входе устройству PE на выходе (например, с помощью RTP).

<-- так пишет RFC

как я понял (из анализа других RFC) тактовая выделяется из пакетов, по разнице времени их прихода и их кол-ва

хатя я сдесь не уверен....

[TU-104 0]

Подниму тему. Может за 6 лет появились какие-то готовые математические алгоритмы? Или еще какие-то идеи подскажут...

[krux 8]

а что там сложного?

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

на приемной стороне из заголовков RTP счетчик вынимается, по дельте за длинный промежуток определяется уход тактовой на N тактов на приемной частоте. приемная частота корректируется при помощи коэффициентов для DPLL.

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

[TU-104 0]

а что там сложного?

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

на приемной стороне из заголовков RTP счетчик вынимается, по дельте за длинный промежуток определяется уход тактовой на N тактов на приемной частоте. приемная частота корректируется при помощи коэффициентов для DPLL.

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

Ну если так, то вроде ничего сложного.

Просто думал, может, щас подскажут какие-то другие варианты... Например, измерить частоту(как в соседней ветке меряют), пусть с точностью +-1Гц, а на той стороне выставить эту базовую частоту и "гулять" в районе 2Гц. Как вариант.

[Corner 0]

Немного лучший метод используется в протоколах синхронизации для сетей с фиксированной архитектурой. Получатель копирует счетчик, когда тот меняется и возвращает отправителю. Отправитель меняет скорость счета, подгоняя фазу. Алгоритм чем-то похож на ФАПЧ с обратной связью. Время интегрирования тоже надо большое. Как минимум, больше максимальной задержки в сети. В пользовательских сетях работает не лучше варианта с одним счетчиком и может пойти в разнос.