[[anp/hsw]]

9 минут назад, slv700 сказал:

Тест со случайным размером пакетов ?  Раскажите нам что из себя предствляет такой тест. 

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

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

Можете какой-нибудь bngblaster так настроить и забыть уже о реальных тестах на абонентах - чай не подопытные крысы, уважать их тоже надо.

[slv700]

38 минут назад, [anp/hsw] сказал:

сотню параметров пакетов разных игрушек, качалок, и прочего,

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

Возьмите любой радиоканал в поселок с 300+ клиентами. Они  будет генерировать 400-500 Mbps  трафика с пакетами разной длины.  Поставьте на этот радиоканал свой Rocket 5AC    Lite , снимите трафик с порта свича и все увидите.   

Для получения полки  в 550М на AF5X HD  нужен трафик от 350-400+ клиентов.  Полка будет видна на самом графике в прайм-тайм  вечером и по резкому увеличению задержки в канале.

    Вообще иметь канал на оптике и резервный на  радио - обычная практика.  Сколько пропустит радио проверяется легко, на него переключается весь или часть трафика поселка и  наблюдается  в  течении нескольких суток или недель. Загрузка канала снимается с порта свича что на оптическом канале, что на радиоканале.

При этом ставить резервный радиоканал на каком  нибудь UBNT Airmax , полагая, чтот это г. пропустит 450М как указано в спецификации ( типа Смотрю на PowerBeam 5ac ISO Gen2, на сайте ubnt написано, что скорость будет 450+мбит/сек  ) , или веря голословным  словам - вранью   разных продаванов  , - очевидная глупость .  Только практика реальной экслуатации -критерий истины. 

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

[xabarov]

В 02.07.2021 в 09:26, slv700 сказал:

200М - это потолок на реальном трафике от сотни+ юзеров для решений  Airmaх.

Для решений AirMax потолок около 150М, а AirMax AC более 400 Мбит/с.

В 02.07.2021 в 09:26, slv700 сказал:

В тесте на синтетическрм трафике пакетами фиксированной длины AF5X дает макс 1 Гиг в 100Мгц.   На столе на 1024QAM в 100 Мгц это сделает любой девайс. 

Любой девайс может и делает на столе, а вот файбер это делает на линке 3 км:

 

В 02.07.2021 в 09:26, slv700 сказал:

А вот на улице на реальном трафике от несколько сотен юзеров- совсем другая картина. Покажите загрузку  600+  Mbps реальным трафиком на  AF5x HD.   

Сейчас лето и трафика пока больше 400-450 нет, но к осени потребление вырастает и обязательно обрадуем вас цифрой 600+

 

В 02.07.2021 в 10:02, slv700 сказал:

До Force425  на линке стоял AF5x, реальный трафик упирался в полку 540Мbps.

Достоверно НЕизвестно, почему он упирался. По роду работы довольно часто сталкиваюсь с тем, что операторы используют оборудование с неправильными или неоптимальными настройками, причем у многих из них отсутствуют грамотные специалисты по беспроводке. В большинстве случаев достаточно указать на ошибки в настройках и проблема решается без замены оборудования. Но вы преследуете другую задачу - заменить у клиента оборудование любого вендора на Камбиум, независимо от того, были у него какие-либо ошибки в инсталляции или нет. Этот подход вы неоднократно демонстрировали на этом форуме. 

В 05.07.2021 в 08:12, slv700 сказал:

НЕТ НИ ОДНОГО практического случая, где было бы видно что AF5X HD пробивает полку 550Mbps Download на реальном коммерческом трафике от сотен юзров.

Вы проверили все инсталляции AF-5XHD в мире, чтобы так утверждать? Если нет, то вы лжец. Здесь на форуме от силы 1% пользователей этого оборудования и остальным 99% нет никакого дела до ваших рекордов.

В 05.07.2021 в 08:12, slv700 сказал:

НЕТ НИ ОДНОГО практического случая где было бы видно что Airmax UBNT 5AC пробивает полку 230 Mbps Download  на реальном коммерческом трафике от 100-150 юзеров .

