Jump to content
Local

mpolk

Muggles
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

7 Обычный

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. Для тех, кому интересно, описываю дальнейший ход изысканий. Были организованы две тестовых точки: 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 в конфиге (правильными или неправильными), а неправильным распределением ОЛТ-ом восходящей полосы пропускания, вызванным ошибочным расчетом этого распределения ОЛТ-ом в момент поднятия линка на порту. Со временем (возможно, по мере переподключения ОНУ-шек) ОЛТ корректирует свои расчеты, и скорость приходит в норму. Если это предположение верно, то проблема может быть решена только силами разработчиков ПО ОЛТ-а. Ждем фидбэка от них.
  2. Вчера провели, наконец, измерения скорости, довольно подробные, с кручением рукояток в разные стороны. Результаты такие, что лучше бы мне их не видеть никогда. 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) Чтобы разобраться, как работает весь этот кошмар а-ля "волновая функция вселенной", нужно иметь гораздо более глубокое знакомство с БДКомо-ЖПОНовой кухней, чем у меня сейчас имеется. Эпизодическими измерениями с привлечением монтажников не обойдешься. Строим стационарную тестовую точку с дистанционным управлением на территории лояльного клиента. И тогда продолжим...
  3. 1) Узел ОЛТа находится на чердаке пятиэтажки. Температура там та же самая, но более грязно и тесно. Правда, ветра нет. Но проводить там эксперименты с оптическими соединениями - обстановка не располагает. 2) Асимметричных делителей у нас в хозяйстве нет. Конечно, если проблема не решится за 50 залезаний на столбы к ПОН-боксам, будем городить конструкцию под ОЛТом и возвращать клиентский эзернет с ОНУшки ВЛАНом на техплощадку. Вот именно, что хрен его знает. В общечеловеческом понимании cir не резервируется за спящим клиентом (устройством, потоком), а гарантированно выделяется ему, если он проснется и попросит. Не попросит - выдается другим. А как сделано конкретными китайцами в конкретном продукте - это только жизнь покажет.
  4. Да нет, скорее админ, имеющий склонность к изящной словесности 🙂 Для клиентов с пакетами, отличных от 100Мбит, скорость всегда и нарезалась именно на БРАСах. А теперь, когда мы начинаем ставить гигабитные домовые свичи для пациентов с пакетами более 100М, шейпим на БРАСах и 100Мбит тоже. Но год назад, когда этот ПОН запускался, 100Мбитные полосы нарезались физикой, благо она такая в природе существует и работает совершенно бесплатно. Но отдавать весь шейпинг/полисинг на БРАСы тоже нельзя. Заведет, к примеру, себе пациент Микротика с открытым в мир 53/udp портом. Через пару дней он уже будет красоваться на Shodan-е, а на третий день добрые люди запишут его в свой ботнет и пристроят к хорошему делу - DNS-amplification-ом заниматься. Или еще лучше, простого трояна пациент заведет, такого который udp во все стороны рассылает что есть силы. Этот аплоуд на БРАСе шейпить уже поздно будет. Боюсь, что для ПОНа это будет немногим лучше той "светящей" ОНУшки, если эти порывы прямо на ОНУшке не гасить. Да я понимаю. Я собственно к минимуму и свожу. Но без вышеописанного ограничения аплоуда и особенно без loopback-detect-a на ОНУ жить нельзя вообще в принципе. Я на стенде петлю пробовал делать на ОНУШке, подключенной к этому самому ОЛТу, когда еще китайцы loopback-detect-а не завезли. Так там не то, что все клиенты отваливались, там ОЛТ в синюю асфиксию впадал необратимо. Случись это не на стенде, а в природе, я даже и не знаю, как бы я это восстанавливал. Мне такой расчет тоже в голову приходил. Я даже перемножал в Экселе скорости аплоуда на количества ОНУшек на порту. Получалось не слишком ровно, но тенденция просматривается. Увы, проверять, новые гипотезы у меня снова не получается. Даже вчерашнюю гипотезу (с отключением rate-limit-профайла) проверить окончательно не удается, хотя она вполне вероятно, уже и может решить проблему. Мои монтажники опять перемерзли на аварийных работах и теперь натирают тюленьим жиром отмороженные пальцы, которые еще можно спасти от ампутации. Следующий ориентировочный срок для измерений - завтра в первой половине дня.
  5. 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 Мбит/с выдает.
  6. Кого вы называете "активными клиентами"? Я употреблял аналогичное выражение "активная ОНУ" в смысле "ОНУ, имеющая что послать в сеть в данный момент". Если речь идет о таких "активных клиентах", то их количество меняется несколько раз в секунду. Так что посчитать их в буквальном смысле очень затруднительно. Можно как-то оценить их количество, активность и влияние на пропускную способность сети глядя на объем трафика. Как я уже писал, трафик в PON-ах небольшой, порядка 200Мбит/с вниз / 30МБит/с вверх в момент наибольшей загрузки на самых загруженных портах. В среднем по времени и по палате - намного меньше. От насыщения физики пока очень далеко. Если вы говорите о ком-то/чем-то другом, например, о количестве активных клиентских подключений на БРАСах / на порт, то это посчитать как-то можно, но на мой взгляд, это не имеет прямого отношения к проблеме. Просто зарегистрированных ОНУшек на портах от 20-и до 75-и, в среднем около 40-а. Счастья нет ни на одном из портов. Степень несчастья варьирует. Я все же надеюсь, что у меня нет отдельной безумной ОНУшки на каждом порту. Пока надеюсь 🙂
  7. 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-я ОНУшками все было хорошо.
  8. Ну тогда следующей ночью так и попробую.
  9. А можно уточнить: что значит удалить все? К примеру удаление файла config.db, в котором хранятся, насколько я понимаю закэшированные конфиги ОНУ-шек - это правильный способ? И не приведет ли это к неспособности ОЛТа загрузиться? Честно говоря, боязно экспериментировать на живую.
  10. Да я понимаю, что беда где-то в этой области: cir/pir/shaper/policer и т.п.. Так прямо сразу и написал. Вот только не понимаю пока, где конкретно. DBA-профайла в этом ОЛТе нет вообще (или я о нем не знаю). Это меня тоже сильно смущает. С физикой значимых проблем нет: уровни сигнала приемлемые, потерь пакетов нет, скорость не рваная, а ровно (но неправильно) нарезанная. Я хочу, чтобы скорость делилась не между подключенными терминалами (в том числе спящими, ковыряющими в носе и размышляющими о жизни). А между терминалами, реально запросившими передачу данных, в пределах выделенных cir/pir/eir-ов. Такой способ разделения полосы называется Dynamic Badwidth Allocation (DBA) и присутствует в стандарте GPON-а, во всех вменяемых реализациях EPON-а (за отсутствием там стандарта) и во всех вменяемых технологиях, использующих TDM (под разными названиями). PON без такой фичи мне точно не нужен. У меня на БДКОМе оно аналогично выглядит. Но то ли я неправильно пишу эти профайлы, то ли ОЛТ неправильно их понимает. У меня стоит 3-й тип трафика, и в нем 8Мбит гарантированных и 100М максимальных. С виду ничего криминального, должно быть хорошо. А на деле плохо. Дело именно в полосе, а не в физике. Я точно про аплоуд. Загрузка PON-портов очень небольшая в обоих направлениях. Думаю, что не в норме, судя по результатам (если вы про шейперы ОЛТа и/или ОНУ). Только я не знаю, как это поправить. Где начинаются настройки ОНУшек и заканчиваются настройки ОЛТа (т.е. кто именно нарезает скорость аплоуда) из конфига и документации тоже, кстати, не видно. В общем мораль похоже такова, что надо брать и крутить все скоростные (и возможно не только) настройки во все стороны, пока что-то не прояснится. Жду, пока монтажники построят тестовую точку подключения под крышей дома лояльного клиента. А дальше займусь исследованием этой темной материи.
  11. Полноценно испытать прошивку BD_GP3616_10.3.0C_46550 не удалось. С текущим конфигом ОНУшки подключиться не смогли, ОЛТ ругался на незнакомую команду "cmd-sequence 004 gpon onu loopback-detect protocol private". После удаления этой команды из профилей конфигурирования ОНУ слегка полегчало: ОНУшки подключились. Но клиенты подключиться уже не смогли. Трафик в клиентских ВЛАНах над ОЛТом полностью отсутствовал. От дальнейших экспериментов над живыми людьми я пока воздержался. Попробую еще поэкспериментировать с прошивкой 46550 ночью, постепенно упрощая конфиг до такого состояния, что клиенты таки смогут подключиться. Хотя жить с такой прошивкой (без loopback-detect-а) сколько-нибудь долго нельзя, только на время эксперимента. Либо придется искать другое решение.
  12. Спасибо. Пошел пробовать. По результатам отпишусь.
  13. А не поделитесь ли прошивкой? Буду признателен.
  14. Это несложно. Конфиг был слит до перехода на новую прошивку. Никаких принципиальных отличий там нет.
  15. Конфиг и версия ПО находятся в студии с самого начала. Первый в приложении, а вторая под спойлером.
×