Перейти до

Проблема со скоростью аплоуда у клиентов на BDCOM GP3600-08


mpolk

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

Наблюдаем проблему со скоростью аплоуда у клиентов, подключенных к ОЛТу BDCom GP3600-08. Данный ОЛТ у нас первый из устройств этой модели в хозяйстве, и вообще большого опыта в области GPON-а у нас пока нет. Не исключено, что проблема проявлялась уже давно, но обнаружена она была недавно. Суть проблемы: максимальная скорость аплоуда у клиентов ограничена величиной 25-37 Мбит/с. Не видно зависимости скорости аплоуда от уровня сигнала у конкретного клиента, но просматривается зависимость от порта ОЛТа, к которому подключен клиент. К примеру, на 3-м порту у всех клиентов макс. скорость аплоуда 25-28Мбит/с,на 4-м - 32-34 Мбит/с, на 5-м - 35-37 Мбит/с. Потерь пакетов у клиентов не наблюдается; проблем со скоростью даунлоуда - тоже (у всех около 94 Мбит/с). Какой-либо физический перегруз каналов исключен (трафик небольшой).

На стенде, с 2-мя ONU эта проблема не наблюдалась. Создается впечатление, что скорость аплоуда зависит от количества ОНУ, зарегистрированных на порту, т.е. ОЛТ выделяет каждой ОНУ фиксированную полосу пропускания, не пытаясь осуществлять DBA. Если проблема именно в этом (в чем я не уверен), то способов включить DBA на ОЛТе я не вижу. Я надеялся, что DBA включен автоматически, но, возможно, я ошибался.

 

Дополнительно, в процессе проведенных изысканий было обнаружено следующее. Возникло подозрение, что скорость аплоуда в порту определяется ОНУшкой с самым слабым сигналом (такое явление обсуждалось в прошлом на local.com.ua применительно к EPON-овскому оборудованию). Для проверки этой гипотезы я начал временно отключать ОНУ работающих клиентов, подключенных к тому же порту, что и тестовый ноутбук, и при этом перемерять скорость аплоуда. Сначала я отключал ОНУ с самым слабым сигналом. Потом стал отключать, наоборот, самые благополучные ОНУ. Оказалось, что по мере отключения параллельно работающих клиентов скорость аплоуда на тестовом оборудовании действительно растет. Однако уровень сигнала отключаемых ОНУ никак не влияет на результат.  Ускорение тестового аплоуда зависит, по-видимому, только от общего количества отключаемых ОНУ.

 

В целом, вырисовывается такая картина, что дело не в физике, не в уровнях сигнала и т.п., а в каких-то патологиях в распределении ОЛТом восходящей полосы пропускания между ОНУшками. Возможно, патологии обусловлены ошибками конфигурирования ОЛТа (делалось все, естественно, методом китайского научного тыка, как положено с БДКомом). Или, может быть, дырками в софте ОЛТа, или сочетанием того и другого.

 

Не сталкивался ли кто с такой проблемой и не знает ли методов лечения?

 

Данные ОЛТа:

Скрытый текст

Kaz42-GPON#sh ver
BDCOM(tm) GP3600-08 Software, Version 10.3.0D Build 68222
Copyright by Shanghai Baud Data Communication CO. LTD.
Compiled: 2019-10-22 21:27:32 by SYS, Image text-base: 0x80008000
ROM: System Bootstrap, Version 0.1.4, Serial num:00320000525
System image file is "flash:BD_GP3616_10.3.0D_68222.bin"
hardware version:
(RISC) processor with 524288K bytes of memory, 32768K bytes of flash
Base ethernet MAC Address: 84:79:73:37:42:c8
snmp info:
  product_ID:342   system_ID:1.3.6.1.4.1.3320.1.342.0
Kaz42-GPON uptime is 4:04:10:46, The current time: 2019-11-18 14:9:13
 Reboot history information:
  No. 1: System is rebooted by command at 2019-11-13 13:14:31, uptime 0:00:27:59

 

ОНУшки используем родные: BDCom GP1501DR.

Kaz42-GPON.start

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

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

И так, проблема, наконец, была решена (если это кому-нибудь еще интересно).   Еще месяц техподдержка ДЕПСа всячески мордовала меня, заставляя снова проверять качество аплинка, пускать трафик