Тут вы точно врете, поскольку как минимум от меня был пример работы AirMax AC с трафиком 300+ от нескольких сотен юзеров, но как обычно вас этот пример не устроил - нужны особенные измерительные инструменты с особыми настройками измерений. Но даже если удовлетворить всем требованиям - все равно появятся новые, более изощренные.

В 05.07.2021 в 08:12, slv700 сказал:

ЕСТЬ практическая экплуатация Force 425/400C где линк в 80Мгц прокачивает реальный коммерческий трафик 735  Mbps DL + 115 Mbps UL  ( 830  Mbps UL+DL) для 500+ юзеров поселка.

Почему нет примеров от самих провайдеров? Где все эти счастливые обладатели форсов? Если не брать в расчет ваш кейс, то других примеров то и нет. За исключением одного. Ваши венгерские друзья дали протестировать 425-ый местному провайдеру на линке 2 км в реальных (зашумленных) условиях и вот что они получили в полосе 80 МГц: 

 

Ну и в конце ролика они рассказали, что получили цифры около 900 Мбит/с только на расстоянии 400 метров в чистом эфире без помех. Как у вас прокачивает 830 Мбит/с "реальный коммерческий трафик" на более протяженном линке - большой вопрос.

 

В 04.07.2021 в 08:15, slv700 сказал:

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

Получается, что проблем у RB4011 не было, а наезды на хабарова с обвинениями в подтасовке и безграмотности были безосновательны? 

[slv700]

34 минуты назад, xabarov сказал:

Почему нет примеров от самих провайдеров? Где все эти счастливые обладатели форсов? Если не брать в расчет ваш кейс, то других примеров то и нет

Все мои примеры - это реальные линки реальных провайдеров - наших заказчиков

 

34 минуты назад, xabarov сказал:

Получается, что проблем у RB4011 не было,

Проблема RB4011  что там  на 4-х ядерном процессоре ARM в bandwidth test запускают 4 копии этого bandwidth test c 4-мя стеками TCP. И потери на одном стеке компенсируются 3-мя другими. Поэтому  BT на RB4011 - не есть адекватный измерительный инструмент.

К сожалению, даже Iperf сейчас также неадекватен. Синтетический трафик с пакетами  постоянной длины и реальный трафик с пакетами разной длины, требующий фрагментации и агрегации в радио - суть разные вещи.

Адекватный показатель максимальной пропускной способности -  только живой реальный трафик на линке с достаточной для работы  на 1024QAM 5/6 энергетикой ( CINR).

[slv700]

24 минуты назад, xabarov сказал:

получили цифры около 900 Мбит/с только на расстоянии 400 метров в чистом эфире без помех

Вы несете ахинею. Скорость в TDD  не зависит от дальности, а зависит от рабочей модуляции, которая в свою очередь зависит от энергетики линка,  а точнее от CINR-  отношения уровня сигнала к помехе. Если в городе в зашумленном эфире в 80 Мгц получили  не 900М, а 500М, то значит рабочая модуляция была не 1024 QAM, а например 64QAM или меньше из низкого CINR из за помех.

Кроме того сам по себе Микротик TCP ( кроме RB4011 ) не способен в Bandwidth тест генерировать больше 350М TCP трафика.

 

24 минуты назад, xabarov сказал:

пример работы AirMax AC с трафиком 300+ от нескольких сотен юзеров, но как обычно вас этот пример не устроил - нужны особенные измерительные инструменты с особыми настройками измерений

Не надо ничего особенного. Сойдет обычный Кактус с усреднением реального живого трафика  за несколько секунд в течении дня или хотя бы десятка минут.. Мгновенные пики трафика- не зачет. Что здесь непонятного?

 

25 минут назад, xabarov сказал:

Вы проверили все инсталляции AF-5XHD в мире, чтобы так утверждать?

Зачем проверять  все инсталяции в мире? Покажите всего лишь одну  инсталляцию, где видна цифра 600М живого реального трафика, снятого с порта свича. Сколько можно это повторять?

