Обновить

Комментарии 9

это зависит от частоты процессора 125МГц

125 МГц (125 Мбод) - это также символьная скорость протоколов 100BASE-X (Fast Ethernet, “медь” и “оптика”), протокола 1000BASE-T (Gigabit Ethernet, “медь”), частота блочного кодирования протокола 1000BASE-X (Gigabit Ethernet, “оптика”) и тактовая частота стыков GMII и RGMII (между чипами MAC-PHY).

Слова “Gigabit Ethernet” в тексте/картинках проскальзывают. Если не секрет, у вас какой физический протокол?

В основной массе используется 10GBASE-R. Конкретно в случае с приведенным примером у ACX2100 линки точно 10Г. Не исключаю, что причина в чем-то другом. Но АСХ точно страдает проблемами с точностью

10GBASE-R - это кодирование 64b/66b (IEEE 802.3ae, Cl. 49), то есть частота блочного кодирования 156,25 МГц или период 6,4 нс (не далеко от 8 нс), но там PHY и MAC фактически работают асинхронно “благодаря” вставке-исключению Idle-блоков между блоков с данными кадров (Idle symbols insertion and removal, см. 49.2.4.7). Поэтому ничего удивительного в том, что для опорной частоты PTP в таком случае выбирается частота, никак не связанная с частотой физического соединения. Взяли 125 МГц, получили шаг подстройки (квант) в 8 нс. Почему нет? Вроде, все честно.

Мне вот другое интересно. Вы, вроде как, описываете случай применения пакетных сетей в качестве mobile backhaul, если это так, зачем там такой точный PTP? Чтобы логи из разных мест хорошо сходились? Ведь для правильной работы базовых станций нужна лишь синтонизация, что уже обеспечивает SyncE, а фазовая-календарная синхронизация это лишь приятный бонус. Или нет?

В 2G, 3G, LTE FDD каждой базе условно выделена своя частота. В LTE TDD базовые станции могут вещать на одной частоте, но в разных тайм-слотах. Чтобы точно знать начало своего тайм-слота, фаза должна быть синхронизирована между соседними секторами. Очевидно, что если сектора не видят друг друга, то это требование становится факультативным, т.к. портить друг другу жизнь они не будут.

Про необходимость календарного времени не уверен, оно просто идет в нагрузку, т.к. PTPv2 строит процедуру частотной и фазовой синхронизации именно на основе календарного. Время для логов по-старинке берется с NTP-серверов.

Вот здесь хорошая брошюрка о требованиях к синхронизации современной и не очень мобилы

https://tf.nist.gov/seminars/WSTS/PDFs/2-2_Ericsson_Ruffini_Sync_in_MobileStandards_ruffini-rev3-tot.pdf

Приходилось ли сталкиваться при настройке с более редкими зверями, как там обстоят дела с возможностью посмотреть/настроить детально протоколы? Понятно что хуавей и джун это база, но интересно, используется ли у нас в магистралях(и оконечниках) китайский зоопарк и как с ним работается? Ну и возможно не только китайский, европейский тоже интересно)

Увы и ах, но нет, и неизвестно, когда такая возможность представится. Хотя, конечно, было бы интересно.

На Juniper полюбопытствуйте:

start shell pfe network feb0 на ACX2100. Там

show clksync ?

show ptp ?

test ptp ?

test clksync ?

debug clksync ?

Да, спасибо. Команды не так давно тоже вычитал на сайте джунипера, но проверить уже нет возможности, поэтому не знаю что они выдают и в статью не добавлял. Если у вас есть возможность прислать выводы с живых железок (совместно с sh ptp lock det) можно было бы их проанализировать и добавить в статью

На MX104:

start shell pfe network afeb0

Далее, всё тоже самое что и на ACX2100.

Для построения графика freq offset и/или phase offset можно воспользоваться конструкцией:

set protocols clock-synchronization traceoptions

Выводит в файл всё что связано (возможно в данном режиме) с синхронизацией.

В частности оба смещения. Плюс ошибки разного рода. И часть дебажной информации.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации