UA.PON v3.0

[wladd 382]

Пишу персонально тов. Гайджину.

Мы и правда очень заинтересованы в вашей помощи, и действительно очень ценим ваши тесты.

Практически по каждому из ваших исследований я выписываю соответствующие кейсы производителю.

Если для продолжения тестов необходимо оборудование, мы можем решить эти вопросы.

К сожалению вопрос вашего времени находится за пределами нашего влияния.

 

Но честно, иногда, я просто не знаю, какие выводы необходимо сделать.

Последний тест вполне интересен. Как правило причиной написания тикета является некая проблема.

Я не смог правильно понять, какой вывод сделать из того теста кторый был опубликован.

В сущность - это в любом случай моя вахта. Кейс выпишу. Хотелось бы

чтобы вы дополнили это т тест своими выводами и мыслями более подробно.

Просто "странного поведения" боюсь недостаточно для руководства к действию.

Что не так - напишите более развернуто. Чем это грозит?  ИМХО Тариф 100М на порту в 100M мне кажется фикцией изначально.

[Гайджин 574]

Но честно, иногда, я просто не знаю, какие выводы необходимо сделать.

Влад, да не в этом дело. - Мы все чего то не знаем, а чего то знаем, и причем все по разному. Но суммарно мы знаем гораздо больше чем каждый в отдельности.

 

Вот я возвал к коллективному разуму - мужики, кто что думает по этому поводу? Т.е. почему подобные финты ушами (такой причудливый рост пинга) могут происходить? То что это ненормально я сам прекрасно понимаю - мне интересно докопаться до причин. Без осознания причин китайцев не отпиннаешь в копчик, и они ничего не исправят.

 

Мне же в ответ вместо того, что бы каких нибудь интересных мыслей покинуть - да ты типа за%%%л ("...Ваш поезд сьехал в тупик неадекватности..."), все и так оху%%но, "при съемках данного фильма ни одно животное не пострадало", и вообще "в Багдаде все спокойно". Т.е. креативных мыслей аж два вагона. Я х%%ю, уважаемая редакция.

 

Так вот господа, не все спокойно в Багдаде - вчера коллега провел подобный моему тест (нагрузил восходящий канал черз ONU->OLT и пингал хост ниже ONU) и вот результаты у него следующие - 94.7 Mbits/sec и RTT 1-3 мс, без подскоков и падений. Вот это я нахожу нормальным поведением. Но вот только беда в том, что тест проводился на PON оборудовании другого вендора.

 

И при этом - в Багдаде все спокойно...

 

p.s. И вообще, лично мне кажется, что обсуждение подобных тем в формате форума весьма неудобно. Нужна обычная система баг-трекинга, что типа вот такого. Что бы не было как сегодня с утра - протрахался два часа в попытках насадить на ONU ip-адрес управления. И только потом обнаружил, что наши раскосые друзья в последней прошивке заброс ARPа из влана во влан починили. Но вот только горюшко то в том, что похоже на этом баге и держались все эти приколы типа "влан управления может быть любой, но не тегированный". Создается впечатление, что туда ARP тоже забрасывало, на этом и жило, а теперь перестало - вот менеджмент и отвалился. Вернее ARP в менеджмент влане.

А вот теперь внимание вопрос: еще тут я просил объяснить подробней, что наблюдали и к чему пришли; было это 4 дня назад; не уже ли так тяжело было ответить?! Ведь минимум два человека знали и четко понимали о чем речь.

Получи я ответ вовремя, я бы вместо двух часов кувыкрков осознал бы в чем дело за 5 минут.

 

Ось така х%ня малята, на добраніч, діти...

[Гайджин 574]

Последний тест вполне интересен. Как правило причиной написания тикета является некая проблема.

Я не смог правильно понять, какой вывод сделать из того теста кторый был опубликован.

Предъявлять пока что то рано - причины этого явления пока не ясны.

Нужно дополнительно работать над этим, а у меня как раз время кончается - мне сеть новую запускать ехать надо. Так что может быть все же толпой на этот баг навалимся?

