wladd Posted February 3, 2013 Author Posted February 3, 2013 Пишу персонально тов. Гайджину. Мы и правда очень заинтересованы в вашей помощи, и действительно очень ценим ваши тесты. Практически по каждому из ваших исследований я выписываю соответствующие кейсы производителю. Если для продолжения тестов необходимо оборудование, мы можем решить эти вопросы. К сожалению вопрос вашего времени находится за пределами нашего влияния. Но честно, иногда, я просто не знаю, какие выводы необходимо сделать. Последний тест вполне интересен. Как правило причиной написания тикета является некая проблема. Я не смог правильно понять, какой вывод сделать из того теста кторый был опубликован. В сущность - это в любом случай моя вахта. Кейс выпишу. Хотелось бы чтобы вы дополнили это т тест своими выводами и мыслями более подробно. Просто "странного поведения" боюсь недостаточно для руководства к действию. Что не так - напишите более развернуто. Чем это грозит? ИМХО Тариф 100М на порту в 100M мне кажется фикцией изначально.
Гайджин Posted February 3, 2013 Posted February 3, 2013 Но честно, иногда, я просто не знаю, какие выводы необходимо сделать. Влад, да не в этом дело. - Мы все чего то не знаем, а чего то знаем, и причем все по разному. Но суммарно мы знаем гораздо больше чем каждый в отдельности. Вот я возвал к коллективному разуму - мужики, кто что думает по этому поводу? Т.е. почему подобные финты ушами (такой причудливый рост пинга) могут происходить? То что это ненормально я сам прекрасно понимаю - мне интересно докопаться до причин. Без осознания причин китайцев не отпиннаешь в копчик, и они ничего не исправят. Мне же в ответ вместо того, что бы каких нибудь интересных мыслей покинуть - да ты типа за%%%л ("...Ваш поезд сьехал в тупик неадекватности..."), все и так оху%%но, "при съемках данного фильма ни одно животное не пострадало", и вообще "в Багдаде все спокойно". Т.е. креативных мыслей аж два вагона. Я х%%ю, уважаемая редакция. Так вот господа, не все спокойно в Багдаде - вчера коллега провел подобный моему тест (нагрузил восходящий канал черз ONU->OLT и пингал хост ниже ONU) и вот результаты у него следующие - 94.7 Mbits/sec и RTT 1-3 мс, без подскоков и падений. Вот это я нахожу нормальным поведением. Но вот только беда в том, что тест проводился на PON оборудовании другого вендора. И при этом - в Багдаде все спокойно... p.s. И вообще, лично мне кажется, что обсуждение подобных тем в формате форума весьма неудобно. Нужна обычная система баг-трекинга, что типа вот такого. Что бы не было как сегодня с утра - протрахался два часа в попытках насадить на ONU ip-адрес управления. И только потом обнаружил, что наши раскосые друзья в последней прошивке заброс ARPа из влана во влан починили. Но вот только горюшко то в том, что похоже на этом баге и держались все эти приколы типа "влан управления может быть любой, но не тегированный". Создается впечатление, что туда ARP тоже забрасывало, на этом и жило, а теперь перестало - вот менеджмент и отвалился. Вернее ARP в менеджмент влане. А вот теперь внимание вопрос: еще тут я просил объяснить подробней, что наблюдали и к чему пришли; было это 4 дня назад; не уже ли так тяжело было ответить?! Ведь минимум два человека знали и четко понимали о чем речь. Получи я ответ вовремя, я бы вместо двух часов кувыкрков осознал бы в чем дело за 5 минут. Ось така х%ня малята, на добраніч, діти...
Гайджин Posted February 3, 2013 Posted February 3, 2013 Последний тест вполне интересен. Как правило причиной написания тикета является некая проблема. Я не смог правильно понять, какой вывод сделать из того теста кторый был опубликован. Предъявлять пока что то рано - причины этого явления пока не ясны. Нужно дополнительно работать над этим, а у меня как раз время кончается - мне сеть новую запускать ехать надо. Так что может быть все же толпой на этот баг навалимся?
wladd Posted February 3, 2013 Author Posted February 3, 2013 если не сложно распиши бюджет Для простых подсчетов можно применить некий постулат Деление на 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 Posted February 3, 2013 Posted February 3, 2013 Спасибо Гайджин уже рассказал. В начале я думал что оптический бюджет нужно считать для всех клиентов сразу, тоисть у тебя 32 абонента, берем два сплитера 1х16 - это уже бюджет 27,8 дБм, я был в растеряности. Спасибо Гайджину он подсказал что нужно подсчитывать бюджет от OLT к ONU для каждого клинта по отдельности.
ksander_fobos Posted February 3, 2013 Posted February 3, 2013 Вот кому интересно посчитал сколько нужно денежек на дерево 1x4 1x16 1x16 1x16 1x16
stroitel Posted February 3, 2013 Posted February 3, 2013 Вот кому интересно посчитал сколько нужно денежек на дерево 1x4 1x16 1x16 1x16 1x16 Чем схему рисовал?
rsst Posted February 3, 2013 Posted February 3, 2013 а вот от делителя 1/16 вы каким образом будете тянуться к клиенту? или у вас 16 дырок на улицу/переулок?
ksander_fobos Posted February 3, 2013 Posted February 3, 2013 а вот от делителя 1/16 вы каким образом будете тянуться к клиенту? или у вас 16 дырок на улицу/переулок? в место где находится 16 клиентов ставится бокс для 16 абонентов. Максимальная длина кабеля 120 метров до клиента
ksander_fobos Posted February 3, 2013 Posted February 3, 2013 нет есть чс где по 16 клиентов в радиусе макс 120 метров
Petrov Posted February 3, 2013 Posted February 3, 2013 Вот кому интересно посчитал сколько нужно денежек на дерево 1x4 1x16 1x16 1x16 1x16 Спасибо! Подскажите пожалуйста, общий бюджет проекта 24140 долларов на 256 абонентов - то есть 94 доллара на абонента - это с учетом стоимости кабелей или это только стоимость оборудования?
ksander_fobos Posted February 3, 2013 Posted February 3, 2013 это я для себя считал там написано без учета кабелей и расходников типа патчкорды и боксы у клиентов
ksander_fobos Posted February 3, 2013 Posted February 3, 2013 и это просчитано для дерева 1х16 1х16 1х16 1х16 для других хз
rsst Posted February 3, 2013 Posted February 3, 2013 не учтены боксы, расходники, нормальный сварочный аппарат, измеритель оптической мощности (не говоря уже про рефлектометр) .... и т.д.
wladd Posted February 3, 2013 Author Posted February 3, 2013 Выписал тикет, направил производителю. Наблюдения показывают, что при достижении ширины канала, например wirespeed порта UNI, пинги растут как бы не помещаясь в канал передачи, передаются с задержкой. Тов. Гайджин, говорит что эта же картина наблюдается при достижении rate лимита выставленного на порту. Будем ждать разъяснений, и может быть каких то документаций. BDCOM ответил что тест отличный. Надо провести тестирования с их стороны, и провести улчшения в этом вопросе. Ждемс.
wladd Posted February 4, 2013 Author Posted February 4, 2013 По ARP проблеме 1004B.(заброс ARP запросов из соседнего VLAN)напомню как обстояли дела дальшеБыл выпущен временный патч, который решал проблему ARP,но приводил к неработоспособности менеджмент VLAN и обновлятьего нужно было через UNI порт.Мы провели переговоры по этим вопросамИнженеры утверждают, что особенности чипсета ОНУ таковы, чтомы можем иметь либо- правильную работу ARP- либо менеджмент VLAN на ОНУ.Может существовать два альтернативных мнения "Менеджмент" или "ARP"Тов. UFM - за ARP. C единственной оговоркой, что прошивки должны без проблем обновляться через ОЛТ.Нужно понимать, что принятие этого решения, поведет эволюцию прошивки под 1004B либо в сторону"неуправляемого кирпича" но правильно работающего, либо в сторону "управляемого устройства но с проблемой возможных ARP штормовПредлагаю голосование.Так или иначе. У нас есть работающая прошивка "B" и через 2 дня у нас будет прошивка для обновления с ОЛТОдна прошивка будет отвечать позиции_1 вторая отвечать требованиям позиции_2.Давайте голосовать!
_WesT_ Posted February 4, 2013 Posted February 4, 2013 Тов. UFM - за ARP. C единственной оговоркой, что прошивки должны без проблем обновляться через ОЛТ. Я за вот такой вариант
ufm Posted February 4, 2013 Posted February 4, 2013 Инженеры утверждают, что особенности чипсета ОНУ таковы, что мы можем иметь либо - правильную работу ARP - либо менеджмент VLAN на ОНУ. На самом деле не столь категорично, но доступ к ОНУ будет "при определенных условиях". У меня подход очень простой - "дайте мне кирпич управляемый только с головы или дайте мне тупую голову а управление всё с самой ONU".
sadmin Posted February 4, 2013 Posted February 4, 2013 я за поддержку 2х веток ПО: мне нужно управление, но многим АРП. так что, Влад, просим!
wladd Posted February 4, 2013 Author Posted February 4, 2013 я за поддержку 2х веток ПО: мне нужно управление, но многим АРП. так что, Влад, просим! Две ветки ПО. Как это? Честно немного странно. Мы как минимум будем иметь две веточки. Прошивку с одним и другим. Попробуем. Постараемся. Хотелось бы увидеть статистику Пока счет 1:1 Кто еще выскажется?.
Гайджин Posted February 4, 2013 Posted February 4, 2013 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. На этом я заканчиваю свои эксперименты на ближайшее время.
Recommended Posts