Вчера провели, наконец,  измерения скорости, довольно подробные, с кручением рукояток в разные стороны. Результаты такие, что лучше бы мне их не видеть никогда. 0) Исходное состояние: еще в ночь

В плане стабильности у него все вроде бы в порядке.   Единственный несчастный случай был зафиксирован года полтора назад еще до начала промышленной эксплуатации. ОЛТ был впервые вынесен в по

Конфиг и версия ПО находятся в студии с самого начала. Первый в приложении, а вторая под спойлером.

Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, mpolk сказал:

Конфиг и версия ПО находятся в студии с самого начала. Первый в приложении, а вторая под спойлером.

 

А как так у вас получилось ? 

В файле Kaz42-GPON.star

!version 10.3.0C build 50870
boot system flash BD_GP3616_10.3.0C_50870.bin

А в sh ver

BDCOM(tm) GP3600-08 Software, Version 10.3.0D Build 68222
System image file is "flash:BD_GP3616_10.3.0D_68222.bin"

 

Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, fet4 сказал:

 

А как так у вас получилось ? 

В файле Kaz42-GPON.star


!version 10.3.0C build 50870
boot system flash BD_GP3616_10.3.0C_50870.bin

А в sh ver


BDCOM(tm) GP3600-08 Software, Version 10.3.0D Build 68222
System image file is "flash:BD_GP3616_10.3.0D_68222.bin"

 

Это несложно. Конфиг был слит до перехода на новую прошивку. Никаких принципиальных отличий там нет.

Ссылка на сообщение
Поделиться на других сайтах
5 часов назад, andruxovich сказал:

Была похожая проблема. Решилась откатом прошивки до BD_GP3616_10.3.0C_46550. На более новых работать нормально отказывается

А не поделитесь ли прошивкой? Буду признателен.

Ссылка на сообщение
Поделиться на других сайтах
3 минуты назад, andruxovich сказал:

Вот здесь лежат прошивки http://bdcom.mega.dp.ua/files/

Спасибо. Пошел пробовать. По результатам отпишусь.

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

Полноценно испытать прошивку BD_GP3616_10.3.0C_46550 не удалось. С текущим конфигом ОНУшки подключиться не смогли, ОЛТ ругался на незнакомую команду "cmd-sequence 004 gpon onu loopback-detect protocol private". После удаления этой команды из профилей конфигурирования ОНУ слегка полегчало: ОНУшки подключились. Но клиенты подключиться уже не смогли. Трафик в клиентских ВЛАНах над ОЛТом полностью отсутствовал. От дальнейших экспериментов над живыми людьми я пока воздержался.

Попробую еще поэкспериментировать с прошивкой 46550 ночью, постепенно упрощая конфиг до такого состояния, что клиенты таки смогут подключиться. Хотя жить с такой прошивкой (без loopback-detect-а) сколько-нибудь долго нельзя, только на время эксперимента.

 

Либо придется искать другое решение.

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

У меня трафик не хотел бежать, как я не упрощал конфиг. В итоге удалил все, и настроил с нуля. Теперь работает. А проблема начиналась с плохой скорости, которая падала по мере роста кол-ва ону на голове (неважно в каких pon портах). В итоге дошел до момента, когда новые ону не получали конфиг. Если отключить пару зареганых ранее ону - новые получали конфиг. А насчёт разницы версий в sh run и sh conf - таки да, после обновления, или отката в sh run отображается текущая версия,  в sh conf предыдущая. Если сделать write all - все становится одинаково. 

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

Если проблема в с корости с ростом ОНУ - значит косяк в лайн/дба профилях, где бендвич указывается несколькими способами - жёстко, плавающе по максимальной полосе и ДР . Что то вроде sir/pir на епоне

Ну и ещё с сигналом может бида быть. Но тогда ошибки тикают.

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

А что Вы хотите от общей среды?

Если просто и на пальцах, то http://www.gpon.com/how-gpon-works

Вот и делите эти 1.2Gbps на все подключенные абонентские терминалы.

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

Нееее. Тама можно указать как резать полосу - жёстко, или не жёстко. Если нарезать соточку жёстко - то да, 10 онух и амба. А можно не жёстко.