[fractal]

9 часов назад, slv700 сказал:

К сожалению, даже Iperf сейчас также неадекватен

Ну купите флюк, сертифицированный инструмент с генератором трафика, поверьте он модулирует imix так, что даже серьёзное железо скопытится

[[anp/hsw]]

11 часов назад, slv700 сказал:

Проблема RB4011  что там  на 4-х ядерном процессоре ARM в bandwidth test запускают 4 копии этого bandwidth test c 4-мя стеками TCP. И потери на одном стеке компенсируются 3-мя другими.

А 500 абонентов как-будто используют один стек на всех?

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

11 часов назад, slv700 сказал:

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

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

[slv700]

2 часа назад, [anp/hsw] сказал:

А 500 абонентов как-будто используют один стек на всех?

Один стек TCP на 4 ядра ARM с NSS.

 

2 часа назад, [anp/hsw] сказал:

днопоточный, то многопоточный тесты

Поток TCP и стек протокола TCP c TCP windows size( количество пакетов в пачке) с контролем доставки   AСK всей пачки, работающий на один или несколько потоков TCP -  разные вещи.

 

2 часа назад, [anp/hsw] сказал:

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

Пожалуйста, можете использовать rrd, но нужны не три точки как у вас на графике, а сотни и с усреднением мгновенных значений скорости трафика  за 1-2 секунды, а не пиковые значения  скорости за интервал десять+  минут. Моя позиция неизменна, я эти требования к измерительному инструменту повторяю десятки раз.

[slv700]

4 часа назад, fractal сказал:

флюк, сертифицированный инструмент с генератором трафика,

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

[fractal]

51 минуту назад, slv700 сказал:

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

да давно есть - https://www.icsgroup.ru/flukenetworks/products/detail.php?SID=7732 / https://skomplekt.com/tovar/1/5/59/ выбирайте, сам точно знаю что этими двумя приборами принимают опорную сеть Газпром, а они себе много пролетов делают начиная от обычных ptp/rrl, заканчивая оптикой и медью, и я еще год назад их приводил Вам, сейчас у меня такой же в организации, мы каналы принимаем только им

[slv700]

49 минут назад, fractal сказал:

да давно есть - https://www.icsgroup.ru/flukenetworks/products/detail.php?SID=7732 / https://skomplekt.com/tovar/1/5/59/ выбирайте, сам точно знаю что этими двумя приборами принимают опорную сеть Газпром, а они себе много пролетов делают начиная от обычных ptp/rrl, заканчивая оптикой и медью, и я еще год назад их приводил Вам, сейчас у меня такой же в организации, мы каналы принимаем только им

Там есть возможность генерировать случайный набор пакетов разной длины?

Именно эта фича в современных генераторах тестов является ключевой.

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

Дело в том , что типового процессора без аппаратного ускорения NSS на недорогой платформе Atheros-Qualcomm  хватает только на пропуск не более 230М реального трафика ( пакетов разной длины от сотен юзеров).

 Применение NSS на 4-х ядерной платформе ARM решает эту проблему.

Проверяется очень просто. Например на устройстве Cambium   отключается ( это инженерная фича, недоступная юзеру) поддержка  NSS и реальный трафик упирается в полку 200-230М. Включаем фичу- полки нет.

Или пускается трафик, который не поддерживает NSS родным драйвером  Atheros. Ранее   это был QinQ. Этот трафик упирался в те же самые 230М. Убирали QinQ - полка уходила. Скорее всего поддержку NSS  трафика QinQ и других специфических протоколов ( обычно туннели) Qualcomm уже пофиксил в своем вайфай драйвере.  С ним по этим вопросам занимался Cambium, потому что без фикса имелись проблемы с полкой некоторых типов трафика.

     Что касается AF5X HD, то у него более мощная и дорогая платформа нежели у Qualcomm.  NSS или типа того там нет.

Так вот по наблюдениям работы  AF5X HD  на реальных линках у него процессор может пропускать до 550М  реального трафика ( пакетов разной длины от сотен юзеров). При этом полки на синтетическом трафике у него ( как и у всех других устройствах Atheros ) нет.  Поэтому синтетические тесты даже не сертифицированных измерительных устройствах не дают адекватной картины реальной пропускной способности радиоканала.  

    Причем  теоеретически  генератор тестов  можно заставить  генерировать пакеты разной длины , в этом случае возможно  и можно получить адекватный результат оценки реальной пропускной способности. А может есть еще какие то грабли, нужно изучать вопрос.

       А пока только реальный трафик от сотен юзеров с измерением нескольких сотен усреденных за 1-2 сек значений скорости трафика за десятки минут или часов есть адекватный инструмент оценки  пропукной способности радиоканала.

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

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

ЗЫ

Мыслить - это ( в том числе) способность  видеть тонкие различия. Цитата одного из известных философов.

 

[fractal]

19 минут назад, slv700 сказал:

Там есть возможность генерировать случайный набор пакетов разной длины?

Именно эта фича в современных генераторах тестов является ключевой.

естественно, я же и указывал про генерацию IMIX трафика в том числе, имитация работы приложения, если докупить еще ПО то вплоть до 7го уровня

[weedman]

Хватит офтпить

[xabarov]

В 08.07.2021 в 17:52, slv700 сказал:

Все мои примеры - это реальные линки реальных провайдеров - наших заказчиков

Откуда нам это знать? Сами они молчат и о них ничего неизвестно. На форумах никто из известных людей не высказывается. Альтернативные обзоры не показывают таких цифр.

В 08.07.2021 в 18:06, slv700 сказал:

Вы несете ахинею. Скорость в TDD  не зависит от дальности, а зависит от рабочей модуляции, которая в свою очередь зависит от энергетики линка,  а точнее от CINR-  отношения уровня сигнала к помехе.

Вы это кому рассказываете? Когда я вам говорил тоже самое несколько лет назад относительно AF-5XHD, то вы мне в ответ говорили дословно - "такую модуляцию (10Х) поднять можно разве что на коротком расстоянии до 2 км", а когда я показал пример на 7 км, то сразу пошли оправдания - "эфир не такой и условия специально подобранные" :)

В 08.07.2021 в 18:06, slv700 сказал:

Не надо ничего особенного. Сойдет обычный Кактус с усреднением реального живого трафика  за несколько секунд в течении дня или хотя бы десятка минут.. Мгновенные пики трафика- не зачет. Что здесь непонятного?

Повторю вопрос [anp/hsw]: "А нам что с этого будет?". Потрачу свое время и людей напрягу. Соберем мост на AirMax AC, запустим живой трафик, настроим Кактус, покажем цифры значительно больше, чем вы утверждаете. Что потом? Вы готовы опубликовать публичное опровержение и извинения во всех постах, где наврали про 200М? Если да, то я готов провернуть этот эксперимент. 

В 08.07.2021 в 18:06, slv700 сказал:

Зачем проверять  все инсталяции в мире? Покажите всего лишь одну  инсталляцию, где видна цифра 600М живого реального трафика, снятого с порта свича. Сколько можно это повторять?

Затем, что вы опять врете, говоря "НЕТ НИ ОДНОГО практического случая". Вы все случаи проверили, чтобы так говорить? Если нет, то не надо так говорить, или уточняйте, что "на этом форуме не было".

В 09.07.2021 в 09:27, slv700 сказал:

А пока только реальный трафик от сотен юзеров с измерением нескольких сотен усреденных за 1-2 сек значений скорости трафика за десятки минут или часов есть адекватный инструмент оценки  пропукной способности радиоканала.

Это конечно здорово, но на практике неприменимо. 

В 09.07.2021 в 09:27, slv700 сказал:

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

Я напомню, как у вас "ничего не меняется" :) Сначала вы всех заставляли делать Бэндвичтест и iperf, как самые правильные инструменты. В какой-то момент у меня возникли сомнения в правильности измерений iperf (когда вы ТСР получили больше UDP), на что вы мне ответили:

В 29.03.2019 в 22:35, slv700 сказал:

