Jump to content
Local

mpolk

Muggles
  • Content Count

    26
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by mpolk

  1. Сам отвечаю на поставленный мною же вопрос. Да, возможно. Но с оговорками. После двух месяцев эксплуатации нового БРАСа в реальной среде уже можно что-то сказать. Сервер мы купили не совсем такой, как хотелось, а такой, какой был на складе. Процессор хотели 7302, а получили 7282 (номинальная тактовая 2.8 ГГц вместо 3.0, а ядер столько же, т.е. 16). И материнская плата Supermicro H11SSL-i, т.е. под предыдущее поколение ЭПИКов, но с проапгрейженным под второе поколение БИОСом. Памяти пришлось поставить 32Г, чтобы занять хотя бы 4 канала. Хотя по объему мне бы и 2-х Г хватило. Систему поставили Ubuntu 18.04. В результате получилось вот что: Сервер получился самым производительным из имеющихся у нас (хотя и не намного). Что и понятно, т.к. предыдущему поколению БРАСов у нас уже лет пять. БРАСы предыдущего поколения, на Intel Xeon E5-2650v2 x 2, могут обмолачивать примерно по 4500 пациентов в час пик. Новый сервер - примерно 5800 в то же время. Колеса начинают отваливаться при примерно 6200 пациентов. Это хорошо. А вот то, что не совсем хорошо: С родным для 18-й Убунты ядром 4.15 сервер более-менее работает. За исключением одного: ядро напрочь не узнает EDAC второго EPYC-а. Ругается примерно вот так: Jun 3 09:54:05 vasilisk kernel: [ 9.484971] EDAC amd64: Error: Error probing instance: 0 Jun 3 09:54:05 vasilisk kernel: [ 9.580503] EDAC amd64: Node 0: DRAM ECC enabled. Jun 3 09:54:05 vasilisk kernel: [ 9.580504] EDAC amd64: F17h detected (node 0). Jun 3 09:54:05 vasilisk kernel: [ 9.580511] EDAC amd64: Error: F0 not found, device 0x1460 (broken BIOS?) Жить с этим в принципе можно, но обидно, т.к. совершенно нет уверенности, что ECC (да еще при таком конском объеме памяти) работает, как должно. С HWE-ядром 5.3 EDAC опознается благополучно, но возиться с HWE-ядрами не хотелось бы. Приёмистость нового БРАСа, т.е. скорость приема входящих пациентов, несколько ниже, чем у старых БРАСов. В результате, при нехватке пациентов новый сервер стоит недогруженным в то время, как его старшие товарищи трудятся в поте лица. Это, конечно не страшно: при выходе из строя какого-то из старых БРАСов новый тут же возьмет на себя его пациентов. Но неэстетично. Балансировка нагрузки ядер трафиком со стороны пациентов (со стороны городской сети) тоже имеет некоторые проблемы. Со стороны Интернета трафик, в вместе с ним и загруженность ядер балансируется без проблем силами сетевого адаптера (RSS), потому что трафик там не инкапсулирован в PPPoE. А вот со стороны пациентов трафик инкапсулирован и потому попадает весь в одну очередь и на одно ядро. У нас это традиционно лечилось с помощью RPS, который далее раскидывает нагрузку равномерно по ядрам. На Интеловских серверах дополнительная нагрузка на ядро, обрабатывающее аппаратные прерывания, была практически незаметна. А новом БРАСе она оказалась очень даже заметной, так что сервер начинало перепирать задолго до того, как средняя нагрузка на все ядра становилась критической. Пришлось ядро, занятое аппаратными прерываниями, полностью освободить от дальнейшей обработки трафика. В результате оно оказывается недогруженным, но так как SoftIRQ-шная нагрузка, снятая с этого ядра, равномерно распределяется по 7-и остальным ядрам, то жить опять-таки можно. Не исключаю, что пробемы из пп. 3 и 4 могут быть как-то взаимосвязаны.
  2. Доброго времени суток, Есть ли у кого-то практический опыт построения софтового (Линуксового) BRAS-а на платформе AMD EPYC2 (ну или хотя бы на просто EPYC)? Если да, наблюдаются ли какие-то специфические для данной платформы проблемы: с производительностью, балансировкой прерываний от сетевых плат, RSS, RPS и т.д.? Что известно про совместимость с 10G-сетевыми платами (от Intel и Mellanox)? Какие сетевухи предпочтительнее? Дополнительное требование: у нас клиенты подключаются по PPPoE, поэтому необходим именно правильно работающий RPS. Мы традиционно строили аналогичные сооружения на интеловских Xeon-ах с интеловскими же сетевыми платами (раньше i350, потом 82599). Но в наш просвещенный век, когда кругом Meltdown, Spectre, Spectre 2, Spectre 3 и повышение цен, а AMD - это так стильно, модно и молодежно... Неудержимо хочется попробовать AMD. Сегодня собрать на Интеле примерно такой же БРАС, как три года назад (с аналогичной ожидаемой производительностью, но на новом железе) получается почему-то раза в полтора дороже, чем три года назад. А на Эпик2 аналогичная коробка (с той же ожидаемой производительностью) получается процентов на 10 дешевле чем Интеловская коробка трехлетней давности. Только вот будет ли реальная производительность где-то вблизи ожидаемой? Сердце-то помнит страшные рассказы, которые ходили несколько лет назад, о том как плохо и даже ужасно делать БРАСы на AMD. Глядя на теперешние блок-схемы и даташиты Эпиков я не нахожу ничего ужасного. Но не скрывается ли оно где-то в глубине?
  3. Да нет, я не такой отчаянный, чтобы свежеиспеченный дистрибутив прямо на сервера ставить. У меня на тех серверах клиенты, по несколько тысяч на каждом, и среди них встречаются очень неприятные и злопамятные люди. Я примерно про это и спрашивал. А @nedoinet пояснил. Если бы было на чем, я бы прямо на этом чем-то и испытывал (и вопросов бы, скорее всего, не задавал). Но это что-то стоит около 90 килогривен. Так что я решил предварительно поспрашивать.
  4. А у вторых Эпиков это уже не так, насколько я понимаю. У них теперь нет локальной памяти для ядер. Вся память колхозная. Это, конечно ухудшает показатели для отдельных ядер, но в среднем по палате показатели по словам АМД-ов улучшаются.
  5. О, вот это тоже интересный вопрос, и не все с ним ясно. Похоже, вы что-то про это знаете. Убунта 18.04 - это хорошо, это бы меня устроило. А вот ядро какое имеется в виду? Родное, 4.15? Или потребуется с HWE-ядрами мучаться? И еще. А в каком смысле новый процессор (в данном случае EPYC2) может не поддерживаться той или иной ОС? Вот прямо так не загрузится система с дистрибутивной флэшки или не установится? Или какие-то новые фичи работать не будут? Сколько я жил раньше, не разу не видел, чтобы Линукс не захотел работать именно из-за процессора, а теперь вот такие разговоры появились о (не-)совместимости. От того и недоумеваю. Спасибо, обнадеживает.
  6. Спасибо, это уже кое-что. Думаю, если Эпик-первый годен к такому делу, то и второй должен потянуть.
  7. Так а вы пробовали? Или это просто теоретическая концепция, которую неплохо было бы проверить, например, на мне? 😀
  8. Наблюдаем проблему со скоростью аплоуда у клиентов, подключенных к ОЛТу 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-овскому оборудованию). Для проверки этой гипотезы я начал временно отключать ОНУ работающих клиентов, подключенных к тому же порту, что и тестовый ноутбук, и при этом перемерять скорость аплоуда. Сначала я отключал ОНУ с самым слабым сигналом. Потом стал отключать, наоборот, самые благополучные ОНУ. Оказалось, что по мере отключения параллельно работающих клиентов скорость аплоуда на тестовом оборудовании действительно растет. Однако уровень сигнала отключаемых ОНУ никак не влияет на результат. Ускорение тестового аплоуда зависит, по-видимому, только от общего количества отключаемых ОНУ. В целом, вырисовывается такая картина, что дело не в физике, не в уровнях сигнала и т.п., а в каких-то патологиях в распределении ОЛТом восходящей полосы пропускания между ОНУшками. Возможно, патологии обусловлены ошибками конфигурирования ОЛТа (делалось все, естественно, методом китайского научного тыка, как положено с БДКомом). Или, может быть, дырками в софте ОЛТа, или сочетанием того и другого. Не сталкивался ли кто с такой проблемой и не знает ли методов лечения? Данные ОЛТа: ОНУшки используем родные: BDCom GP1501DR. Kaz42-GPON.start
  9. В плане стабильности у него все вроде бы в порядке. Единственный несчастный случай был зафиксирован года полтора назад еще до начала промышленной эксплуатации. ОЛТ был впервые вынесен в поле и засунут в ящик на чердаке. Живых пациентов мы к нему по-моему еще не подключали, просто хотели посмотреть, как на него свежий воздух подействует и бодрящая атмосфера летнего чердака в хрущовке. Примерно через сутки ОЛТ исчез с экранов радаров и больше не появлялся. Его вытащили из ящика и положили на анатомический стол. Вскрытие показало, что перед смертью покойник сильно потел и стер себе содержимое флэшки, так что грузиться ему было уже неоткуда. Возникла гипотеза, что ОЛТ не любит жары, но ДЕПС уверил, что эти ОЛТы и не такую температуру с легкостью выдерживают, и что это первый такой случай в их практике. Мы поверили, восстановили прошивку (уже не помню как) и вернули ОЛТа на чердак. Там он с тех пор и работает без каких-либо нареканий (не считая проблемы, описанной в данной теме). Но запасной экземпляр мы на всякий случай держим. Главная проблема с этим железом - отсутствие нормальной документации. Из документации есть только: 1) 22 тома наставлений от БДКома про "свичи вообще", где описано, как свичи перезагружать и смотреть на них время. Про GPON там сказано только то, что, чтобы посмотреть посмотреть информацию об ОНУшках, надо прямо так и сказать: show gpon onu-info. И т.п. 2) "Малая книга заклинаний" от ДЕПСа. По объему и информативности примерно соответствует двум страницам из рукописи Войнича, только без картинок. Если этих заклинаний не хватает, то надо просить аудиенции у Вендоров (см. выше).
  10. А тот способ, который я вам предлагал, чем вас не устраивает? Или он не работает?
  11. И так, проблема, наконец, была решена (если это кому-нибудь еще интересно). Еще месяц техподдержка ДЕПСа всячески мордовала меня, заставляя снова проверять качество аплинка, пускать трафик iperf-а в обход PPPoE и перебирая все известные им способы не заниматься проблемой напрямую. Наконец, мне была дана Скайп-аудиенция с младшим чиновником провинции Фу Цзянь по делам серверных варваров. Чиновник оказался женска полу: ко мне вышла девушка в огромных очках и с длинными волосами, как в фильме "Шанхайский дракон 4" (если, конечно, верить аватарке) и показала настоящее кунг-фу. Пять минут она выслушивала мою челобитную, потом пять минут думала, потом три минуты копалась в недрах ОЛТа (ей был дан удаленный доступ) и потом спросила примерно так: - You have 90Mbit/s now. You are happy? - O-o-h! I am happy. What did you do? - You see this command in your TCONT profile: gpon profile onu-tcont tcont-general id 2 gpon-profile tcont-type 3 pir 100032 cir 8192 gpon-profile alloc-type nsr Remember this command, use it in your life, reboot your ONUs and be happy. Go your way. (Честно говоря, девушка еще пояснила мне, что эта команда, она ... "the command NSR of the tcont profile ,it means the onu only need care about the bandwidth for itself.it will not effection other onu in the same pon port". На самом деле, команда по-видимому, переводит механизм DBA в режим non-status-reporting. И ведь с самого начала я предполагал, что проблема в DBA). С тех пор у моих клиентов хороший аплоуд, а я хожу просветленный, мечтаю снова встретить ту девушку и очень не люблю ДЕПС.
  12. mpolk

    Продам б/у D-LINK DGS-3610-26G

    Добрый день, А отдельно DEM-412X не продадите (если есть еще)?
  13. Куплю вышеупомянутый модуль (если кто-нибудь мне его продаст). Заплачу деньги.
  14. mpolk

    Продам L3 D-LINK DGS-3610-26G

    Добрый день, а один DEM-412X не продадите?
  15. Для тех, кому интересно, описываю дальнейший ход изысканий. Были организованы две тестовых точки: 1) Автономно работающий ноутбук с Линуксом, автоматически подключающийся к серверам доступа через PON-сеть (через 1-й порт ОЛТ-а). На нем установлен iperf3, с помощью которого можно тестировать скорость аплоуда между ноутбуком и сервером доступа, к которому он в данный момент подключен. Данная точка размещена у одного из клиентов, с которым имеется договоренность на этот счет. 2) ОНУ-шка, подключенная прямо к порту ОЛТ-а (в данный момент к тому же 1-у порту) через асимметричный сплиттер 5/95 (по совету @nedoinet). Эзернет-порт ОНУ-шки подключен к домовому свичу и далее, специально организованным транзитным ВЛАНом, выведен «обратным ходом» снова на сервера доступа. Таким образом, можно, запуская на одном из серверов доступа PPPoE-клиента, подключаться к другому серверу и тестировать скорость iperf-ом. Таким образом, была обеспечена возможность удаленного тестирования скорости аплоуда, и проблема была передана поставщикам оборудования. Кроме того, я за последнюю неделю самостоятельно провел серию изысканий с помощью вышеописанных тестовых точек (по ночам, чтобы меньше мешать клиентам). Исследования проводились по следующей схеме: я отключал часть клиентских ОНУ-шек от PON-сети (с помощью команды «gpon onu disable» на соотв. подинтерфейсе) и измерял скорость аплоуда (и даунлоуда) на обеих тестовых точках. Потом разрешал этим ОНУ-шкам снова подключиться, отключал следующие и т. д. Также я проверял эффект полного тушения порта с отключением всех клиентов (командой shutdown на GPON-интерфейсе) и эффект перезагрузки ОЛТа. Кроме того, я пытался менять ограничения скорости аплоуда (cir и pir) в «onu rate-limit profile». Как выяснилось, эти изменения не влияют (по крайней мере прямо) на ситуацию (см. ниже), поэтому я вернул профиль к исходному состоянию. Результаты исследований приведены ниже: 1. Скорость аплоуда в обеих тестовых точках практически одинакова (с точностью до 1 Мбит/с). Она может меняться в зависимости от ситуации (см. ниже), но между двумя точками разницы в скорости аплоуда нет никогда (пока точки подключены к одному и тому же порту). Это при том, что уровень сигнала на порту ОЛТ равен примерно -26 dBm для первой точки и -9 dBm для второй. 2. Скорость даунлоуда в обеих точках также одинакова между собой с точностью до 1 Мбит/с и, кроме того, не зависит от ситуации. Она всегда равна 92-93 Мбит/с и определяется возможностями тестового оборудования и 100-Мбитного эзернет-подключения. 3. Сразу после поднятия GPON-порта на ОЛТ-е (неважно, какой ход событий предшествовал и привел к этому поднятию: shutdown порта, перезагрузка ОЛТ-а или запрет всех ОНУ-шек, зарегистрированных на порту) ОЛТ устанавливает одинаковую максимальную скорость аплоуда для всех ОНУ-шек на порту. Или, может быть, не для всех, но на тех двух ОНУ-шках, за которыми я мог наблюдать, эта скорость всегда была одинаковой. Значение этой максимальной скорости, похоже выбирается случайно, хотя возможно ОЛТ и имеет на этот счет какие-то неизвестные мне соображения. Я наблюдал значения в интервале от 50-и до 80-и Мбит/с. 4. Далее, если ОЛТ и ОНУ-шки оставить в покое и ограничиться пассивными замерами скорости, то обнаружится, что скорость аплоуда будет постепенно расти, оставаясь при этом одинаковой для двух тестовых точек. Рост продолжается, пока не будет достигнут предел в 93 Мбит/с, определяемый, как я уже писал, возможностями тестового оборудования. Время, необходимое для восстановления скорости аплоуда до номинальной величины, в разных случаях разное и, похоже, не коррелирует с начальной скорость аплоуда. Мне приходилось наблюдать временные интервалы от 6-и часов до двух с половиной суток. Детальный характер роста скорости (плавно, скачками или еще как-то) мне определить не удалось. 5. Дальше, скорость аплоуда будет оставаться на этом уровне, пока не произойдет следующее падение порта или массовое переподключение ОНУ-шек (например, при их массовом переконфигурировании). После этого будет установлено новое случайное значение скорости и все повторится снова. 6. Если в период от поднятия порта до достижения номинальной скорости аплоуда отключить от порта одну или несколько ОНУ-шек (командой «gpon onu disable»), то скорость аплоуда на остальных ОНУ-шках возрастает. Степень возрастания скорости зависит как от количества отключаемых ОНУ-шек, так и от их «качества». Т.е. некоторые ОНУ-шки при отключении вносят больший вклад в увеличение скорости аплоуда, чем другие. «Качество» ОНУ-шек никак не коррелирует с уровнем сигнала на на этих ОНУ-шках. В то же время, «качество» ОНУ-шки является параметром постоянный, т. е. при повторных отключениях каждая ОНУ-шка вносит тот же самый вклад в улучшение скорости аплоуда, что и во время предыдущих попыток. В зависимости от «качества» отключаемых ОНУ-шек может потребоваться отключение от 2-х до 6-и единиц ОНУ для достижения номинальной скорости аплоуда в 93 Мбит/с. 7. После возвращения отключенных ОНУ-шек в строй скорость аплоуда снова падает. Как правило, она падает до того же уровня, который наблюдался до отключения ОНУ‑шек. Но довольно часто, скорость аплоуда после отключение оказывается немного (на несколько Мбит/с) выше, чем она была до отключения. Таким образом, эксперименты с отключением ОНУ-шек приводит к ускорению процесса возвращения скорости аплоуда к номинальной величине. Есть подозрение, что и «естественный» процесс подъема скорости аплоуда до номинальной величины движется за счет «естественных» событий подключения/отключения клиентских ОНУ-шек. 8. Как оказалось, мои предыдущие манипуляции с параметрами cir и pir в rate-limit-профиле - все это к причинному месту двери. Единственный видимый эффект от них состоит в том, что изменение этих параметров (или параметров в любом другом onu-профайле) вызывает отключение и переконфигурирование ОНУшки или ОНУшек, в которых этот профайл задействован. Если профайл "глобальный", т.е. задействован во всех или в многих ОНУшках, то произойдет массовое переподключение, которое повлечет за собой события, описанные выше. Переконфигурирование ОНУшки(ОНУшек) триггерится в некоторых случаях непосредственно изменением в профайле, на который ссылается ОНУшка, а других - по команде "exit" после внесения изменений в профайл. Таким образом, складывается устойчивое впечатление, что заниженная скорость аплоуда определяется не какими-то настройками QoS в конфиге (правильными или неправильными), а неправильным распределением ОЛТ-ом восходящей полосы пропускания, вызванным ошибочным расчетом этого распределения ОЛТ-ом в момент поднятия линка на порту. Со временем (возможно, по мере переподключения ОНУ-шек) ОЛТ корректирует свои расчеты, и скорость приходит в норму. Если это предположение верно, то проблема может быть решена только силами разработчиков ПО ОЛТ-а. Ждем фидбэка от них.
  16. Вчера провели, наконец, измерения скорости, довольно подробные, с кручением рукояток в разные стороны. Результаты такие, что лучше бы мне их не видеть никогда. 0) Исходное состояние: еще в ночь с четверга на пятницу в общеклиентский rate-limit-профайл прописаны дефолтные значения (pir 1244160 cir 1244160), все это записано а в startup-config и ОЛТ перезагружен с этим конфигом. Уже тогда были предварительные данные, что аплоуд с таким конфигом будет хороший (85Мбит/с). 1) В субботу утром подключаемся и начинаем мерить. Действительно, 85 Мбит/с. На разных ОНУшках. (Как потом выяснилось, 85Мбит/с - это потолок аплоуда для нашего тестового ноутбука с его встроенной сетевухой и "оптимизированной" народными умельцами Windows 10). Счастье, вот оно. Мы нашли команду, которая все портила (спасибо @sanyadnepr). Просыпается оптимизм, вкус к жизни и желание поэкспериментировать. А теперь попробуем проверить гипотезу @foreverok, что излишний cir приносит вред. 2) Создаем тестовый rate-limit-профайл с pir 1244160 cir 10000. Удаляем ссылку на текущий rate-limit-профайл из рабочего virtal-port-профайла. А сейчас мы туда поставим ссылку на тестовый профайл с умеренным cir-ом. Ой, звук пропал... ОЛТ куда-то ушел... На телнет не реагирует, на пинги не отвечает. В принципе дело знакомое, ОЛТ так уходит в себя, когда массово переконфигурирует ОНУшки. Сейчас, правда, его никто об этом не просил. Видно сам решил. Подождем, он минуты чрез 3-4-5 должен вернуться. Действительно, вернулся. Продолжаем с того места, где остановились. Назначаем тестовый rate-limit-профайл. Переконфигурируем тестовую ОНУшку. Меряем аплоуд. 35Мбит/с... Ах ты ж зараза! 3) Поднимаем cir до старого (предположительно, неверного) значения 100000. Переконфигурируем тестовую ОНУшку. Меряем аплоуд. 25Мбит/с... Выставляем pir, равным cir, т.е. 100000. Переконфигурируем тестовую ОНУшку. Меряем аплоуд. 30Мбит/с... Пытаемся постепенно поднять pir до дефолтного значения 1244160, при котором все было хорошо. 200000. Меряем. 35Мбит/с... 400000. Меряем. 20Мбит/с... 800000. Меряем. 35Мбит/с... 1200000. Меряем. 25Мбит/с... Возвращаем дефолтный профайл (pir 1244160 cir 1244160), на котором мы видели 85Мбит. Меряем. 20Мбит/с... В отчаянии перегружаю ОЛТа, не сохраняя конфига, надеясь вернуть его к начальному состоянию, которое было утром, когда и аплоуд был 85. Меряем. 50Мбит/с. Занавес. Когда я снова стал узнавать близких и воспринимать окружающее, я сделал для себя следующие выводы: 1) В принципе, направление изысканий правильное, крутить надо rate-limit-профайлы. Хотя, возможно, не только их: tcont-профайлы содержат аналогичные параметры. Чем один профайлы отличаются от других и как они взаимодействуют - в этом еще разбираться и разбираться. 2) ОЛТ безусловно понимает параметры этих профайлов каким-то извращенным образом. Возможно, на самом деле, вредный вклад в его образ действий вносит тот факт, что суммарный cir в rate-limit-ах превышает физическую пропускную способность канала. Теоретически этот вред не должен проявляться, пока не достигнуто насыщение физики, но на практике, в исполнении китайского ОЛТа, можно ожидать чего угодно. Так что cir-ы, вероятно, стоит отрихтовать. 3) Мало того, что реальное состояние параметров восходящих шейперов/полисеров хранится в системе "конфиг ОЛТа + кэш конфигов ОНУшек (т.е. sqlite-овый config.db) + рантаймовые конфиги ОНУшек". К тому же и синхронизация этих параметров, похоже, триггерится не только командами конфигурирования ОНУшечных сабинтерфейсов (типа GPON0/1:2), как мне казалось. Но также и какими-то командами изменения профайлов, где-то на их многочисленных уровнях косвенных ссылок. Это судя по тому, как ушел от меня ОЛТ в начале эксперимента. 4) Чтобы разобраться, как работает весь этот кошмар а-ля "волновая функция вселенной", нужно иметь гораздо более глубокое знакомство с БДКомо-ЖПОНовой кухней, чем у меня сейчас имеется. Эпизодическими измерениями с привлечением монтажников не обойдешься. Строим стационарную тестовую точку с дистанционным управлением на территории лояльного клиента. И тогда продолжим...
  17. 1) Узел ОЛТа находится на чердаке пятиэтажки. Температура там та же самая, но более грязно и тесно. Правда, ветра нет. Но проводить там эксперименты с оптическими соединениями - обстановка не располагает. 2) Асимметричных делителей у нас в хозяйстве нет. Конечно, если проблема не решится за 50 залезаний на столбы к ПОН-боксам, будем городить конструкцию под ОЛТом и возвращать клиентский эзернет с ОНУшки ВЛАНом на техплощадку. Вот именно, что хрен его знает. В общечеловеческом понимании cir не резервируется за спящим клиентом (устройством, потоком), а гарантированно выделяется ему, если он проснется и попросит. Не попросит - выдается другим. А как сделано конкретными китайцами в конкретном продукте - это только жизнь покажет.
  18. Да нет, скорее админ, имеющий склонность к изящной словесности 🙂 Для клиентов с пакетами, отличных от 100Мбит, скорость всегда и нарезалась именно на БРАСах. А теперь, когда мы начинаем ставить гигабитные домовые свичи для пациентов с пакетами более 100М, шейпим на БРАСах и 100Мбит тоже. Но год назад, когда этот ПОН запускался, 100Мбитные полосы нарезались физикой, благо она такая в природе существует и работает совершенно бесплатно. Но отдавать весь шейпинг/полисинг на БРАСы тоже нельзя. Заведет, к примеру, себе пациент Микротика с открытым в мир 53/udp портом. Через пару дней он уже будет красоваться на Shodan-е, а на третий день добрые люди запишут его в свой ботнет и пристроят к хорошему делу - DNS-amplification-ом заниматься. Или еще лучше, простого трояна пациент заведет, такого который udp во все стороны рассылает что есть силы. Этот аплоуд на БРАСе шейпить уже поздно будет. Боюсь, что для ПОНа это будет немногим лучше той "светящей" ОНУшки, если эти порывы прямо на ОНУшке не гасить. Да я понимаю. Я собственно к минимуму и свожу. Но без вышеописанного ограничения аплоуда и особенно без loopback-detect-a на ОНУ жить нельзя вообще в принципе. Я на стенде петлю пробовал делать на ОНУШке, подключенной к этому самому ОЛТу, когда еще китайцы loopback-detect-а не завезли. Так там не то, что все клиенты отваливались, там ОЛТ в синюю асфиксию впадал необратимо. Случись это не на стенде, а в природе, я даже и не знаю, как бы я это восстанавливал. Мне такой расчет тоже в голову приходил. Я даже перемножал в Экселе скорости аплоуда на количества ОНУшек на порту. Получалось не слишком ровно, но тенденция просматривается. Увы, проверять, новые гипотезы у меня снова не получается. Даже вчерашнюю гипотезу (с отключением rate-limit-профайла) проверить окончательно не удается, хотя она вполне вероятно, уже и может решить проблему. Мои монтажники опять перемерзли на аварийных работах и теперь натирают тюленьим жиром отмороженные пальцы, которые еще можно спасти от ампутации. Следующий ориентировочный срок для измерений - завтра в первой половине дня.
  19. 1. В способности ОЛТа работать в роли L2-свича я (пока) не сомневаюсь. В распределительной сети в точке подключения ОЛТа с нагрузкой и скоростями все в порядке. Там и домовой свич есть, обслуживающий локальных клиентов дома, где стоит ОЛТ. Все у них нормально. 2. В дефолтном конфиге есть ограничение аплоуда на 1 Гигабит (gpon profile onu-rate-limit ratelimit-default id 1). Я заменил Гигабит на желательные мне 100Мбит. Поясню логику этих манипуляций (не пытаясь оправдать полученный результат): исторически у нас основная масса клиентов (не-ПОН-овских) имеют тарифную скорость 100Мбит и подключены к портам домовых свичей, тоже 100-Мбитных. Учитывая это чудесное совпадение и желая облегчить жизнь БРАСов, мы к 100-Мбитным клиентам шейперов на БРАСах не применяли вообще, полагаясь на ограничения физики. (Так было на момент первоначального конфигурирования ОЛТа, сейчас шейперы есть у всех клиентов). С появлением ПОНа и ОНУшек с Гигабитным клиентским портом возникло желание воспроизвести эту схему и на ПОНе. Данный rate-limit-profile есть результат попытки ограничить скорость клиента 100Мбитами силами самого ПОНа (методом китайского тыка). Вместе с аналогичным tcont-profile-ом и uni-profile-ом, упомянутым ниже. Сейчас выясняется, что попытка была неудачная. Но на стенде этого видно не было. Однако изыскания, проведенные вчера на закате дня, указывают, что собака зарыта, похоже, именно в этом месте. Путем удаления восходящего rate-limit-profile из virtualport-profile-а и ручного переконфигурирования тестовой ОНУшки сразу же получилось добиться скорости аплоуда в 85 Мбит/с. К сожалению, довести изыскания до конца вчера не удалось, ввиду того, что к моменту испытаний солнце уже почти село, мороз достиг -10 градусов и в сгустившихся сумерках руки монтажников-испытателей уже примерзали к ноутбуку, патч-корд к ОНУшке, а генератор постоянно глох. (Наши изыскания проводятся на открытом воздухе под столбами, на которых висят ПОН-боксы, и да, наш тестовый ноутбук работает от двухтактного бензинового генератора). Сегодня ночью я перегрузил ОЛТа с подправленным конфигом (профайлами) и надеюсь к концу дня повторить испытания и получить более надежные результаты. 3. Этот uni-profile - вариация на ту же тему про ограничение в 100Мбит. И как раз он - это правильный способ добиться такого ограничения (в отличие от предыдущих). Он ставит физическую скорость эзернет-порта ОНУшки в 100Мбит. Работает как должно. 4. Про сетевушку тестового ноутбука ничего сказать не могу, кроме того, что она встроенная и 100Мбитная. Но она правильная, со своими тестовыми задачами справляется и скорость в 90-95 Мбит/с выдает.
  20. Кого вы называете "активными клиентами"? Я употреблял аналогичное выражение "активная ОНУ" в смысле "ОНУ, имеющая что послать в сеть в данный момент". Если речь идет о таких "активных клиентах", то их количество меняется несколько раз в секунду. Так что посчитать их в буквальном смысле очень затруднительно. Можно как-то оценить их количество, активность и влияние на пропускную способность сети глядя на объем трафика. Как я уже писал, трафик в PON-ах небольшой, порядка 200Мбит/с вниз / 30МБит/с вверх в момент наибольшей загрузки на самых загруженных портах. В среднем по времени и по палате - намного меньше. От насыщения физики пока очень далеко. Если вы говорите о ком-то/чем-то другом, например, о количестве активных клиентских подключений на БРАСах / на порт, то это посчитать как-то можно, но на мой взгляд, это не имеет прямого отношения к проблеме. Просто зарегистрированных ОНУшек на портах от 20-и до 75-и, в среднем около 40-а. Счастья нет ни на одном из портов. Степень несчастья варьирует. Я все же надеюсь, что у меня нет отдельной безумной ОНУшки на каждом порту. Пока надеюсь 🙂
  21. 1. Эти строки получены из virtual-port профайла, присутствующего в дефолтном конфиге путем его копирования с заменой предположительного значения скорости в 1 Гбит/с на желательные 100 Мбит/с. Сделано, конечно, не в результате трезвого понимания своих действий, а под влиянием интуитивного представления, что "в дефолтном конфиге все должно быть более-менее нормально, надо только слегка подкрутить". Это представление подкреплялось и тем обстоятельством, что на стенде этот конфиг проблем не вызывал. Будут ли положительные изменения при удалении указанных лимиттеров, проверить прямо сейчас не могу. Как только возможность (свободные монтажники в поле) появится - проверю. 2. Уровни на разных портах разные: 1: -27,6 ... -22,7 2: -26,3 ... -21,2 3: -33 ... -20,7 4: -32,2 ... -21 5: -24,3 ... -19,4 6: -30 ... -20,6 7: -31,5 ... -21,3 8: -28,8 ... -22,8 Однако, как я уже писал, скорость аплоуда по моим наблюдениям не зависит от уровней сигнала ОНУшек. Она низкая даже на 5-м порту, где слабых ОНУшек нет. И отключение слабых ОНУшек улучшает в аплоуд не более, чем отключение любых других ОНУшек: важно только количество отключаемых ОНУ. Чем меньше ОНУшек остается на порту, тем лучше аплоуд. Но он не хорош, даже когда все слабые ОНУшки отключены. 3. Если вы имеет в виду "sh int", то ошибок там нет (в значимых количествах). 4. Подключение тестового ноутбука прямо в порт ОЛТа - операция инвазивная и не очень информативная: без сплиттеров/атенюаторов линия не заведется, а если там городить искусственную конструкцию, то и результаты будут иметь косвенное отношение к реальности. Поэтому от такого исследования пока воздержусь. Как я писал в начале, на стенде с тем же ОЛТом, с тем же (с точностью до количества ОНУшек) конфигом и с 2-я ОНУшками все было хорошо.
  22. Ну тогда следующей ночью так и попробую.
  23. А можно уточнить: что значит удалить все? К примеру удаление файла config.db, в котором хранятся, насколько я понимаю закэшированные конфиги ОНУ-шек - это правильный способ? И не приведет ли это к неспособности ОЛТа загрузиться? Честно говоря, боязно экспериментировать на живую.
  24. Да я понимаю, что беда где-то в этой области: cir/pir/shaper/policer и т.п.. Так прямо сразу и написал. Вот только не понимаю пока, где конкретно. DBA-профайла в этом ОЛТе нет вообще (или я о нем не знаю). Это меня тоже сильно смущает. С физикой значимых проблем нет: уровни сигнала приемлемые, потерь пакетов нет, скорость не рваная, а ровно (но неправильно) нарезанная. Я хочу, чтобы скорость делилась не между подключенными терминалами (в том числе спящими, ковыряющими в носе и размышляющими о жизни). А между терминалами, реально запросившими передачу данных, в пределах выделенных cir/pir/eir-ов. Такой способ разделения полосы называется Dynamic Badwidth Allocation (DBA) и присутствует в стандарте GPON-а, во всех вменяемых реализациях EPON-а (за отсутствием там стандарта) и во всех вменяемых технологиях, использующих TDM (под разными названиями). PON без такой фичи мне точно не нужен. У меня на БДКОМе оно аналогично выглядит. Но то ли я неправильно пишу эти профайлы, то ли ОЛТ неправильно их понимает. У меня стоит 3-й тип трафика, и в нем 8Мбит гарантированных и 100М максимальных. С виду ничего криминального, должно быть хорошо. А на деле плохо. Дело именно в полосе, а не в физике. Я точно про аплоуд. Загрузка PON-портов очень небольшая в обоих направлениях. Думаю, что не в норме, судя по результатам (если вы про шейперы ОЛТа и/или ОНУ). Только я не знаю, как это поправить. Где начинаются настройки ОНУшек и заканчиваются настройки ОЛТа (т.е. кто именно нарезает скорость аплоуда) из конфига и документации тоже, кстати, не видно. В общем мораль похоже такова, что надо брать и крутить все скоростные (и возможно не только) настройки во все стороны, пока что-то не прояснится. Жду, пока монтажники построят тестовую точку подключения под крышей дома лояльного клиента. А дальше займусь исследованием этой темной материи.
  25. Полноценно испытать прошивку BD_GP3616_10.3.0C_46550 не удалось. С текущим конфигом ОНУшки подключиться не смогли, ОЛТ ругался на незнакомую команду "cmd-sequence 004 gpon onu loopback-detect protocol private". После удаления этой команды из профилей конфигурирования ОНУ слегка полегчало: ОНУшки подключились. Но клиенты подключиться уже не смогли. Трафик в клиентских ВЛАНах над ОЛТом полностью отсутствовал. От дальнейших экспериментов над живыми людьми я пока воздержался. Попробую еще поэкспериментировать с прошивкой 46550 ночью, постепенно упрощая конфиг до такого состояния, что клиенты таки смогут подключиться. Хотя жить с такой прошивкой (без loopback-detect-а) сколько-нибудь долго нельзя, только на время эксперимента. Либо придется искать другое решение.
×