На ЗТЕ выглядит примерно так

 

profile tcont SMARTOLT-1G-UP type 4 maximum 1024000

Где type :

 1  Fixed bandwidth
  2  Assured bandwidth
  3  Assured bandwidth and non-assured bandwidth
  4  Best-effort bandwidth
  5  The super set of all of T-CONT types

Ссылка на сообщение
Поделиться на других сайтах
9 минут назад, Dimkers сказал:

Нееее. Тама можно указать как резать полосу - жёстко, или не жёстко. Если нарезать соточку жёстко - то да, 10 онух и амба. А можно не жёстко.

На ЗТЕ выглядит примерно так

 

profile tcont SMARTOLT-1G-UP type 4 maximum 1024000

Где type :

 1  Fixed bandwidth
  2  Assured bandwidth
  3  Assured bandwidth and non-assured bandwidth
  4  Best-effort bandwidth
  5  The super set of all of T-CONT types

Так дело ж не в полосе, а в физике (L1). Вы точно про UPLOAD?

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

http://ngoptics.com.ua/materials/reference_information/osobennosti-nastroyki-profaylov-na-olt-zte/

У меня есть ветки с 110+ ОНУ. Жалоб на скорость, нерегистрацию ОНУ - нет. То, что не дает зарегать ОНУ - это таки похоже на жесткое нарезание профилей. Не забывайте, Гпон это вниз таки 2,5Гб

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, Dimkers сказал:

http://ngoptics.com.ua/materials/reference_information/osobennosti-nastroyki-profaylov-na-olt-zte/

У меня есть ветки с 110+ ОНУ. Жалоб на скорость, нерегистрацию ОНУ - нет. То, что не дает зарегать ОНУ - это таки похоже на жесткое нарезание профилей. Не забывайте, Гпон это вниз таки 2,5Гб

ТС таки жаловался на скорость UPLOAD. 

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

Ааа, сорян.

Что то было и такое тут. В прошивках онух косяк был.

Кстате, а с шейпером все норм?

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
13 часов назад, Dimkers сказал:

Если проблема в с корости с ростом ОНУ - значит косяк в лайн/дба профилях, где бендвич указывается несколькими способами - жёстко, плавающе по максимальной полосе и ДР . Что то вроде sir/pir на епоне

Ну и ещё с сигналом может бида быть. Но тогда ошибки тикают.

Да я понимаю, что беда где-то в этой области: cir/pir/shaper/policer и т.п.. Так прямо сразу и написал. Вот только не понимаю пока, где конкретно. DBA-профайла в этом ОЛТе нет вообще (или я о нем не знаю). Это меня тоже сильно смущает.

С физикой значимых проблем нет: уровни сигнала приемлемые, потерь пакетов нет, скорость не рваная, а ровно (но неправильно) нарезанная.

 

12 часов назад, foreverok сказал:

А что Вы хотите от общей среды?

Если просто и на пальцах, то http://www.gpon.com/how-gpon-works

Вот и делите эти 1.2Gbps на все подключенные абонентские терминалы.

Я хочу, чтобы скорость делилась не между подключенными терминалами (в том числе спящими, ковыряющими в носе и размышляющими о жизни). А между терминалами, реально запросившими передачу данных, в пределах выделенных cir/pir/eir-ов. Такой способ разделения полосы называется Dynamic Badwidth Allocation (DBA)  и присутствует в стандарте GPON-а, во всех вменяемых реализациях EPON-а (за отсутствием там стандарта) и во всех вменяемых технологиях, использующих TDM (под разными названиями). PON без такой фичи мне точно не нужен.

 

12 часов назад, Dimkers сказал:

Нееее. Тама можно указать как резать полосу - жёстко, или не жёстко. Если нарезать соточку жёстко - то да, 10 онух и амба. А можно не жёстко.

На ЗТЕ выглядит примерно так

 

profile tcont SMARTOLT-1G-UP type 4 maximum 1024000

Где type :

 1  Fixed bandwidth
  2  Assured bandwidth
  3  Assured bandwidth and non-assured bandwidth
  4  Best-effort bandwidth
  5  The super set of all of T-CONT types

