Перейти до

GEPON в FTTB


Tornight

Рекомендованные сообщения

 

 

 

Ну не знаю, я бы ещё 5-ти этажки подумал ... по 1 ону на подьезд ... а вообще за онушкой желательно управляшку или хоть смартик .... Хотя выиграша тады мало ...

 

Ну вот в чем профит? Ну хоть убейте не пойму. В экономии волокон? 

 

Профита нету. Вопрос ж был о том возможно или нет. Возможно, только нужно иметь 2.5 гиг в канале к ону, ибо 1гиг звери забью в хлам. А профита нету, фттб в много этажках пока имхо хер переплюнешь. 

 

Насколько я знаю 2,5 Гиг (кстати обратка всего-то 1 гиг) - это теория.

И, поправьте если я не прав, но никто на форуме больше 800 метров в прыжке на ветку ещё не подымал, даже "на столе" ... Как оно себя поведет х/з, а тут ещё нагрузочка по килопакетикам нехилая будет ...

 

 

Лень рыться но поднимали 900 с хером МБит.

Ссылка на сообщение
Поделиться на других сайтах

Привожу результаты на udp трафике

Traffic Item Tx Frames Rx Frames Frames Delta Loss % Tx Rate (Mbps) Rx Rate (Mbps) Store-Forward Avg Latency (ns) Store-Forward Min Latency (ns) Store-Forward Max Latency (ns) First TimeStamp Last TimeStamp

UPSTREAM 3,877,610 3,717,350 160,260 4.133 970.002 932.372 590,052 348,940 941,340 00:04:54.673 00:05:42.643

DOWNSTREAM 3,877,610 3,877,601 9 0.000 970.002 972.589 73,865 68,440 78,340 00:04:54.673 00:05:42.643

 

Обратите внимание на пинги, нужно было попробовать несколько онушек включить.

для одного абонента этого больше чем достаточно, а вот для целой многоэтажки ХЗ.

Ссылка на сообщение
Поделиться на других сайтах

подключаем макс 3-х этажные здания на пон, ито которые в близости частного сектора. В городе пон не имеет права на жизнь (кроме как ону на пользователя).

Ссылка на сообщение
Поделиться на других сайтах

Скажу вам о Тринити в Мариуполе : скорости нет никакой , айпи тв не пашет, постоянно тормозит и не всегда открываются каналы (( . Хоть и  в Марике 500к населения у Тринити там порядка 40к хомяков  и сеть постоянно тормозит.

 

 

Единственное что мне понравилось это то что они кинули многопарник по лифтовым шахтам и по выводили его на этажах. Очень удобно и быстро подключать абонов.

Відредаговано djdeedee
Ссылка на сообщение
Поделиться на других сайтах

145 домов, 5,9,14-этажки - это по 60-200 квартир на дом. Пускай по 100 в среднем. Итого - при 10% плотности подключений имеется 1.5 тыс.абонов, потенциально - 15 тыс.

 

Вопрос - нафига городить PON-FTTB? Тем более, если уже построено по FTTB??? Что это даст ТСу, кроме нового, неизведанного ранее гимора? :)

 

Может, стоило бы что-то в консерватории поменять - ну, там, наладить безотказную работу имеющегося оборудования, пересмотреть тарифы, вбросить деньги в рекламу? Неспроста же 2/3 хомяков рассосалось (канал просел с 1-1.2 гига до 300-400Мбит)

Відредаговано NiTr0
Ссылка на сообщение
Поделиться на других сайтах

ТС советую не страдать фигней и строить все по FTTB, это проще, дешевле и надежней. Если проблема с числом волокон то тогда смотреть в сторону CWDM. Удел PON это низкоэтажная застройка с небольшой плотностью абонентов.

Ссылка на сообщение
Поделиться на других сайтах

Подправлю специфику: количество абонов просело из-за боевых действий. Планируется строить новую сеть по другим провайдером. Количество волокон критично все из-за тех же боевых действий - проще, дешевле и быстрее сварить 1-2 волокна нежели 12-16. Опыт пользователя тринити Мариуполя очень ценен, но что-то мне подсказывает, что канал забит шайтан-iptv.

Ссылка на сообщение
Поделиться на других сайтах

строили ону на дом  или подьезд. поставили ону(1501с или 1501с1)+спс224 результат нормальный полет нормальный 20 абонентов в среднем, задержки нет, пинг нормальный, танкисты не жалуються. построено так 12 домов. стоит уже 1 год.

 

пакеты от 7 - 90 мб/с

 

сейчас перешли на ону в каждую квартиру и дом. Работает отлично!

 

плохо работает если Админу не платить!))