[wladd 382]

если не сложно распиши бюджет

Для простых подсчетов можно применить некий постулат

Деление на 2 =2dB

деление на 4 =6

делние на 8 = 9

деление на 16 = 12

и.т.д.

 

В вашем случае 1х2х16 = 12+3=18 плюс

волокна всего 700+120= меньше одного километра.

При затухании 0,36 db/km

это мелочи+ конекнтокры - разъемные соединения.

На все - волокно+ плюс все все все все  берем =2dB

ИТОГО = 18+2=20db  потерь.

Учитывая что Бюджет ПОН 28-32 db

У вас в запасе от 8 до 10 db

[ksander_fobos 1]

Спасибо Гайджин уже рассказал.

В начале я думал что оптический бюджет нужно считать для всех клиентов сразу, тоисть у тебя 32 абонента, берем два сплитера 1х16 - это уже бюджет 27,8 дБм, я был в растеряности. Спасибо Гайджину он подсказал что нужно подсчитывать бюджет от OLT к ONU для каждого клинта по отдельности.  

[ksander_fobos 1]

Вот кому интересно посчитал сколько нужно денежек на дерево 1x4 1x16 1x16 1x16 1x16

[stroitel 4]

Вот кому интересно посчитал сколько нужно денежек на дерево 1x4 1x16 1x16 1x16 1x16

Чем схему рисовал?

[ksander_fobos 1]

корел

[rsst 406]

у вас там частный сектор или многоэтажки?

[ksander_fobos 1]

частный 

[rsst 406]

а вот от делителя 1/16 вы каким образом будете тянуться к клиенту? или у вас 16 дырок на улицу/переулок?

[ksander_fobos 1]

а вот от делителя 1/16 вы каким образом будете тянуться к клиенту? или у вас 16 дырок на улицу/переулок?

в место где находится 16 клиентов ставится бокс для 16 абонентов. Максимальная длина кабеля 120 метров до клиента

[rsst 406]

в общем это нечто гипотетическое, как я понимаю

[ksander_fobos 1]

нет есть чс где по 16 клиентов в радиусе макс 120 метров

[Petrov 7]

Вот кому интересно посчитал сколько нужно денежек на дерево 1x4 1x16 1x16 1x16 1x16

Спасибо!

Подскажите пожалуйста, общий бюджет проекта 24140 долларов на 256 абонентов - то есть 94 доллара на абонента - это с учетом стоимости кабелей или это только стоимость оборудования?

[ksander_fobos 1]

это я для себя считал там написано без учета кабелей и расходников типа патчкорды и боксы у клиентов

[ksander_fobos 1]

и это просчитано для дерева 1х16 1х16 1х16 1х16  для других хз

[rsst 406]

не учтены боксы, расходники, нормальный сварочный аппарат, измеритель оптической мощности (не говоря уже про рефлектометр) .... и т.д.

[wladd 382]

Выписал тикет, направил производителю.

Наблюдения показывают, что при достижении ширины канала, например

wirespeed порта UNI, пинги растут как бы не помещаясь в канал передачи,

передаются с задержкой.

Тов. Гайджин, говорит что эта же картина наблюдается при достижении rate лимита

выставленного на порту. Будем ждать разъяснений, и может быть каких то документаций.

 

BDCOM ответил что тест отличный. Надо провести тестирования с их стороны, и

провести улчшения в этом вопросе. Ждемс.

[wladd 382]

По ARP проблеме 1004B.
(заброс ARP запросов из соседнего VLAN)

напомню как обстояли дела дальше
Был выпущен временный патч, который решал проблему ARP,
но приводил к неработоспособности менеджмент VLAN и обновлять
его нужно было через UNI порт.

Мы провели переговоры по этим вопросам
Инженеры утверждают, что особенности чипсета ОНУ таковы, что
мы можем иметь либо

- правильную работу ARP
- либо менеджмент VLAN на ОНУ.

Может существовать два альтернативных мнения "Менеджмент" или "ARP"
Тов. UFM - за ARP. C единственной оговоркой, что прошивки должны без проблем обновляться через ОЛТ.