Если вы лично не верите в тесты iperа TCP,   что реально говорит о вашей безграмотности

В 29.03.2019 в 23:05, slv700 сказал:

Вообще заявление что тест TCP Iperf - типа  "нечестный", это вынос мозга, дремучая некомпетентность.    Я очень удивлен.

Ок, я освоил iperf, с моей стороны последовала серия тестов с помощью этого инструмента. Вы поверили результатам? Нет. Но начали активно продвигать оклу спидтест: 

В 16.05.2020 в 10:01, slv700 сказал:

Адекватный результат в данном случае может быть получен только в TCP тесте  OOKLA speedtest.com. Все остальное - чушь и галиматья.

Советовать Оклу спидтест было выгодно вам, т.к. сервер находится в интернете и толстые каналы мало у кого есть, поэтому долгое время никто не мог показать скорость больше 100-200 Мбит/с.

Но тут произошло непредвиденное - у одного из пользователей был канал 500 Мбит/с и он показал таки 400М на дешевом лайтбиме.

 

Что вы ответили автору топика на его результаты? Ничего, вы просто пропали из темы и потом перестали кому-либо советовать спидтест.

 

Ну и тренд последнего года - реальный трафик :) Вы теперь так запели только потому, что ваши ненавистные конкуренты вдруг стали показывать красивые цифры при измерении любыми традиционными инструментами. Другого выхода у вас нет, как объявить все эти инструменты неправильными. Зато у вас появился новый "правильный" инструмент под названием "реальный трафик", которым вы можете манипулировать как угодно и кричать конкурентам "а покажите ка реальный трафик 600М, тогда я вам может быть поверю".

 

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

[fractal]

1 час назад, xabarov сказал:

в данном случае вы требуете Кактус

Кактус вообще древнее зло, этого мамонта лучше не юзать, заббикс, графана более удобные и гибкие) 

[slv700]

В 15.07.2021 в 14:45, xabarov сказал:

Ну и тренд последнего года - реальный трафик :)

        Время не стоит на месте, повышаются и меняются  требования к сервисам  и оборудование меняется.     

Факт есть то, что  максимальная скорость в тестах -UDP, TCP известными инструментами  BT Mikrotik, Iperf, OOKlA Speed test,  другими  устройствами и софтовыми утилитами, специально  не профилированными для тестов радиоканалов отличается в РАЗЫ от реальной пропускной способности современного оборудования PointToPoint точка-точка. 

Это было замечено на многоядерной платформe ARM c NSS аппаратным ускорителем ( начиная с 802.11ac wave 2) .

Поэтому   испытания оборудования , имеющего потенциал по скорости более 200Mbps ( что обеспечивается NSS) , необходимо проводить именно на реальном трафике.

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

   Однако в практике экслуатации реальные возможности оборудования все рано или поздно  становится явным и прозревают даже самые неподготовленные в радио провайдеры . Потому  что если линк не пропускает больше 200М реального трафика - то это невозможно не видеть . Если клиент не получает свой тариф 20-100Mbps в малтипойнт и жалуется своему провайдеру , то в большинстве случаев это не неправильное настроенное оборудование, которое нужно подкрутить,  а просто оборудование - технологический мусор 10 летней давности и на нем нельзя предлагать современный  сервис.

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

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

 

[fractal]

3 часа назад, slv700 сказал:

OOKlA Speed test

То есть допустим я клиент, попросил канал точку точку, мне его дали, я открываю спидтест и канал не отвечает требованиям, дальше что? Начнёте говорить что все не так, все неправильно я как клиент делаю?) 

 

3 часа назад, slv700 сказал:

Только практика реальной эскплуатации оборудования на реальном коммерческом трафике

Есть утверждённые rfc, любой производитель должен соответствовать им, то что Вы сейчас говорите это очень ущемляет сам камбиум, выходит так, что камбиум и любое радио надо как то особенно тестировать) мда, интересно слышали ли они Вас) 

 

3 часа назад, slv700 сказал:

