Jump to content
Local

mpolk

Muggles
  • Content Count

    26
  • Joined

  • Last visited

  • Days Won

    1

mpolk last won the day on June 12

mpolk had the most liked content!

Community Reputation

21 Очень хороший

About mpolk

  • Rank
    Пролетал Мимо
  • Birthday 01/01/1870

Информация

  • Интересы
    Созерцание прекрасного и размышления о возвышенном

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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. Да нет, я не такой отчаянный, чтобы свежеиспеченный дистрибутив прямо на сервера ставить. У меня на тех серверах клиенты, по несколько тысяч на каждом, и среди них встречаются очень неприятные и злопамятные люди. Я примерно про это и спрашивал. А @nedoinet пояснил. Если бы было на чем, я бы прямо на этом чем-то и испытывал (и вопросов бы, скорее всего, не задавал). Но это что-то стоит около 90 килогривен. Так что я решил предварительно поспрашивать.
  3. А у вторых Эпиков это уже не так, насколько я понимаю. У них теперь нет локальной памяти для ядер. Вся память колхозная. Это, конечно ухудшает показатели для отдельных ядер, но в среднем по палате показатели по словам АМД-ов улучшаются.
  4. О, вот это тоже интересный вопрос, и не все с ним ясно. Похоже, вы что-то про это знаете. Убунта 18.04 - это хорошо, это бы меня устроило. А вот ядро какое имеется в виду? Родное, 4.15? Или потребуется с HWE-ядрами мучаться? И еще. А в каком смысле новый процессор (в данном случае EPYC2) может не поддерживаться той или иной ОС? Вот прямо так не загрузится система с дистрибутивной флэшки или не установится? Или какие-то новые фичи работать не будут? Сколько я жил раньше, не разу не видел, чтобы Линукс не захотел работать именно из-за процессора, а теперь вот такие разговоры появились о (не-)совместимости. От того и недоумеваю. Спасибо, обнадеживает.
  5. Спасибо, это уже кое-что. Думаю, если Эпик-первый годен к такому делу, то и второй должен потянуть.
  6. Так а вы пробовали? Или это просто теоретическая концепция, которую неплохо было бы проверить, например, на мне? 😀
  7. Доброго времени суток, Есть ли у кого-то практический опыт построения софтового (Линуксового) 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. Глядя на теперешние блок-схемы и даташиты Эпиков я не нахожу ничего ужасного. Но не скрывается ли оно где-то в глубине?
  8. В плане стабильности у него все вроде бы в порядке. Единственный несчастный случай был зафиксирован года полтора назад еще до начала промышленной эксплуатации. ОЛТ был впервые вынесен в поле и засунут в ящик на чердаке. Живых пациентов мы к нему по-моему еще не подключали, просто хотели посмотреть, как на него свежий воздух подействует и бодрящая атмосфера летнего чердака в хрущовке. Примерно через сутки ОЛТ исчез с экранов радаров и больше не появлялся. Его вытащили из ящика и положили на анатомический стол. Вскрытие показало, что перед смертью покойник сильно потел и стер себе содержимое флэшки, так что грузиться ему было уже неоткуда. Возникла гипотеза, что ОЛТ не любит жары, но ДЕПС уверил, что эти ОЛТы и не такую температуру с легкостью выдерживают, и что это первый такой случай в их практике. Мы поверили, восстановили прошивку (уже не помню как) и вернули ОЛТа на чердак. Там он с тех пор и работает без каких-либо нареканий (не считая проблемы, описанной в данной теме). Но запасной экземпляр мы на всякий случай держим. Главная проблема с этим железом - отсутствие нормальной документации. Из документации есть только: 1) 22 тома наставлений от БДКома про "свичи вообще", где описано, как свичи перезагружать и смотреть на них время. Про GPON там сказано только то, что, чтобы посмотреть посмотреть информацию об ОНУшках, надо прямо так и сказать: show gpon onu-info. И т.п. 2) "Малая книга заклинаний" от ДЕПСа. По объему и информативности примерно соответствует двум страницам из рукописи Войнича, только без картинок. Если этих заклинаний не хватает, то надо просить аудиенции у Вендоров (см. выше).
  9. А тот способ, который я вам предлагал, чем вас не устраивает? Или он не работает?
  10. И так, проблема, наконец, была решена (если это кому-нибудь еще интересно). Еще месяц техподдержка ДЕПСа всячески мордовала меня, заставляя снова проверять качество аплинка, пускать трафик 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). С тех пор у моих клиентов хороший аплоуд, а я хожу просветленный, мечтаю снова встретить ту девушку и очень не люблю ДЕПС.
  11. mpolk

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

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

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

    Добрый день, а один DEM-412X не продадите?
  14. Для тех, кому интересно, описываю дальнейший ход изысканий. Были организованы две тестовых точки: 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 в конфиге (правильными или неправильными), а неправильным распределением ОЛТ-ом восходящей полосы пропускания, вызванным ошибочным расчетом этого распределения ОЛТ-ом в момент поднятия линка на порту. Со временем (возможно, по мере переподключения ОНУ-шек) ОЛТ корректирует свои расчеты, и скорость приходит в норму. Если это предположение верно, то проблема может быть решена только силами разработчиков ПО ОЛТ-а. Ждем фидбэка от них.
  15. Вчера провели, наконец, измерения скорости, довольно подробные, с кручением рукояток в разные стороны. Результаты такие, что лучше бы мне их не видеть никогда. 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) Чтобы разобраться, как работает весь этот кошмар а-ля "волновая функция вселенной", нужно иметь гораздо более глубокое знакомство с БДКомо-ЖПОНовой кухней, чем у меня сейчас имеется. Эпизодическими измерениями с привлечением монтажников не обойдешься. Строим стационарную тестовую точку с дистанционным управлением на территории лояльного клиента. И тогда продолжим...
×