Нужно понимать, что принятие этого решения, поведет эволюцию прошивки под 1004B либо в сторону
"неуправляемого кирпича" но правильно работающего, либо в сторону  "управляемого устройства но с проблемой возможных ARP штормов
Предлагаю голосование.

Так или иначе. У нас есть работающая прошивка "B" и через 2 дня у нас будет прошивка для обновления с ОЛТ
Одна прошивка будет отвечать позиции_1 вторая отвечать требованиям позиции_2.
Давайте голосовать!

[_WesT_ 1 016]

Тов. UFM - за ARP. C единственной оговоркой, что прошивки должны без проблем обновляться через ОЛТ.

 

Я за вот такой вариант

[ufm 17]

 

Инженеры утверждают, что особенности чипсета ОНУ таковы, что

мы можем иметь либо

 

- правильную работу ARP

- либо менеджмент VLAN на ОНУ.

 

 

На самом деле не столь категорично, но доступ к ОНУ будет "при определенных условиях".

 

У меня подход очень простой - "дайте мне кирпич управляемый только с головы или дайте мне тупую голову а управление всё с самой ONU".

[sadmin 7]

я за поддержку 2х веток ПО: мне нужно управление, но многим АРП. так что, Влад, просим!

[wladd 382]

я за поддержку 2х веток ПО: мне нужно управление, но многим АРП. так что, Влад, просим!

Две ветки ПО. Как это? Честно немного странно. Мы как минимум будем иметь две веточки. Прошивку с одним и другим.

Попробуем. Постараемся. Хотелось бы увидеть статистику

Пока счет 1:1 Кто еще выскажется?.

[Гайджин 574]

 

BDCOM ответил что тест отличный. Надо провести тестирования с их стороны, и провести улчшения в этом вопросе. Ждемс.

Я сегодня еще ковырялся в этой теме. Попытаюсь обобщить.

 

Наблюдаю следующее:

Если попытаться двунаправленно раскачать канал сквозь ONU+OLT, до скоростей близких к скорости насыщения порта ONU, то RTT вырастает до 200 мс и более.

Как одно из предположений, было выдвинуто то, что механизмы TDMA перестают корректно работать при переполнении буфера порта ONU.

Было принято решение попробовать ограничить скорость на портах средствами самой ONU чуть ниже физической скорости порта.

При ограничении скорости rate-limit-ом и попытатке двунаправленно раскачать канал сквозь ONU+OLT, до скоростей близких к скорости rate-limit-, то RTT вырастает до 200 мс и более. Причем это наблюдается даже если зажать rate-limit-ом скорость на 10 МБит/с.

Та же самая картина наблюдается если попытаться применить sla.

Делаю вывод, что похоже rate-limit тесно взаимосвязан с механизмами TDMA, и вылечить одно за счет другого не получится.

Тогда предпринимаю попытку ограничить скорость внешними средствами. Создаю не сервере B (схема с прошлого раза не менялась) низходящий двухполосый щейпер. Первая полоса имеет приоритет в 8 раз выше чем вторая и в нее помещается технологический TCP трафик (ACK) - т.е. я "кондициорирую" трафик (обеспечиваю ему улучшенные условия для двунаправленного обмена). Для восходящего трафика создаю полисер. Параметры дискриминации трафика подбираю во время экспериментов. На приведенном ниже скриншоте в левом маленьком окне пинг с сервера B на серевер A, в правом маленьком окне пинг с сервера B на серевер Mag250, в нижнем окне двусторонний промер с сервера A на B, на заднем плане консоль сервера B.

На выхлопе я добиваюсь того, что при зажимании скорости в обеих направлениях на 80 МБит/с я получаю нормальный RTT.

Именно таким он должен быть без всяких манипуляций с моей стороны, не будь у ONU своего видения на жизнь.

 

Вопрос для китайцев: Хочу, что бы было вот так, как выделено жирным шрифтом.

 

p.s. На этом я заканчиваю свои эксперименты на ближайшее время.