Поэтому   испытания оборудования , имеющего потенциал по скорости более 200Mbps ( что обеспечивается NSS) , необходимо проводить именно на реальном трафике.

Есть во Владивостоке канал, 300 мбит, точка точка, юбик, любой тест синтетических показывает полную скорость, обновления Windows в офисе ночью также грузят канал, о чем Вы, если бы мы ждали реальный трафик на этом канале то это заняло бы довольно продолжительный срок, мда, а если при тестах заявленной скорости нет, то провайдер идёт и решает вопрос, не может решить, то смена провайдера спасает, все, никаких особых тестов, скорость должна соответствовать тестам любым способам, iperf, okla, fluke

[alibek]

1 час назад, fractal сказал:

То есть допустим я клиент, попросил канал точку точку, мне его дали, я открываю спидтест и канал не отвечает требованиям, дальше что? Начнёте говорить что все не так, все неправильно я как клиент делаю?) 

Однажды где-то подслушал хорошую фразу.

Дословно не помню, но что-то вроде такого.

 

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

А инженер-продавец это тот, кто сможет потом объяснить, почему реальное поведение отличается от предсказанного.

[fractal]

4 часа назад, alibek сказал:

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

Оборудование в нормальном режиме работает понятно, естественно радио много от чего зависит, это понятно, канал приняли, периодически его тестим (как и все другие) когда бывают проблемы заводим заявку, исправляют, суть в том, что никто не пытается сказать что мы как то не так тестим, просто люди делают свою работу

[slv700]

В 18.07.2021 в 11:59, fractal сказал:

а если при тестах заявленной скорости нет, то провайдер идёт и решает вопрос, не может решить, то смена провайдера спасает, все, никаких особых тестов, скорость должна соответствовать тестам любым способам, iperf, okla, fluke

Все с точностью до наоборот.

1)Если в  тестах UDP ( встроенным в оборудование линк тестером)   заявленной скорости нет, то значит канал НЕ соответствует  заявленным требованиям по пропускной способности.

2) Если же в тестах UDP есть заявленная скорость, а в тестах TCP -нет, то  значит канал НЕ  соответствует  заявленным требованиям по пропускной способности.

3) Если же в тестах UDP и TCP есть заявленная скорость, измеренная адекватным тестером, то это НЕ значит, что канал   соответствует  заявленным требованиям по пропускной способности для любого профиля (типа )  трафика. Значит надо тестить каналал для всех профилей трафика, на котором будет работать канал. Проще это сделать не перебирая тесты с разными профилями ( которых может быть десятки) синтетического трафика, а просто пустить живой реальный трафик, на котором будет работать канал. Он и покажет, что  канал   соответствует или нет   заявленным требованиям по пропускной способности.

И таки да, требование 3 появилось совсем недавно, с появляением  платформы  на Atheros ARM c NSS, драйверы которой по разному обрабатывают разные профили (типы) трафика 

ЗЫ

Требования RFC неприменимы к тестам радиоканалов связи. 

[fractal]

6 часов назад, slv700 сказал:

Все с точностью до наоборот.

1)Если в  тестах UDP ( встроенным в оборудование линк тестером)   заявленной скорости нет, то значит канал НЕ соответствует  заявленным требованиям по пропускной способности.

2) Если же в тестах UDP есть заявленная скорость, а в тестах TCP -нет, то  значит канал НЕ  соответствует  заявленным требованиям по пропускной способности.

3) Если же в тестах UDP и TCP есть заявленная скорость, измеренная адекватным тестером, то это НЕ значит, что канал   соответствует  заявленным требованиям по пропускной способности для любого профиля (типа )  трафика. Значит надо тестить каналал для всех профилей трафика, на котором будет работать канал. Проще это сделать не перебирая тесты с разными профилями ( которых может быть десятки) синтетического трафика, а просто пустить живой реальный трафик, на котором будет работать канал. Он и покажет, что  канал   соответствует или нет   заявленным требованиям по пропускной способности.

И таки да, требование 3 появилось совсем недавно, с появляением  платформы  на Atheros ARM c NSS, драйверы которой по разному обрабатывают разные профили (типы) трафика 

