asteroid Опубликовано 24 июля, 2019 · Жалоба Добрый день. Планируем взять чужую ВОЛС. Вопрос, между OLT и множеством ONU будет присутствовать по пути оптический кросс с полировкой UPC. Избавиться от него никак. Насколько это может повлиять в целом на работу ВОЛС тракта? Там где стоят абонентские ONU там все механические соединения с полировками APC Но по пути, и достаточно близко от OLT присутствует один стык с UPC. Есть у кого опыт в этом? В целом оптический бюджет получается с большим запасом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pinkbyte Опубликовано 24 июля, 2019 · Жалоба Если оптический бюджет с запасом и везде используются правильные кроссировочные патчкорды, то есть НЕТ такого что если на кроссе полировка UPC, а используется патчкорд APC(или наоборот) - то проблем быть не должно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 24 июля, 2019 · Жалоба Если стыкуются разные типы полировок, то речи о нормальной работе вообще нет. UPC использовать нежелательно. И дело не столько в ослаблении, сколько в отражении, тут запас по бюджету мало чем поможет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nikita Devyatyarov Опубликовано 24 июля, 2019 · Жалоба 1 час назад, asteroid сказал: Добрый день. Планируем взять чужую ВОЛС. Вопрос, между OLT и множеством ONU будет присутствовать по пути оптический кросс с полировкой UPC. Избавиться от него никак. Насколько это может повлиять в целом на работу ВОЛС тракта? Там где стоят абонентские ONU там все механические соединения с полировками APC Но по пути, и достаточно близко от OLT присутствует один стык с UPC. Есть у кого опыт в этом? В целом оптический бюджет получается с большим запасом. Добрый день! Если CATV будет, тогда страшно. Если нет, тогда ничего страшного нет. При условии, что на стыке с UPC кроссом будет использован правильный патч-корд (как выше указал Pinkbyte ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
asteroid Опубликовано 24 июля, 2019 · Жалоба 3 hours ago, alibek said: Если стыкуются разные типы полировок, то речи о нормальной работе вообще нет. Та не, это надо уж совсем быть далеким от всего, что бы соединить стык UPC с APC. Это как то надо просто тыкать абы влезало. В лучшем случае повредим торец обоих феррул, и получим нерабочий линк. В худшем, отломим кусок феррулы, и то же получим нерабочий линк. Тут вопрос был про наличие по пути единственного правильного стыка FC-UPC - FC-UPC. ------------ Всем спасибо за ответы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 27 июля, 2019 · Жалоба @asteroid при наполнении порта более 50% возможны странное поведение Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 28 июля, 2019 · Жалоба 12 часов назад, pingz сказал: при наполнении порта более 50% возможны странное поведение Невозможно. И дело тут не в том, что обычно на таком стыке return loss около 40дб, и не в том, что чтобы сигнал переотразился в ONU (с затуханием уже в 80дб) таких стыков нужно два (т.к. прием и передача на разных длина волн). А еще и в том, что GPON по природе - TDM-сеть, и защитных интервалов там порядочно, ни о каких переотражениях речи уже не идет даже при полностью загруженом upstream. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 28 июля, 2019 · Жалоба @[anp/hsw] когда у нас начались проблемы с 60-90 клиентами на порт, мы переделали на apc проблем стало меньше с отвалом клиентского оборудования Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 28 июля, 2019 · Жалоба 4 часа назад, pingz сказал: мы переделали на apc проблем стало меньше с отвалом клиентского оборудования Как минимум, вы не просто меняли коннекторы, а еще и варили оптику, меняли прошивки, настройки, и вообще много вещей, которые обычно делают, пытаясь решить такую проблему. То, что вы ассоциируете проблему с UPC, не имеет под собой ничего общего с реальностью. Весь китай на UPC строится, и стандарт у них также 128 клиентов на дерево. (думаю, в численности китайцев, и что, что это дерево будет заполнено, также нет сомнений?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 28 июля, 2019 · Жалоба @[anp/hsw] с заменой на apc бюджет стал лучше, по 5-10 клиентов одновременно перестало отваливается. Обычные пользователи на это не жалуются, игроки жаловались. Вы правы прошивку меняли, но есть древо, где прошивки старые и таких проблем нет, но там утилизация на порт 25-40% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 29 июля, 2019 · Жалоба 5 часов назад, pingz сказал: с заменой на apc бюджет стал лучше А ведь он не мог стать лучше, если старая линия была в порядке: APC хоть и имеет меньшее обратное отражение, но также имеет и повышеное затухание стыка (типичное - 0.2дб, против 0.1дб в UPC). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 30 июля, 2019 · Жалоба @[anp/hsw] практика показывает при высоких уровнях сигнала лучше использовать apc З.ы. если чё я ещё варить умею не нужно мне про сварки сказки рассказывать т.к. в 98% виновата не сварка апарата, а укладка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 30 июля, 2019 · Жалоба 48 минут назад, pingz сказал: практика показывает при высоких уровнях сигнала лучше использовать apc можно более подробную статистику? уровни сигналов, количество перевареных коннекторов? в ктв конечно, APC необходим, но остальное высосано из пальца. -80дб там получается отраженка, т.к. WDM, а вот в ктв как раз -40, т.к. необходимо всего одно отражение, и выходная мощь усилителя поболее, что и вызывает самовозбуждение от отраженного сигнала с последущей деградацией качества. еще раз: весь китай построен на UPC, и все у них в порядке. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 31 июля, 2019 · Жалоба @[anp/hsw] eltex с модулями феномен С++, у худших клиентов сигнал от ону 28, к ону 23-24. Была ситуация, когда по 5-10 клиентов с порта отваливалось по не совпадению таймаутов(как я понял тдма) у нас есть два подобных древа, одно собрано первым, где был существующий кросс на upc примерно в 3 км, вторую уже аже всю собирал на apc бюджеты +/- одинаковые. Когда на первом перевалило за 50% начались проблемы с отвалом, на втором проблем не было. Меняли прошивки, меняли sfp, в итоге переварил в кроссе на новые upc реф показывал отражение(варил под контролем) переделали на apc отражение пропало, отвалы в таком количестве прикрепились. По поводу Китая и upc есть разница между GPON и GEPON, к примеру древа на bdcom, есть как upc, так и apc/upc проблем не было. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 1 августа, 2019 · Жалоба 12 часов назад, pingz сказал: ыла ситуация, когда по 5-10 клиентов с порта отваливалось по не совпадению таймаутов(как я понял тдма) Настолько все плохо, что точную ошибку не запомнили? LOSi? LOFi? DOW? Несовпадение "таймаутов" может быть только если кварц в ONU значительно съехал с рабочей частоты. Все остальные ошибки имеют другую природу и называются по-другому. 12 часов назад, pingz сказал: где был существующий кросс на upc примерно в 3 км, вторую уже аже всю собирал на apc бюджеты +/- одинаковые. Вы в предыдущем посте указали, что у вас сигналы улучшились при замене на APC, что в принципе не должно было произойти при грамотном монтаже, т.к. затухания на APC всегда больше. 12 часов назад, pingz сказал: Меняли прошивки, меняли sfp, в итоге переварил в кроссе на новые upc реф показывал отражение(варил под контролем) переделали на apc отражение пропало, отвалы в таком количестве прикрепились. Почему бы просто было не задать вопрос в техподдержку элтекс? Возможно, феррула разъем был повреждена (например втыканием APC-UPC через розетку). Но и APC при повреждении также будет давать отраженку. Чисто в теории два таких разьема (плохого качества, или поврежденные, тогда там может быть и -10 отраженка) на малом расстоянии друг от друга могут дать такой эффект. 12 часов назад, pingz сказал: По поводу Китая и upc есть разница между GPON и GEPON Я прекрасно знаю отличия. И их нет в данном конкретном случае, т.к. мы рассматриваем физику процесса. Есть очень ограниченое количество случаев, когда отраженка может на что-то влиять. Еще раз. Весь китай строит на UPC именно GPON. И GEPON строит. APC в PON появился исключительно потому, что его эксплуатация задумывалась в существующих сетях КТВ. Нету ВЧ КТВ - нету и APC. Загляните на любую барахолку в китае (да тот же aliexpress), и увидите, что устройств с APC значительно меньше, и стоят они дороже, т.к. предназначены только на экспорт. PS: Ах, да, в вашем любимом GPON OLT модуле C++, рекомендованом элтексом (да и во всех на самом деле), UPC полировка! Шах и мат! (а UPC там потому, что по обьективным причинам сигнал КТВ через этот стык не пойдет никогда) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pingz Опубликовано 2 августа, 2019 · Жалоба @[anp/hsw] мы разговариваем на разных языках, я вас понимаю вы скорее нет, полировка голове и конечном устройстве может быть любая. Но по мне лучше промежуточные делать apc(на моем языке в кроссах, кросс-муфтах), это субьюктивный и имперический опыт, где были не понятные ситуации с upc, переделывал на apc становилось лучше. У меня на bdcom, как чистый upc, так и смешанный. На eltex есть как чисто apc, так и смешанный связано, с тем, что нам дорого встанет влазить в чужой кросс. Но у меня, в данный момент всего устройство загруденно на 70-80%, и нам пришлось избавится от этого стыка на upc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[anp/hsw] Опубликовано 2 августа, 2019 · Жалоба 10 минут назад, pingz сказал: Но по мне лучше промежуточные делать apc(на моем языке в кроссах, кросс-муфтах), это субьюктивный и имперический опыт, где были не понятные ситуации с upc, переделывал на apc становилось лучше. Субьективно - да, делайте, что хотите, только за истину это не выдавайте. У вас заработало, вот и хорошо. Реальную картину, как оно все работает, я уже описал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AAS Опубликовано 6 августа, 2019 · Жалоба Как-то на GPON-е фиолетово какая у Вас полировка... главное чтобы не было некорректных соединений в одном адаптере (ну что-то типа SC/APC и SC/UPC). Мы у себя на станции ставим кроссы все FC/APC (так исторически сложилось)... а оборудование кроссируется переходным патчкордом (FC/APC - SC/UPC) или (FC/APC - LC/UPC). Со стороны клиента используем розетки с SC/UPC. Проблем нет с любой "утилизацией" порта хоть 25%... хоть 90% (там скорее проблемы начинаются, когда на одном дереве "зоопарк" из производителей ONU-шек у клиентов, приходится менять на одну модель при большой плотности на порту OLT). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...