У меня на БДКОМе оно аналогично выглядит. Но то ли я неправильно пишу эти профайлы, то ли ОЛТ неправильно их понимает. У меня стоит 3-й тип трафика, и в нем 8Мбит гарантированных и 100М максимальных. С виду ничего криминального, должно быть хорошо. А на деле плохо.

 

12 часов назад, foreverok сказал:

Так дело ж не в полосе, а в физике (L1). Вы точно про UPLOAD?

Дело именно в полосе, а не в физике. Я точно про аплоуд. Загрузка PON-портов очень небольшая в обоих направлениях.

 

12 часов назад, Dimkers сказал:

Ааа, сорян.

Что то было и такое тут. В прошивках онух косяк был.

Кстате, а с шейпером все норм?

Думаю, что не в норме, судя по результатам (если вы про шейперы ОЛТа и/или ОНУ). Только я не знаю, как это поправить. Где начинаются настройки ОНУшек и заканчиваются настройки ОЛТа (т.е. кто именно нарезает скорость аплоуда) из конфига и документации тоже, кстати, не видно.

 

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

  • Like 1
Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, mpolk сказал:

(если вы про шейперы ОЛТа и/или ОНУ

не, я про НАСы\БРАСы.

 

2 часа назад, mpolk сказал:

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

Одна из первых ссылок гугла дала конфиг https://forum.nag.ru/index.php?/topic/148225-bdcom-gp3600-16-nastroyka-multikasta/

Крутите.

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

Правьте сигналы и ставьте усиленные модули. Нам ток это помогло. Все настройки до фени. Если модули фоксгейты и на голову приходит меньше -25, нихрена вам не поможет, повторюсь ток сигналы и усиленные модули.

У нас осталась с этой башкой одна проблема: раз в несколько недель пропадают маки на одном из понов-помогает ток ребут

Ссылка на сообщение
Поделиться на других сайтах
В 19.11.2019 в 13:03, andruxovich сказал:

У меня трафик не хотел бежать, как я не упрощал конфиг. В итоге удалил все, и настроил с нуля. Теперь работает. А проблема начиналась с плохой скорости, которая падала по мере роста кол-ва ону на голове (неважно в каких pon портах). В итоге дошел до момента, когда новые ону не получали конфиг. Если отключить пару зареганых ранее ону - новые получали конфиг. А насчёт разницы версий в sh run и sh conf - таки да, после обновления, или отката в sh run отображается текущая версия,  в sh conf предыдущая. Если сделать write all - все становится одинаково. 

А можно уточнить: что значит удалить все? К примеру удаление файла config.db, в котором хранятся, насколько я понимаю закэшированные конфиги ОНУ-шек - это правильный способ? И не приведет ли это к неспособности ОЛТа загрузиться? Честно говоря, боязно экспериментировать на живую.

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

Если боязно - тогда через вебморду reset к заводским настройкам. Но, можно также удалить startup-config и config.db , перезагрузить и все будет хорошо. 

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

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

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

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

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

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

Вхід

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

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

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

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

    • Від winedrop
      продам xPON ONU G55 Hosecom
      чіп ZTE, працюють на ZTE, Huawei та кітайських OLT
      нові, власний імпорт, в наявності 500 шт
      до 50 шт - 400 грн/шт
      від 50 шт - 390 грн/шт
      від 200 шт - про ціну домовимось
      ціна на ФОП, з ПДВ  +20%
       
      в комплекті патч-корд 
       
      тел. для зв'язку - 0506305206, 0688371733






    • Від Dolik
      Після переходу на GPON вивільнились кілька OLT на 4 порти та на 8.
      Всі голови укомплектовані UPS на 12в від Proline

    • Від winedrop
      продам ОНУ, нові
      1-20 шт - 440 грн/шт
      21-60 шт - 420 грн/шт
      60+ - 400 грн/шт
      з ПДВ +20%


    • Від ~AsmodeuS~
      PON  панель
       
       
    • Від Mykola_
      Продам spf
      Bdcom rx 20+++ 8шт новые 1000 грн
      Step4net  новые 4шт 800 грн
      Alistar,Foxgate,Hisens, бу 500 грн
       
      Gpon 
      Zte c++ 2шт почти новые 700 грн
       




×
×
  • Створити нове...