Відредаговано Shebeduk
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від tadesky
      Продам б/в BDCOM P3616-2TE OLT . 

      Повністю робочий, без нюансів, знятий після модерну.  Комплектований резервним БЖ. 
      Оціночна вартість 40 тис. грн.

      За потреби можна комплектувати SFP Picotel EPON SFP PX++ = 600 грн/шт. 
       
      Пишіть в особисті. 
       
    • Від Prodazha
      В продажі 100 шт ону.
      комплектація ону + блок живлення
      ціна 350 грн за опт.



    • Від forella
      Имеется такая ситуация.
      топология: абонент---ону---bdcom p3310---cisco 4948--- далее 2 пути, 99% идут на линуксовый шлюз, оставшиеся(избранные, назовем их так) 1% на микротик по оттдельному vlan.
      олт 13шт. каждая олт оттдельным портом на 4948 подключена. все аналогично работают как описано выше.
      наблюдается вот такая ситуация на циско:
       
      *Apr 20 03:17:28.873: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/11 to port Gi1/7 *Apr 20 03:17:32.289: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/5 to port Gi1/11 *Apr 20 03:17:33.489: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/11 to port Gi1/5 *Apr 20 03:17:34.273: %C4K_EBM-4-HOSTFLAPPING: Host 74:4D:28:4D:3D:88 in vlan 321 is moving from port Gi1/10 to port Gi1/11 *Apr 20 03:17:34.277: %C4K_EBM-4-HOSTFLAPPING: Host 74:4D:28:4D:3D:88 in vlan 321 is moving from port Gi1/11 to port Gi1/10 *Apr 20 03:17:43.769: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/7 to port Gi1/11 *Apr 20 03:17:43.973: %C4K_EBM-4-HOSTFLAPPING: Host 78:9A:18:C7:61:85 in vlan 321 is moving from port Gi1/11 to port Gi1/7 *Apr 20 03:17:47.289: %C4K_EBM-4-HOSTFLAPPING: Host C4:AD:34:02:A9:FA in vlan 321 is moving from port Gi1/5 to port Gi1/11 vlan 321 это те самые избранные, и по логам видно что связующее звено 11 порт, за ней олт. (порты 5,7,10 так же олт)
      что было сделано:
      на олт за 11 портом выключены абоненты имеющие отношение к влан 321 - флапы продолжились.
      выключены пон порты по очереди и все сразу - флапы продолжились.
      выключен порт 11 на циско - флапы прекратились.
      включен порт, но удален влан 321 на циско - флапы прекратились.
      собственно вопрос - это глюк прошивки олт, что при выключеных пон портах флапы продолжаются, либо не там ищу причину?
       
    • Від Emanon
      Приветствую форумчан. Есть проблема и суть ее такова:
      В топологии одной провайдерской сети сделали определенные изменения. Некоторые access-коммутаторы (edge core ec3528M) в домах, решили подключить по gpon-у. Тоесть, если ранее все это дело шло ветками от одного свича к другому, то теперь ответственность, за их агрегацию , частично лягла на olt bdcom gp3600.
      Если схематически : свич -> onu -> olt -> свич агрегации -> bras (accel ipoe) ну и далее уже в ядро. Onu кстати - bdcom gp1701. Вопросы о том, зачем все это и насколько целесообразно - можно оставить для другого разговора.
      А пока что хотелось бы в кое чем разобраться. Недавно, начали идти заявки от НЕКОТОРЫХ абонентов одного и того же дома с одного и того же узла с жалобой на нестабильный интернет. Это через неделю-две после изменения топологии и соответственно, переключения их коммутатора к pon-сети.
      Техник, осмотрев происходящее, заявлял что рандомно, раз в минуту-две, начинаются потери пакетов. Проверял целостность линий,  подключался напрямую ноутом. Результат один и тот же. Линк между свичом и роутером не падает. Не падает линк и между onu и свичом. Проблем с режимами (half duplex, full duplex) портов тоже не было. Если уже далеко зайти, сам домовой свич, olt, коммутатор агрегации, без проблем пингуются (правда находятся в отдельном управляющем vlan). Очевидные проблемы, вроде роста cpu и утечек памяти, в их работе не наблюдались. В логах все чисто. В мониторинге видно, что канал не нагружен (download и upload не превышают 250 Мбит как по pon так и выше, нет аномальных значений pps как для broadcast, так для unicast и multicast). Да и для остальных пользователей, кроме проблемных, не было вопросов. У всех вроде работает, кроме некоторых ребят с конкретного узла. Трасса упорно показывает, что проблемный участок как раз между роутером и bras. Логи на роутерах тоже ничего вразумительного не пишут. При этом, стоило подключить вместо абонентского tp link archer ax12, c64 или keenetic titan, какой то древний роутер, вроде dlink dir300 или tp link tl-wr841n, как все работало стабильно, без потерь. 
      Со стороны bras сессии не рвутся, но через tcpdump действительно обнаруживается, что при пинге ( как 32 байта, так и побольше) часть icmp пакетов от проблемных абонентов не доходит. 
      Менялись mac  абонентских устройств, пытались найти mac flapping, менялся mac aging, менялся абонентский ip. Без результатов. Mac таблица за onu не забивается кстати, там не более 8 устройств. Проверялись оптические уровни. Конечно, onu rx -24 и olt rx -26 - это уже почти на грани. 
      И наверное это отчасти играет роль. Но нюанс с тем, что происходит при замене роутеров, заставляет задуматься. Возможно то, что такое вылезло именно после перехода на gpon - это совпадение. Но есть подозрения, что связь все таки есть. И проблема довольно странная, ранее не встречал.
      Ещё стоит сказать, что это далеко уже не первый домовой свич, подключенный по такой схеме. Но проблема пока вылезла именно тут. В общем, хотелось бы услышать мнения опытных ребят, с чем конкретно связаны проблемы.
      Прошу не судить сильно по части некоторых решений и высказываний. Я пока не имею солидного опыта и большого багажа знаний. Но буду благодарен за помощь
    • Від CoUL
      Sync users ONU скрипт.
      Скрипт виконує автоматичне додавання ONU та відповідної OLT, на якій вона зареєстрована, в карту абонента MikBiLL.
      Забезпечує повну синхронізацію ONU при зміні топології мережі — тобто при реальному переміщенні ONU між OLT або між абонентами. Все відбувається автоматично без необхідності вручну додавати чи змінювати ONU працівниками.
      Можлива синхронізація окремих OLT в ручному режимі.
      Підтримується робота з BDCOM EPON та GPON обладнанням.
      Можливе розширення під інших виробників OLT за потреби.
      💬 По всім питанням звертайтесь у приват.
      BDCOM xPON ONU Auto Sync Script.webm
×
×
  • Створити нове...