mpolk
-
Всього повідомлень
26 -
Приєднався
-
Останній візит
-
Дней в лидерах
1
Тип контенту
Профили
Форум
Календарь
Сообщения додав mpolk
-
-
5 минут назад, ISK сказал:
20.04 LTS не за горами - там 5.4 уже будет, подождите уже пару месяцев...
Да нет, я не такой отчаянный, чтобы свежеиспеченный дистрибутив прямо на сервера ставить. У меня на тех серверах клиенты, по несколько тысяч на каждом, и среди них встречаются очень неприятные и злопамятные люди.
5 минут назад, ISK сказал:Эм-м-м... как это?😲 Архитектура команд amd64 как бы не менялась уже 20 лет... Другое дело дрова чтобы выжать максимум производительности, это да...
Я примерно про это и спрашивал. А @nedoinet пояснил.
5 минут назад, ISK сказал:Так проверьте в тестовом режиме, если есть на чем...
Если бы было на чем, я бы прямо на этом чем-то и испытывал (и вопросов бы, скорее всего, не задавал). Но это что-то стоит около 90 килогривен. Так что я решил предварительно поспрашивать.
-
10 минут назад, nedoinet сказал:
у эпиков самое слабое место это infinity fabric - если вдруг приспичит гонять данные между кристалами или ядру захочется порыться в памяти к которой у него нет прямого доступа.
А у вторых Эпиков это уже не так, насколько я понимаю. У них теперь нет локальной памяти для ядер. Вся память колхозная. Это, конечно ухудшает показатели для отдельных ядер, но в среднем по палате показатели по словам АМД-ов улучшаются.
-
43 минуты назад, nedoinet сказал:
необходима бубунта 18.04 и выше. другие дистры - курите в какой версии есть нормальная поддержка архитектур zen/zen2
О, вот это тоже интересный вопрос, и не все с ним ясно. Похоже, вы что-то про это знаете. Убунта 18.04 - это хорошо, это бы меня устроило. А вот ядро какое имеется в виду? Родное, 4.15? Или потребуется с HWE-ядрами мучаться?
И еще. А в каком смысле новый процессор (в данном случае EPYC2) может не поддерживаться той или иной ОС? Вот прямо так не загрузится система с дистрибутивной флэшки или не установится? Или какие-то новые фичи работать не будут? Сколько я жил раньше, не разу не видел, чтобы Линукс не захотел работать именно из-за процессора, а теперь вот такие разговоры появились о (не-)совместимости. От того и недоумеваю.
6 минут назад, anti-stels сказал:собираем брасы на ryzen, брат жив.
Спасибо, обнадеживает.
-
8 минут назад, Nubs сказал:
Два сервера на EPYC 7371, проц неплохой но выгоднее e5 2690v2/v3 с алика пока что ничего не придумали, такие два проца 100гиг проглотят на ура
Спасибо, это уже кое-что. Думаю, если Эпик-первый годен к такому делу, то и второй должен потянуть.
-
4 минуты назад, Nubs сказал:
Разницы никакой нет, главное на частоту памяти не забивать
Так а вы пробовали? Или это просто теоретическая концепция, которую неплохо было бы проверить, например, на мне? 😀
-
Доброго времени суток,
Есть ли у кого-то практический опыт построения софтового (Линуксового) 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. Глядя на теперешние блок-схемы и даташиты Эпиков я не нахожу ничего ужасного. Но не скрывается ли оно где-то в глубине?
-
32 минуты назад, andryas сказал:
Не використовую цього пристрою, принаймні, поки що, але висловлюю свою повагу, за те що рішення проблеми опубліковане.
До речі, як себе показує це обладнання у плані стабільності?
В плане стабильности у него все вроде бы в порядке.
Единственный несчастный случай был зафиксирован года полтора назад еще до начала промышленной эксплуатации. ОЛТ был впервые вынесен в поле и засунут в ящик на чердаке. Живых пациентов мы к нему по-моему еще не подключали, просто хотели посмотреть, как на него свежий воздух подействует и бодрящая атмосфера летнего чердака в хрущовке.
Примерно через сутки ОЛТ исчез с экранов радаров и больше не появлялся. Его вытащили из ящика и положили на анатомический стол. Вскрытие показало, что перед смертью покойник сильно потел и стер себе содержимое флэшки, так что грузиться ему было уже неоткуда. Возникла гипотеза, что ОЛТ не любит жары, но ДЕПС уверил, что эти ОЛТы и не такую температуру с легкостью выдерживают, и что это первый такой случай в их практике. Мы поверили, восстановили прошивку (уже не помню как) и вернули ОЛТа на чердак. Там он с тех пор и работает без каких-либо нареканий (не считая проблемы, описанной в данной теме).
Но запасной экземпляр мы на всякий случай держим.
Главная проблема с этим железом - отсутствие нормальной документации. Из документации есть только:
1) 22 тома наставлений от БДКома про "свичи вообще", где описано, как свичи перезагружать и смотреть на них время. Про GPON там сказано только то, что, чтобы посмотреть посмотреть информацию об ОНУшках, надо прямо так и сказать: show gpon onu-info. И т.п.2) "Малая книга заклинаний" от ДЕПСа. По объему и информативности примерно соответствует двум страницам из рукописи Войнича, только без картинок. Если этих заклинаний не хватает, то надо просить аудиенции у Вендоров (см. выше).
-
2
-
1
-
-
23 минуты назад, trsnah сказал:
Ну я уже месяц у ДЕПСа выбиваю ОИД, для снятия МАК адресов с ОНУшек (конечно мне кажется, что его даже не существует). Но тем не менее, мне дают не рабочие ОИДы и так по сей день ...
Я уже даже Вендору написал 😃
А тот способ, который я вам предлагал, чем вас не устраивает? Или он не работает?
-
И так, проблема, наконец, была решена (если это кому-нибудь еще интересно).
Еще месяц техподдержка ДЕПСа всячески мордовала меня, заставляя снова проверять качество аплинка, пускать трафик 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).
С тех пор у моих клиентов хороший аплоуд, а я хожу просветленный, мечтаю снова встретить ту девушку и очень не люблю ДЕПС.
-
3
-
4
-
-
Добрый день,
А отдельно DEM-412X не продадите (если есть еще)?
-
Куплю вышеупомянутый модуль (если кто-нибудь мне его продаст). Заплачу деньги.
-
Добрый день,
а один DEM-412X не продадите?
-
Для тех, кому интересно, описываю дальнейший ход изысканий.
Были организованы две тестовых точки:
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 в конфиге (правильными или неправильными), а неправильным распределением ОЛТ-ом восходящей полосы пропускания, вызванным ошибочным расчетом этого распределения ОЛТ-ом в момент поднятия линка на порту. Со временем (возможно, по мере переподключения ОНУ-шек) ОЛТ корректирует свои расчеты, и скорость приходит в норму.
Если это предположение верно, то проблема может быть решена только силами разработчиков ПО ОЛТ-а. Ждем фидбэка от них.
-
1
-
-
Вчера провели, наконец, измерения скорости, довольно подробные, с кручением рукояток в разные стороны. Результаты такие, что лучше бы мне их не видеть никогда.
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) Чтобы разобраться, как работает весь этот кошмар а-ля "волновая функция вселенной", нужно иметь гораздо более глубокое знакомство с БДКомо-ЖПОНовой кухней, чем у меня сейчас имеется. Эпизодическими измерениями с привлечением монтажников не обойдешься.
Строим стационарную тестовую точку с дистанционным управлением на территории лояльного клиента. И тогда продолжим...
-
5
-
-
9 часов назад, nedoinet сказал:
А почему нельзя включится на узле, где стоит олт? Электрика в розетке и условия труда по идее интереснее. Сделать себе отвод делителем 5/95 через sc-шки. И вся ветка в ваших руках
1) Узел ОЛТа находится на чердаке пятиэтажки. Температура там та же самая, но более грязно и тесно. Правда, ветра нет. Но проводить там эксперименты с оптическими соединениями - обстановка не располагает.
2) Асимметричных делителей у нас в хозяйстве нет.
Конечно, если проблема не решится за 50 залезаний на столбы к ПОН-боксам, будем городить конструкцию под ОЛТом и возвращать клиентский эзернет с ОНУшки ВЛАНом на техплощадку.
10 часов назад, foreverok сказал:Ну хрен знает как оно работает в этих чудных устройствах.
Однако определенная логика есть. cir - это гарантированная полоса, значит должна резервироваться.
gpon-profile pir 100000 cir 100000 - я не с потолка взял, это из конфига ТС. Потому рекомендую уменьшить cir до 10000
Вот именно, что хрен его знает. В общечеловеческом понимании cir не резервируется за спящим клиентом (устройством, потоком), а гарантированно выделяется ему, если он проснется и попросит. Не попросит - выдается другим. А как сделано конкретными китайцами в конкретном продукте - это только жизнь покажет.
-
3 часа назад, fet4 сказал:
mpolk! Вы случаем не писатель, решивший заняться сетевыми технологиями ? Интересно читать Ваше повествование проблемы! Чем же все закончится ?!
Да нет, скорее админ, имеющий склонность к изящной словесности 🙂
3 часа назад, logic сказал:а не пробували різати швидкість не на олті а на серваку ?
Для клиентов с пакетами, отличных от 100Мбит, скорость всегда и нарезалась именно на БРАСах. А теперь, когда мы начинаем ставить гигабитные домовые свичи для пациентов с пакетами более 100М, шейпим на БРАСах и 100Мбит тоже. Но год назад, когда этот ПОН запускался, 100Мбитные полосы нарезались физикой, благо она такая в природе существует и работает совершенно бесплатно.
Но отдавать весь шейпинг/полисинг на БРАСы тоже нельзя. Заведет, к примеру, себе пациент Микротика с открытым в мир 53/udp портом. Через пару дней он уже будет красоваться на Shodan-е, а на третий день добрые люди запишут его в свой ботнет и пристроят к хорошему делу - DNS-amplification-ом заниматься. Или еще лучше, простого трояна пациент заведет, такого который udp во все стороны рассылает что есть силы. Этот аплоуд на БРАСе шейпить уже поздно будет. Боюсь, что для ПОНа это будет немногим лучше той "светящей" ОНУшки, если эти порывы прямо на ОНУшке не гасить.
3 часа назад, ISK сказал:ТС на заметку: не весь зоопарк китайских ОНУ умеет адекватно шейпить и детектить петли (была и такая, которая вообще игнорила темплейт), поэтому их конфигурирование должно быть сведено к минимуму.
Да я понимаю. Я собственно к минимуму и свожу. Но без вышеописанного ограничения аплоуда и особенно без loopback-detect-a на ОНУ жить нельзя вообще в принципе. Я на стенде петлю пробовал делать на ОНУШке, подключенной к этому самому ОЛТу, когда еще китайцы loopback-detect-а не завезли. Так там не то, что все клиенты отваливались, там ОЛТ в синюю асфиксию впадал необратимо. Случись это не на стенде, а в природе, я даже и не знаю, как бы я это восстанавливал.
1 час назад, foreverok сказал:Активные, в смысле включенные в розетку и имеющие линк с OLT. Пока что у Вас примерно так и есть, что скорость upload равна 1,2Gbps разделить на количество активных онух.
Много писать не люблю, поэтому попробуйте поменять,
gpon-profile pir 100000 cir 100000 (cir уменьшите скажем до 10000).
судя по всему тут собака порылась.
Мне такой расчет тоже в голову приходил. Я даже перемножал в Экселе скорости аплоуда на количества ОНУшек на порту. Получалось не слишком ровно, но тенденция просматривается.
Увы, проверять, новые гипотезы у меня снова не получается. Даже вчерашнюю гипотезу (с отключением rate-limit-профайла) проверить окончательно не удается, хотя она вполне вероятно, уже и может решить проблему. Мои монтажники опять перемерзли на аварийных работах и теперь натирают тюленьим жиром отмороженные пальцы, которые еще можно спасти от ампутации. Следующий ориентировочный срок для измерений - завтра в первой половине дня.
-
7 часов назад, sanyadnepr сказал:
1. Подключить тестовый ноут медью в ОЛТ, без Гпона и проверить, скорость исхода есть ?
2. Откуда взялся "дефолтный конфиг" не припомню рейт-лимита 100М в дефолте.
3. Откуда это и с какой целью ? В дефолте этого нет.
! gpon profile onu-uni uni-general id 2 gpon-profile speed 100 gpon-profile eth-wiring auto !4. Сетевушка тестера какая ?
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 Мбит/с выдает.
-
8 часов назад, foreverok сказал:
Так сколько? 5-10-20 и тд (именно активных).
Или тут у всех стабильно скорость UPLOAD 100Mbit+ на деревьях с более чем 20 активными клиентами?
Кого вы называете "активными клиентами"? Я употреблял аналогичное выражение "активная ОНУ" в смысле "ОНУ, имеющая что послать в сеть в данный момент". Если речь идет о таких "активных клиентах", то их количество меняется несколько раз в секунду. Так что посчитать их в буквальном смысле очень затруднительно. Можно как-то оценить их количество, активность и влияние на пропускную способность сети глядя на объем трафика. Как я уже писал, трафик в PON-ах небольшой, порядка 200Мбит/с вниз / 30МБит/с вверх в момент наибольшей загрузки на самых загруженных портах. В среднем по времени и по палате - намного меньше. От насыщения физики пока очень далеко.
Если вы говорите о ком-то/чем-то другом, например, о количестве активных клиентских подключений на БРАСах / на порт, то это посчитать как-то можно, но на мой взгляд, это не имеет прямого отношения к проблеме.
Просто зарегистрированных ОНУшек на портах от 20-и до 75-и, в среднем около 40-а. Счастья нет ни на одном из портов. Степень несчастья варьирует.
3 часа назад, a_n_h сказал:У меня скорость "аплоад" падала когда в ветке онушка "светила" постоянно с уровнем порядка -20 дБ.
Я все же надеюсь, что у меня нет отдельной безумной ОНУшки на каждом порту. Пока надеюсь 🙂
-
2 часа назад, sanyadnepr сказал:
! gpon profile onu-rate-limit 100M id 2 gpon-profile pir 100000 cir 100000 ! gpon profile onu-virtual-port virtual-port-default id 1 gpon-profile encryption disable gpon-profile upstream queue 8 gpon-profile upstream rate-limit-profile ratelimit-default gpon-profile downstream queue 8 ! gpon profile onu-virtual-port vport-general id 2 gpon-profile encryption disable gpon-profile upstream queue 8 gpon-profile upstream rate-limit-profile 100M gpon-profile downstream queue 8 gpon-profile downstream rate-limit-profile 100M !1. Зачем эти строки в конфиге ? Зачем используется рейт-лимит ? Если его убрать, будут улучшения ?
2. Уровни сигналов всех ону мин-макс какие ?
3. sh run int ошибки есть ?
Сервер для измерения подключить напрямую в ОЛТ.
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-я ОНУшками все было хорошо.
-
4 часа назад, andruxovich сказал:
Если боязно - тогда через вебморду reset к заводским настройкам. Но, можно также удалить startup-config и config.db , перезагрузить и все будет хорошо.
Ну тогда следующей ночью так и попробую.
-
В 19.11.2019 в 13:03, andruxovich сказал:
У меня трафик не хотел бежать, как я не упрощал конфиг. В итоге удалил все, и настроил с нуля. Теперь работает. А проблема начиналась с плохой скорости, которая падала по мере роста кол-ва ону на голове (неважно в каких pon портах). В итоге дошел до момента, когда новые ону не получали конфиг. Если отключить пару зареганых ранее ону - новые получали конфиг. А насчёт разницы версий в sh run и sh conf - таки да, после обновления, или отката в sh run отображается текущая версия, в sh conf предыдущая. Если сделать write all - все становится одинаково.
А можно уточнить: что значит удалить все? К примеру удаление файла config.db, в котором хранятся, насколько я понимаю закэшированные конфиги ОНУ-шек - это правильный способ? И не приведет ли это к неспособности ОЛТа загрузиться? Честно говоря, боязно экспериментировать на живую.
-
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 сказал:Ааа, сорян.
Что то было и такое тут. В прошивках онух косяк был.
Кстате, а с шейпером все норм?
Думаю, что не в норме, судя по результатам (если вы про шейперы ОЛТа и/или ОНУ). Только я не знаю, как это поправить. Где начинаются настройки ОНУшек и заканчиваются настройки ОЛТа (т.е. кто именно нарезает скорость аплоуда) из конфига и документации тоже, кстати, не видно.
В общем мораль похоже такова, что надо брать и крутить все скоростные (и возможно не только) настройки во все стороны, пока что-то не прояснится. Жду, пока монтажники построят тестовую точку подключения под крышей дома лояльного клиента. А дальше займусь исследованием этой темной материи.
-
1
-
-
Полноценно испытать прошивку BD_GP3616_10.3.0C_46550 не удалось. С текущим конфигом ОНУшки подключиться не смогли, ОЛТ ругался на незнакомую команду "cmd-sequence 004 gpon onu loopback-detect protocol private". После удаления этой команды из профилей конфигурирования ОНУ слегка полегчало: ОНУшки подключились. Но клиенты подключиться уже не смогли. Трафик в клиентских ВЛАНах над ОЛТом полностью отсутствовал. От дальнейших экспериментов над живыми людьми я пока воздержался.
Попробую еще поэкспериментировать с прошивкой 46550 ночью, постепенно упрощая конфиг до такого состояния, что клиенты таки смогут подключиться. Хотя жить с такой прошивкой (без loopback-detect-а) сколько-нибудь долго нельзя, только на время эксперимента.Либо придется искать другое решение.
-
3 минуты назад, andruxovich сказал:
Вот здесь лежат прошивки http://bdcom.mega.dp.ua/files/
Спасибо. Пошел пробовать. По результатам отпишусь.
BRAS на Linux и AMD EPYC2: возможно ли?
в Залізо
Опубліковано: · Відредаговано mpolk
Сам отвечаю на поставленный мною же вопрос.
Да, возможно. Но с оговорками.
После двух месяцев эксплуатации нового БРАСа в реальной среде уже можно что-то сказать. Сервер мы купили не совсем такой, как хотелось, а такой, какой был на складе. Процессор хотели 7302, а получили 7282 (номинальная тактовая 2.8 ГГц вместо 3.0, а ядер столько же, т.е. 16). И материнская плата Supermicro H11SSL-i, т.е. под предыдущее поколение ЭПИКов, но с проапгрейженным под второе поколение БИОСом. Памяти пришлось поставить 32Г, чтобы занять хотя бы 4 канала. Хотя по объему мне бы и 2-х Г хватило. Систему поставили Ubuntu 18.04.
В результате получилось вот что:
Жить с этим в принципе можно, но обидно, т.к. совершенно нет уверенности, что ECC (да еще при таком конском объеме памяти) работает, как должно.
С HWE-ядром 5.3 EDAC опознается благополучно, но возиться с HWE-ядрами не хотелось бы.
Приёмистость нового БРАСа, т.е. скорость приема входящих пациентов, несколько ниже, чем у старых БРАСов. В результате, при нехватке пациентов новый сервер стоит недогруженным в то время, как его старшие товарищи трудятся в поте лица. Это, конечно не страшно: при выходе из строя какого-то из старых БРАСов новый тут же возьмет на себя его пациентов. Но неэстетично.
Балансировка нагрузки ядер трафиком со стороны пациентов (со стороны городской сети) тоже имеет некоторые проблемы. Со стороны Интернета трафик, в вместе с ним и загруженность ядер балансируется без проблем силами сетевого адаптера (RSS), потому что трафик там не инкапсулирован в PPPoE. А вот со стороны пациентов трафик инкапсулирован и потому попадает весь в одну очередь и на одно ядро. У нас это традиционно лечилось с помощью RPS, который далее раскидывает нагрузку равномерно по ядрам. На Интеловских серверах дополнительная нагрузка на ядро, обрабатывающее аппаратные прерывания, была практически незаметна. А новом БРАСе она оказалась очень даже заметной, так что сервер начинало перепирать задолго до того, как средняя нагрузка на все ядра становилась критической. Пришлось ядро, занятое аппаратными прерываниями, полностью освободить от дальнейшей обработки трафика. В результате оно оказывается недогруженным, но так как SoftIRQ-шная нагрузка, снятая с этого ядра, равномерно распределяется по 7-и остальным ядрам, то жить опять-таки можно. Не исключаю, что пробемы из пп. 3 и 4 могут быть как-то взаимосвязаны.