mpolk

Сам отвечаю на поставленный мною же вопрос. Да, возможно. Но с оговорками. После двух месяцев эксплуатации нового БРАСа в реальной среде уже можно что-то сказать. Сервер мы купили не совсем такой, как хотелось, а такой, какой был на складе. Процессор хотели 7302, а получили 7282 (номинальная тактовая 2.8 ГГц вместо 3.0, а ядер столько же, т.е. 16). И материнская плата Supermicro H11SSL-i, т.е. под предыдущее поколение ЭПИКов, но с проапгрейженным под второе поколение БИОСом. Памяти пришлось поставить 32Г, чтобы занять хотя бы 4 канала. Хотя по объему мне бы и 2-х Г хватило. Сист

Да нет, я не такой отчаянный, чтобы свежеиспеченный дистрибутив прямо на сервера ставить. У меня на тех серверах клиенты, по несколько тысяч на каждом, и среди них встречаются очень неприятные и злопамятные люди. Я примерно про это и спрашивал. А @nedoinet пояснил. Если бы было на чем, я бы прямо на этом чем-то и испытывал (и вопросов бы, скорее всего, не задавал). Но это что-то стоит около 90 килогривен. Так что я решил предварительно поспрашивать.

А у вторых Эпиков это уже не так, насколько я понимаю. У них теперь нет локальной памяти для ядер. Вся память колхозная. Это, конечно ухудшает показатели для отдельных ядер, но в среднем по палате показатели по словам АМД-ов улучшаются.

О, вот это тоже интересный вопрос, и не все с ним ясно. Похоже, вы что-то про это знаете. Убунта 18.04 - это хорошо, это бы меня устроило. А вот ядро какое имеется в виду? Родное, 4.15? Или потребуется с HWE-ядрами мучаться? И еще. А в каком смысле новый процессор (в данном случае EPYC2) может не поддерживаться той или иной ОС? Вот прямо так не загрузится система с дистрибутивной флэшки или не установится? Или какие-то новые фичи работать не будут? Сколько я жил раньше, не разу не видел, чтобы Линукс не захотел работать именно из-за процессора, а теперь вот такие разговоры появилис

Спасибо, это уже кое-что. Думаю, если Эпик-первый годен к такому делу, то и второй должен потянуть.

Так а вы пробовали? Или это просто теоретическая концепция, которую неплохо было бы проверить, например, на мне? 😀

Доброго времени суток, Есть ли у кого-то практический опыт построения софтового (Линуксового) BRAS-а на платформе AMD EPYC2 (ну или хотя бы на просто EPYC)? Если да, наблюдаются ли какие-то специфические для данной платформы проблемы: с производительностью, балансировкой прерываний от сетевых плат, RSS, RPS и т.д.? Что известно про совместимость с 10G-сетевыми платами (от Intel и Mellanox)? Какие сетевухи предпочтительнее? Дополнительное требование: у нас клиенты подключаются по PPPoE, поэтому необходим именно правильно работающий RPS. Мы традиционно с

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

А тот способ, который я вам предлагал, чем вас не устраивает? Или он не работает?

И так, проблема, наконец, была решена (если это кому-нибудь еще интересно). Еще месяц техподдержка ДЕПСа всячески мордовала меня, заставляя снова проверять качество аплинка, пускать трафик iperf-а в обход PPPoE и перебирая все известные им способы не заниматься проблемой напрямую. Наконец, мне была дана Скайп-аудиенция с младшим чиновником провинции Фу Цзянь по делам серверных варваров. Чиновник оказался женска полу: ко мне вышла девушка в огромных очках и с длинными волосами, как в фильме "Шанхайский дракон 4" (если, конечно, верить аватарке) и показала настоящее кунг-

Добрый день, А отдельно DEM-412X не продадите (если есть еще)?

Куплю вышеупомянутый модуль (если кто-нибудь мне его продаст). Заплачу деньги.

Добрый день, а один DEM-412X не продадите?