ЗЫ

Требования RFC неприменимы к тестам радиоканалов связи. 

Вы изобретаете новое, у нас синтетика всегда совпадает с реальным, и почему то камбиум заявлял что его оборудование полностью rfc) видимо они что то не знают)

 

1 минуту назад, fractal сказал:

а просто пустить живой реальный трафик

Реально считаете что это хорошо продакшн трафик пускать по не тестированному каналу? Это крайне, крайне не серьёзный подход, любая уважающая себя организация так не станет делать 

[slv700]

1 час назад, fractal сказал:

Вы изобретаете новое, у нас синтетика всегда совпадает с реальным, и почему то камбиум заявлял что его оборудование полностью rfc) видимо они что то не знают)

Кто завлял  про "полностью RFC"?  Это вы о чем  :)

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

 

1 час назад, fractal сказал:

 

Реально считаете что это хорошо продакшн трафик пускать по не тестированному каналу? Это крайне, крайне не серьёзный подход, любая уважающая себя организация так не станет делать 

Кто сказал, что нужно сразу пускать по только что поднятому каналу коммерческий трафик?  Сначала конечно тесты, начиная с встроенного Link test и дальше пройти все  изложенные мною выше 3 этапа. При этом измеряется не только скорость, но и другие параметры канала связи, и на каждое измерение есть своя методика.

Реальный трафик- финальная стадия.

[fractal]

14 минут назад, slv700 сказал:

встроенного Link test

Не занимаемся этой ерундой, только флюк или тесты встроенный от Cisco 

 

15 минут назад, slv700 сказал:

дальше пройти все  изложенные мною выше 3 этапа

О чем Вы? Это бред полный, попробовали бы Вы такое газпрому предложить) или объяснить им как по Вашему "правильно" тестить, то что Вы предлогаете это хомякотесты, не профессионально, колхозно по простому, без сертификации

 

17 минут назад, slv700 сказал:

А на  убнт ( я так понял ваш конек :)

У нас 95% оптика, процента 3 ррл на, и остаток линки инфинет, есть камбиум и  юбики в общей сложности около 10 ptp, и принимаем их одинаково и все соответствует от флюка до реального трафика

[slv700]

25 минут назад, fractal сказал:

тесты встроенный от Cisco 

С чего бы ?

 

25 минут назад, fractal сказал:

флюк

Если там есть профайл с тестами радио, то не вопрос.

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

 

28 минут назад, fractal сказал:

Это бред полный, попробовали бы Вы такое газпрому предложить)

У нас есть свои "газпромы", мы  знаем больше их самих что и как им нужно. 

 

30 минут назад, fractal сказал:

роцента 3 ррл на, и остаток линки инфинет, есть камбиум и  юбики в общей сложности около 10 ptp, и принимаем их одинаково и все соответствует от флюка до реального трафика

Ну и хорошо.  Я совершенно определенно знаю разницу и между ррл и старым инфинет и камбиум и убиками. Лучше вникайте в то, что я вам говорю, а не бодайтесь не понимая природы некоторых вещей. 

[fractal]

6 минут назад, slv700 сказал:

 несете ахинею пионера, тестирующего свою сеть из говна и палок.

Поржал, во первых, у нас сеть сугубо на циско, а каналы большой 5ки,они нам строят качественно, во вторых ранее Вы даже и не предполагали этого, то есть голословно не имея аргументов поливаете грязью, в третьих, я к Вам на Вы и Вы также поступайте, а не оскорбляйте меня! А то вроде человек взрослый а как нечего сказать так сразу в грязь

 

8 минут назад, slv700 сказал:

С чего бы ?

Sdwan знаете как тестит каналы и работает? 

 

9 минут назад, slv700 сказал:

есть свои "газпромы", мы  знаем больше их самих что и как им нужно. 

Очень их жаль, раз Вы им даёте свою какую то Выдуманную методику тестирования на довольно хорошем оборудование... Ни сертификации, ни актов принятия услуг наверное даже и нет