Для тех, кому интересно, описываю дальнейший ход изысканий. Были организованы две тестовых точки: 1) Автономно работающий ноутбук с Линуксом, автоматически подключающийся к серверам доступа через PON-сеть (через 1-й порт ОЛТ-а). На нем установлен iperf3, с помощью которого можно тестировать скорость аплоуда между ноутбуком и сервером доступа, к которому он в данный момент подключен. Данная точка размещена у одного из клиентов, с которым имеется договоренность на этот счет. 2) ОНУ-шка, подключенная прямо к порту ОЛТ-а (в данный момент к тому же 1-у порту) чер

Вчера провели, наконец, измерения скорости, довольно подробные, с кручением рукояток в разные стороны. Результаты такие, что лучше бы мне их не видеть никогда. 0) Исходное состояние: еще в ночь с четверга на пятницу в общеклиентский rate-limit-профайл прописаны дефолтные значения (pir 1244160 cir 1244160), все это записано а в startup-config и ОЛТ перезагружен с этим конфигом. Уже тогда были предварительные данные, что аплоуд с таким конфигом будет хороший (85Мбит/с). 1) В субботу утром подключаемся и начинаем мерить. Действительно, 85 Мбит/с. На разных ОНУшках. (Как потом вы

1) Узел ОЛТа находится на чердаке пятиэтажки. Температура там та же самая, но более грязно и тесно. Правда, ветра нет. Но проводить там эксперименты с оптическими соединениями - обстановка не располагает. 2) Асимметричных делителей у нас в хозяйстве нет. Конечно, если проблема не решится за 50 залезаний на столбы к ПОН-боксам, будем городить конструкцию под ОЛТом и возвращать клиентский эзернет с ОНУшки ВЛАНом на техплощадку. Вот именно, что хрен его знает. В общечеловеческом понимании cir не резервируется за спящим клиентом (устройством, потоком), а гарантированно выд

Да нет, скорее админ, имеющий склонность к изящной словесности 🙂 Для клиентов с пакетами, отличных от 100Мбит, скорость всегда и нарезалась именно на БРАСах. А теперь, когда мы начинаем ставить гигабитные домовые свичи для пациентов с пакетами более 100М, шейпим на БРАСах и 100Мбит тоже. Но год назад, когда этот ПОН запускался, 100Мбитные полосы нарезались физикой, благо она такая в природе существует и работает совершенно бесплатно. Но отдавать весь шейпинг/полисинг на БРАСы тоже нельзя. Заведет, к примеру, себе пациент Микротика с открытым в мир 53/udp портом. Через пару

1. В способности ОЛТа работать в роли L2-свича я (пока) не сомневаюсь. В распределительной сети в точке подключения ОЛТа с нагрузкой и скоростями все в порядке. Там и домовой свич есть, обслуживающий локальных клиентов дома, где стоит ОЛТ. Все у них нормально. 2. В дефолтном конфиге есть ограничение аплоуда на 1 Гигабит (gpon profile onu-rate-limit ratelimit-default id 1). Я заменил Гигабит на желательные мне 100Мбит. Поясню логику этих манипуляций (не пытаясь оправдать полученный результат): исторически у нас основная масса клиентов (не-ПОН-овских) имеют тарифную скорость 100Мбит

Кого вы называете "активными клиентами"? Я употреблял аналогичное выражение "активная ОНУ" в смысле "ОНУ, имеющая что послать в сеть в данный момент". Если речь идет о таких "активных клиентах", то их количество меняется несколько раз в секунду. Так что посчитать их в буквальном смысле очень затруднительно. Можно как-то оценить их количество, активность и влияние на пропускную способность сети глядя на объем трафика. Как я уже писал, трафик в PON-ах небольшой, порядка 200Мбит/с вниз / 30МБит/с вверх в момент наибольшей загрузки на самых загруженных портах. В среднем по времени и по палате - на

1. Эти строки получены из virtual-port профайла, присутствующего в дефолтном конфиге путем его копирования с заменой предположительного значения скорости в 1 Гбит/с на желательные 100 Мбит/с. Сделано, конечно, не в результате трезвого понимания своих действий, а под влиянием интуитивного представления, что "в дефолтном конфиге все должно быть более-менее нормально, надо только слегка подкрутить". Это представление подкреплялось и тем обстоятельством, что на стенде этот конфиг проблем не вызывал. Будут ли положительные изменения при удалении указанных лимиттеров, проверить прямо сейчас не могу

Ну тогда следующей ночью так и попробую.

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

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

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

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