Перейти до

Cambium Force 300 CSM vs Ubiquiti AF5X HD


Рекомендованные сообщения

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

Там был пример с тестовым трафиком iperf, вы о нем прекрасно знаете. Напомню.

Ну конечно я все прекрасно помню эти тесты  anp/hsp  на Iperf в 2015.  Тогда  ( по ссылке) у меня не было времени разбираться в чем там был фокус , но позже когда он  опять начал тычить этими тестами, я ему сказал, что дуплексные тесты на iperf   в  разных задачах многозадачного Linux делать нельзя. У него получен неадекватный результат дуплекса как сумма двух симплексов,  и я объяснил  почему так получается. Один раз дано разоблачения фокуса и совершенно незачем вытаскивать из забвения  эту херню снова тыкать этим говнотестом .

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

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

Я выразил сомнения в адекватности тестов  TCP на  RB4011. И расписал детально по шагам как можно это проверить По результатам этой  и возможно других проверок можно будет  сделать определенные выводы об адекватности или неадекватности..

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 387
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Ну так и ответьте на него. Вы же делали тесты с полной загрузкой. Что там было по задержке при такой загрузке? Это неправда, AF-5XHD может поднимать 1024QAM на максимальной мощности 29 дБм, под

Радует в этой ситуации одно. Чем больше комбриг лохопетов обработает по камборадиву в мальтпойнт, тем больше у нас временной зазор на стройки , и больше достанется непуганных удаленных сел под пон.

У меня обычные файберы (не HD) на 10км чуть больше 300 Мбит реального трафика тянули (75/25% в полосе 50МГц) Capacity в этот момент показывал 350/120  После этого этот же Линк переместили на

Posted Images

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

то берете капасити за основу в своих доказательствах

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

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

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

Они компетентны , но иногда могут ошибаться, как и все.

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

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

Это все эмоции.:) Подберите лучше технические аргументы. 

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
1 час назад, xabarov сказал:

От вас пока не было никаких замечаний кроме ложных обвинений. Наверно вы позабыли, но я много раз приводил в пример работу магистрального канала на 7 км с антеннами 28 дБ и реальным трафком 350М+, а также один раз показывал вот этот пример на 22 км с тестовым ТСР-трафиком в условиях помех:

Да вы достали уже эти своим скрином. Вам же ясно говорят, что   к этому RB 4011  есть вопросы. Если вам так нравится этот RB401, то  проведите все тесты UDP, TCP   симплекс , дуплекс ( как вы это делали для повербима) и будет более ясно что тест показывает.    Или Iperf,  но чтобы были видны ключи запуска теста. Или этот самый ваш пример работы  на 7 км с реальным трафиком 350+М.  Приведите его, дайте ссылку на него, я что то не припоминаю этот кейс.

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
10 часов назад, xabarov сказал:

У меня есть пара дружественных провайдеров, от которых можно получить какие-то скрины, но они находятся вдалеке от больших помех и боюсь их результаты еще больше расстроят вас :)

Не надо боятся и стеснятся. Если есть представляющие интерес результаты, выкладывайте. Если там  есть косяк, то разберемся, но обвинений  во вранье  не будет. Ну ошиблись люди, с кем не бывает? :). Только не надо уходить в отказ и упорствовать в своем невежестве . 

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
20 часов назад, Alver сказал:

Во первых , это ПК/ноут на многоядерном x86 Intel  на  ROS.

 

Я так понимаю к многоядерному интелу не возникло вопросов? :) 

 

20 часов назад, Alver сказал:

Ну конечно я все прекрасно помню эти тесты  anp/hsp  на Iperf в 2015.  Тогда  ( по ссылке) у меня не было времени разбираться в чем там был фокус , но позже когда он  опять начал тычить этими тестами, я ему сказал, что дуплексные тесты на iperf   в  разных задачах многозадачного Linux делать нельзя. У него получен неадекватный результат дуплекса как сумма двух симплексов,  и я объяснил  почему так получается. Один раз дано разоблачения фокуса и совершенно незачем вытаскивать из забвения  эту херню снова тыкать этим говнотестом .

 

Что-то не припомню таких разоблачений, дайте прямую ссылку. 

 

20 часов назад, Alver сказал:

Я выразил сомнения в адекватности тестов  TCP на  RB4011.

 

И попутно назвали все мои тесты фальшивками :) 

 

20 часов назад, Alver сказал:

Я еще раз повторяю, что Капасити не является точной оценкой пропускной способности канала. В то же время если тест дает оценку   выше Капасити, то это говорит о неадекватности теста. 

 

Вы достоверно знаете, какая именно логика заложена в капасити УБНТ, чтобы так утверждать? 

 

19 часов назад, Alver сказал:

Да вы достали уже эти своим скрином. Вам же ясно говорят, что   к этому RB 4011  есть вопросы. Если вам так нравится этот RB401, то  проведите все тесты UDP, TCP   симплекс , дуплекс ( как вы это делали для повербима) и будет более ясно что тест показывает.    Или Iperf,  но чтобы были видны ключи запуска теста. Или этот самый ваш пример работы  на 7 км с реальным трафиком 350+М.  Приведите его, дайте ссылку на него, я что то не припоминаю этот кейс.

 

На этом форуме я уже минимум несколько раз выкладывал скрины с рабочего линка 7 км. Вот свежий, только что заскринил:

 

aF5HD-40-real_7km.thumb.png.5eb5afe200e99a181b9013ce4f48683e.png

 

Суммарный реальный трафик в 40 МГц - более 350 Мбит/с.

 

На 22 км тесты проведены (только тестовый трафик), картинки нужно подрезать и подготовить описание. Выложу в отдельной теме.

 

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

Не надо боятся и стеснятся. Если есть представляющие интерес результаты, выкладывайте. Если там  есть косяк, то разберемся, но обвинений  во вранье  не будет. Ну ошиблись люди, с кем не бывает? :). Только не надо уходить в отказ и упорствовать в своем невежестве . 

 

Вы забавный. Я несколько раз предлагал вам выложить примеры максимальной пропускной способности на UBNT AC с условием, что вы опровергните свои утверждения про якобы максимальную скорость в 180-200 Мбит/с и публично принесете извинения. Вы сами пошли в отказ и потребовали от меня выкладывать примеры без каких-либо условий. Я напряг своих сотрудников, потратил время, провел тесты, выложил полученные результаты и в ответ получил ушат дерьма - тесты фальшивые, да и никому не нужны, так как оказывается "и так все ясно". Второй раз я на такое не поведусь. Условия - вы публично соглашаетесь признать любые результаты/примеры и принести извинения/опровергнуть все свои утверждения о якобы плохой работе AF-5XHD, если это будет подтверждено опытом других провайдеров. Согласны?

  • Thanks 1
Ссылка на сообщение
Поделиться на других сайтах
1 час назад, xabarov сказал:

многоядерному интелу не возникло вопросов?

Там тест выполняется на одном ядре. Там совсем другие ядра.

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

Что-то не припомню таких разоблачений, дайте прямую ссылку. 

Было где то год назад. Ищите и найдете

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

И попутно назвали все мои тесты фальшивками

Результат  фальшивый. А причин может быть масса, в том числе  ваша некомпетентность, или неадекватность  RB4011, что и следует проверить.

Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, xabarov сказал:

Суммарный реальный трафик в 40 МГц - более 350 Мбит/с.

 

Хорошо, этот кейс принимается. На 1024QAM  это возможно получить, если эта модуляция поднята и стабильно работает. . Но вопрос кода это  ЕСЛИ  выполняется - остается открыт. Точнее там все ясно, а кому не ясно, пусть пробует.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
2 часа назад, xabarov сказал:

 

Вы забавный. Я несколько раз предлагал вам выложить примеры максимальной пропускной способности на UBNT AC с условием, что вы опровергните свои утверждения про якобы максимальную скорость в 180-200 Мбит/с и публично принесете извинения. Вы сами пошли в отказ и потребовали от меня выкладывать примеры без каких-либо условий. Я напряг своих сотрудников, потратил время, провел тесты, выложил полученные результаты и в ответ получил ушат дерьма - тесты фальшивые, да и никому не нужны, так как оказывается "и так все ясно". Второй раз я на такое не поведусь. Условия - вы публично соглашаетесь признать любые результаты/примеры и принести извинения/опровергнуть все свои утверждения о якобы плохой работе AF-5XHD, если это будет подтверждено опытом других провайдеров. Согласны?

Вы опять все передергиваете.

Я повторяю, что я сказал выше в теме - все можно точно посмотреть.

1) У меня есть претензии к тестам Airmax. Результат - фальшивка,    потому что получен результат a) выше теоретического  предела б) выше Капасити.  Возможная причина - неадекватность теста RB4011, что нужно проверить. Как проверить, я также сказал.

2) у меня нет претензий к тесту  AF5x HD  на 3 км  на Iperf. Я об этом точно и недвусмысленно сказал выше в теме. Единственное пожелание, хотелось бы в тестах iperf видеть ключи запуска теста.

3) Что касается полки  Airmax до 200М то эти данные в том числе получены вами в TCP тестах PowerBeam насколько я помню, 10-12 км.

Вы можете эти данные опровергнуть,  получив  и показав результат TCP тестов, но не на RB4011, потому как к нему есть вопросы, а скажем  TCP Iperf   или показав живой реальный трафик >200 Mbps DL на любом устройстве  Airmax на дальности 5-10+ км.

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

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
23 часа назад, Alver сказал:

Было где то год назад. Ищите и найдете

В 11.03.2020 в 20:51, xabarov сказал:

 

Отличный способ слить по любому вопросу! Надо взять на вооружение :) 

 

23 часа назад, Alver сказал:

А причин может быть масса, в том числе  ваша некомпетентность, или неадекватность  RB4011, что и следует проверить.

 

Ну так проверьте уже сами. В чем проблема?

 

23 часа назад, Alver сказал:

На 1024QAM  это возможно получить, если эта модуляция поднята и стабильно работает. . Но вопрос кода это  ЕСЛИ  выполняется - остается открыт.

 

Никаких открытых вопросов - есть CINR 40 dB, значит поднимется. Если будет в пределах 32~39, то скорее всего будет работать нестабильно. Если меньше 30, то точно работать не будет. Если весь эфир забит и нет необходимой свободной полосы - точно не стоит рассчитывать на 1024QAM. Если на моем линке 7 км с небольшими помехами он поднялся, то на 20-30 км скорее всего поднимется только в чистом эфире с антеннами 34 дБ (на моем линке 22 км с антеннами 31 дБ изредка проскакивает, но там есть средне-слабые помехи и энергетика на грани). 

 

23 часа назад, Alver сказал:

Вы опять все передергиваете.

Я повторяю, что я сказал выше в теме - все можно точно посмотреть.

 

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

 

23 часа назад, Alver сказал:

1) У меня есть претензии к тестам Airmax. Результат - фальшивка,    потому что получен результат a) выше теоретического  предела б) выше Капасити.

 

Вы сами выше подтвердили, что полученные цифры в пределах теоретического предела (310-320 Мбит/с). Ну и ни разу не ответили на мой вопрос - вам достоверно известна логика, которую инженеры заложили в Capacity?

 

23 часа назад, Alver сказал:

3) Что касается полки  Airmax до 200М то эти данные в том числе получены вами в TCP тестах PowerBeam насколько я помню, 10-12 км.

Вы можете эти данные опровергнуть,  получив  и показав результат TCP тестов, но не на RB4011, потому как к нему есть вопросы, а скажем  TCP Iperf   или показав живой реальный трафик >200 Mbps DL на любом устройстве  Airmax на дальности 5-10+ км.

 

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

 

Реальный трафик больше 200 есть только на 7 км, но там магистраль, на которой нет возможности для экспериментов. На 22 км можно погонять iperf, но если цифры будут "выше капасити", то вы опять назовете их фальшивыми? :) 

Ссылка на сообщение
Поделиться на других сайтах
В 09.03.2020 в 00:21, Alver сказал:

ЗЫ

Предлагаю Вам уважаемый  argus78 все же найти время и  рассказать нам всем  в  чем же   есть  противоречие ( вранье ?) , например ,  в моей характеристике вашего  данного  линка или в другом известном вам кейсе.

 

В 11.03.2020 в 21:50, Alver сказал:

Было где то год назад. Ищите и найдете

без лишних слов...

Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, xabarov сказал:

 

 Отличный способ слить по любому вопросу! Надо взять на вооружение :) 

 

 

 

Да вот эти тесты, фальшивка.  Здесь

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

Ну так проверьте уже сами. В чем проблема?

Проверяем. Все расскажем.

Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, xabarov сказал:

Никаких открытых вопросов - есть CINR 40 dB, значит поднимется. Если будет в пределах 32~39, то скорее всего будет работать нестабильно. Если меньше 30, то точно работать не будет. Если весь эфир забит и нет необходимой свободной полосы - точно не стоит рассчитывать на 1024QAM. Если на моем линке 7 км с небольшими помехами он поднялся, то на 20-30 км скорее всего поднимется только в чистом эфире с антеннами 34 дБ (на моем линке 22 км с антеннами 31 дБ изредка проскакивает, но там есть средне-слабые помехи и энергетика на грани). 

Проблема в том, что CINR файбер измеряет неправильно и неадекватно выставляет свою рабочую  модуляцию/.  Если помех нет или их мало и    SNR =CINR, то проблема не проявляется и линк работает достойно. А вот если помехи есть, то  работа линка непрогнозируема. В этом и есть вся  суть работы AF5x HD. 

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
2 часа назад, xabarov сказал:

Вы сами выше подтвердили, что полученные цифры в пределах теоретического предела (310-320 Мбит/с). Ну и ни разу не ответили на мой вопрос - вам достоверно известна логика, которую инженеры заложили в Capacity?

 

Штатный суппортер на оф. форуме ,  некто CloudeSS , сделал калькулятор скорости  UBNT на  Excel.   Там видны формулы расчета.  Этот калькулятор можно найти на их форуме. Ищите и найдете :)

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

Реальный трафик больше 200 есть только на 7 км, но там магистраль, на которой нет возможности для экспериментов.

Так покажите загрузку  канала живым трафиком. В чем проблема?

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, xabarov сказал:

 

 

Реальный трафик больше 200 есть только на 7 км, но там магистраль, на которой нет возможности для экспериментов. На 22 км можно погонять iperf, но если цифры будут "выше капасити", то вы опять назовете их фальшивыми? :) 

Вполне допустимо живой трафик догружать  TCP тестом. Например  Iperf или на    BT микротик  Но не надо  пока этого делать на  RB4011, c   ним нужно еще разобраться.

Ссылка на сообщение
Поделиться на других сайтах
В 13.03.2020 в 01:02, Alver сказал:

Да вот эти тесты, фальшивка.  Здесь

 

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

 

В 13.03.2020 в 01:08, Alver сказал:

Проблема в том, что CINR файбер измеряет неправильно и неадекватно выставляет свою рабочую  модуляцию/.  Если помех нет или их мало и    SNR =CINR, то проблема не проявляется и линк работает достойно. А вот если помехи есть, то  работа линка непрогнозируема. В этом и есть вся  суть работы AF5x HD. 

 

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

 

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

Первая  и основная  причина GPF MISS -сильные помехи в канале управления CPE.

Это  проблема не является специфичной для Elevate, она иногда  проявляется и на родных СПЕ и давно известна.

 

Зачем же это приписывать только файберу?

 

В 13.03.2020 в 01:14, Alver сказал:

Штатный суппортер на оф. форуме ,  некто CloudeSS , сделал калькулятор скорости  UBNT на  Excel.   Там видны формулы расчета.  Этот калькулятор можно найти на их форуме. Ищите и найдете :)

 

Теперь вы перестали указывать ссылки - похоже боитесь, что ваши ложные заявления разнесут :) 

 

В 13.03.2020 в 01:14, Alver сказал:

Так покажите загрузку  канала живым трафиком. В чем проблема?

 

Живую загрузку на AF-5XHD уже показал. Ставить Airmax AC на этом линке вместо AF-5XHD несколько трудоемко и есть риск навредить работоспособности сети. Но самое главное - ради чего? Чтобы вы опять слили, обвинили в "специально подобранных условиях" и сказали под конец "работа убнт ас известна и никому ваши результаты не интересны"? Линк 22 км более интересен - там больше помех, антенна для диапазона 5 Ггц, он более протяженный и на нем мы можем делать все что угодно.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
19 часов назад, xabarov сказал:

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

Вы ничего не поняли.  

Объясняю еще раз  в чем есть ошибка ( фокус)  в  тесте  здесь некоего anp/hsw  и поэтому в тестах получен неправильный  результат   работы Rocket 5AC 

Объясняю просто, как для солдат и матросов.

 Тест iperf TCP через радиоканал  между двумя  PC на Linuх на столе. На каждой стороне линка в  разных задачах  ( процессах) Linux поднят сервер и клиент Iperf. В  каждую сторону  одновременно запущен тест  TCP simplex Ipref  server-> client.   Получено в 40 МГц по 150 Mbps в каждую сторону.   Как бы похоже на дуплексный тест и поэтому результат складывается 150+150=300 Mbps в 40 МГц. Типа супер! Однако в тесте есть ошибка. 

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

 Я надеюсь , что на этот раз понятно в чем в тестах есть ошибка (трюк) и просьба не ссылаться более на эти эти фальшивые тесты, как доказательство высокой скорости канала на Rocket 5AC Airmax. 

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

 Также рассмотрим в чем есть фокус с TCP тестом RB4011.

Есть приложение -генератор тестов  Bandwidth Test  Mikrotik , выполняемое на нескольких ядрах  -процессорах CPU устройства RouterBoard.    Это проводится  путем выделения  супервизором задач  операционной системы   ROS ( Linux)  каждому процессору-ядру кванта времени и последовательно по очереди выполняет это приложение на разных ядрах. То есть  в каждый момент времени приложение работает только на одном ядре .   Понятно, что такое исполнение программы последовательно на нескольких ядрах  не ускоряет  исполнение программы. Время исполнения ОДНОГО приложения  на нескольких ядрах остается точно таким же как и на одном ядре . Однако ускорение есть для суммарного времени  одновременной работы  НЕСКОЛЬКИХ  РАЗНЫХ приложений , за счет того, что  исполнение программ распределено по  по  нескольким ядрам.  

     На прошивке RoS ( вышла полгода назад) , где впервые   при работе Bandwidth Test  Mikrotik были задействованы   несколько ядер , тест  как и ранее на одном ядре, не мог генерировать больше чем  TCP 200-300 Mbps трафика, несмотря на то, что в тесте были загружены , но по очереди, все ядра устройства.  Но вот  на новом устройстве RB4011, процессор которого не намного более производительный, чем на других устройствах  Микротик,  мы вдруг неожиданно увидели что генерируемый TCP трафик вырос  не много , не мало -  сразу в 3-4 раза.

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

1) потери пакетов TCP    и снижение размеров окна   стека TCP (  количество пакетов в одной засылаемой в канал пачке ) одного стека, что приводит к снижению скорости  TCP потока,   мгновенно компенсируется увеличением размеров окна  других стеков  на других исполняемых копиях  BT и компенсацией снижения скорости трафика на одном  стеке  восполнением трафика на других  стеках.

2)   тестируемый канал  не простаивает во время ожидания ответа ACK - подтверждения успешного приема пачки  TCP пакетов. Пока один стек ждет ACK, другие стеки заполняют канал своим трафиком .

3) дуплексный TCP тест не является таковым, потому что образуется из двух противоположных симплексов, выполняемых последовательно  в разные  моменты времени различными  копиями ( приложениями, )тестера . То есть  ситациция аналогична тому, как это происходит  в описанных выше  тестах в многозадачной ОС  или виртуальных машинах.

         Фактически мы  в тестах TCP имеем работу с  совершено иным синтезированным суммарным стеком протокола TCP, отличающимся от стека TCP  BT одноядерного  устройства и, главное, от стека   TCP реального   трафика.

         Фактически такой тест в реализации  на RB4011 хотя и остался   TCP , но потерял свою информативность  о потерях в канале и задержках в подтверждении  успешности в доставке пакетов и фактически стал идентичен  UDP.

         Это легко увидеть протестировав  канал  RB4011 пакетами  UDP и TCP,  и результаты этих тестов будут близки.  А в правильных  тестах скорость TCP должна быть как минимум меньше   UDP  на 10-15%.   И чем больше потерь в канале, тем больше разница.

       Также то, что в  ВТ  RB4011     работают несколько стеков  TCP видно по пакетной нагрузке. Пакетная нагрузка обратного канала трафиком ACK  в симплексном  правильном TCP  тесте  и реальном живом  TCP  трафике обычно  составляет 30-35  %. В случае RB4011 эта цифра превышает 60%.

    Тем самым, предварительные исследования показывают, что   новый генератор TCP  теста  Bandwidth Test на многоядерных Микротик ( следует  ожидать такое поведение BT и на других устройствах  МТ)   по всем признакам стал неадекватно тестировать канал   TCP тестом.  Поэтому до  подтверждения или опровержения данного поведения со стороны компании Микротик, других результатов независимых исследований другими специалистами, просьба воздержаться от ликований при получении очередных фальшивых рекордов и ложных выводов о  якобы высокой пропускной способности оборудования, на основе результатов, полученных на  RB4011.

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
8 часов назад, Alver сказал:

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

 

Пруфы будут?

 

8 часов назад, Alver сказал:

Я надеюсь , что на этот раз понятно в чем в тестах есть ошибка (трюк) и просьба не ссылаться более на эти эти фальшивые тесты, как доказательство высокой скорости канала на Rocket 5AC Airmax. 

 

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

 

8 часов назад, Alver сказал:

 На прошивке RoS ( вышла полгода назад) , где впервые   при работе Bandwidth Test  Mikrotik были задействованы   несколько ядер , тест  как и ранее на одном ядре, не мог генерировать больше чем  TCP 200-300 Mbps трафика, несмотря на то, что в тесте были загружены , но по очереди, все ядра устройства.  Но вот  на новом устройстве RB4011, процессор которого не намного более производительный, чем на других устройствах  Микротик,  мы вдруг неожиданно увидели что генерируемый TCP трафик вырос  не много , не мало -  сразу в 3-4 раза.

Это произошло за счет того, что Микротик , по всем внешним признакам ,совершенно определенно стал выполнять на нескольких ядрах не одно приложение BT, а несколько  копий BT, каждое со своим отдельных стеком TCP. 

 

Как это вы определили? Опять придумали?

 

8 часов назад, Alver сказал:

Фактически такой тест в реализации  на RB4011 хотя и остался   TCP , но потерял свою информативность  о потерях в канале и задержках в подтверждении  успешности в доставке пакетов и фактически стал идентичен  UDP.

         Это легко увидеть протестировав  канал  RB4011 пакетами  UDP и TCP,  и результаты этих тестов будут близки.  А в правильных  тестах скорость TCP должна быть как минимум меньше   UDP  на 10-15%.   И чем больше потерь в канале, тем больше разница.

 

Что ж, давайте проверим вашу неподтвержденную теорию на практике. Симплексный UDP-тест без ограничений:

 

40MHZ_UDP_simplex_3km.thumb.png.6f7a73c1469a12525388771ddeb26f82.png

 

Симплексный ТСР-тест без ограничений:

 

40MHZ_TCP_simplex_3km.thumb.png.3588bf06b7596be57a217820fdd855cd.png

 

Упс! В ТСР-тесте все совсем по-другому - мы видим 12 тыс. подтверждающих пакетов в обратном канале, загрузку CPU в 2.5 раза больше, чем при UDP, а трафика на 8% меньше. Пришло время для придумывания новых оправданий вашей лжетеории. 

 

8 часов назад, Alver сказал:

Тем самым, предварительные исследования показывают, что   новый генератор TCP  теста  Bandwidth Test на многоядерных Микротик ( следует  ожидать такое поведение BT и на других устройствах  МТ)   по всем признакам стал неадекватно тестировать канал   TCP тестом.  Поэтому до  подтверждения или опровержения данного поведения со стороны компании Микротик, других результатов независимых исследований другими специалистами, просьба воздержаться от ликований при получении очередных фальшивых рекордов и ложных выводов о  якобы высокой пропускной способности оборудования, на основе результатов, полученных на  RB4011.

 

Думаю компании Микротик не стоит даже обращать внимание на выдумки завравшегося продавца.

  • Like 1
Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, xabarov сказал:

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

Какой вам нужно пруф? Что так тесты никто больше нигде и ни когда не делал?

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
53 минуты назад, xabarov сказал:

Упс! В ТСР-тесте все совсем по-другому - мы видим 12 тыс. подтверждающих пакетов в обратном канале, загрузку CPU в 2.5 раза больше, чем при UDP, а трафика на 8% меньше. Пришло время для придумывания новых оправданий вашей лжетеории. 

 

12 тыс пакетов  в обратном канале против 23 тыс в прямом- это 52%. Видимо у вас в тесте очень мало потерь  и окно TCP стека максимальное и  меньше ACKов. Но это все  равно в 1.5 -2 раза выше, чем есть на живом трафике и TCP тесте на другом  RB. Кроме того 23 тыс TCP    пакетов на трафике 290М -это мало, точно есть очень большое окно и длинные пачки пакетов. Для такого трафика пакетов  ппс должно быть под 30 тыс. Тем самым  похоже в добавок  ко всему в синтетических тестах  искусственно увеличен размер    пачки   пакетов. Обычно на скорость влияет( тормозит)  недостаточный размер окна TCP,  а его увеличение не увеличивает скорость. Но в этих тестах мы видим другую -противоположную  картину.

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

Разница 8%   между UDP и TCP тестом незначительна. Она 1) должна быть больше 2) трафик TCP без ограничений  не может быть таким ровным.   Тест всегда стремится пробить полку и при ее достижении теряет пакеты и снижает скорость.  Флуктуация  скорости должна быть . 

У вас во всех тестах разница между цифрами загрузки current и average  неестественно мизерная . Такого  в нормальных тестах не бывает.

Загрузка проца на web - это средняя по всем ядрам. Нужно зайти  Resource- CPU  посмотреть как загружено каждое ядро.

Сделайте UDP TCP тест без ограничений  в канале  20 Мгц другим  RB.  Он 150-200М TCP вытянет, но покажет как должен выглядеть правильный тест.

В тестах RB4011    явны видны аномалии, ненормальность. Там есть трюк, примерно такой как я обьяснил. Может с  вариациями, но он точно есть.

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
5 часов назад, xabarov сказал:

 

 

 

Думаю компании Микротик не стоит даже обращать внимание

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

ЗЫ

Камбиум про эти аномалии тестов на RB4011 знает.  Он и  обратил на них мое внимание , когда  я их попросил  обьяснить   высокую  пакетную нагрузку   в  TCP тесте канала  на PTP550  на  RB4011. 

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
В 15.03.2020 в 20:20, Alver сказал:

Какой вам нужно пруф? Что так тесты никто больше нигде и ни когда не делал?

 

То что никто никогда не делал - это ваша очередная выдумка. А пруф простой:

 

1) Возьмите 4 компа и сделайте два встречных симплексных iperf-теста.

2) Возьмите 2 компа и сделайте два встречных симплексных iperf-теста.

 

Результаты сюда. Если не сделаете, то будем считать это вашим поражением в этом вопросе. Сколько времени нужно вам для этого?  

 

В 15.03.2020 в 20:48, Alver сказал:

12 тыс пакетов  в обратном канале против 23 тыс в прямом- это 52%. Видимо у вас в тесте очень мало потерь  и окно TCP стека максимальное и  меньше ACKов. Но это все  равно в 1.5 -2 раза выше, чем есть на живом трафике и TCP тесте на другом  RB. Кроме того 23 тыс TCP    пакетов на трафике 290М -это мало, точно есть очень большое окно и длинные пачки пакетов. Для такого трафика пакетов  ппс должно быть под 30 тыс. Тем самым  похоже в добавок  ко всему в синтетических тестах  искусственно увеличен размер    пачки   пакетов. Обычно на скорость влияет( тормозит)  недостаточный размер окна TCP,  а его увеличение не увеличивает скорость. Но в этих тестах мы видим другую -противоположную  картину.

 

Я уже с большим трудом сдерживаю себя, чтобы не начать вас оскорблять за вашу ахинею. Вот тут вы делились результатами force 300 csm, сделанные с помощью BT. Посмотрим на ваши скрины:

 

TCP_280_30M_12ms_40MHz.png.336c01186d70197fcfc40437b7e4f5fd.thumb.png.387ae1193a7209d61ab6351bb5555097.png

 

А теперь еще раз на мой, к которому у вас есть претензии:

 

40MHZ_TCP_simplex_3km.thumb.png.be18c1dc5e0347eab8d4fd225eb87080.png

 

И что же мы видим? Цифры-то практически идентичные! Только в вашем случае еще есть около 10% обратного трафика, а в моем чистый симплекс, в котором количество пакетов в обратном канале почти такое же, как в вашем дуплексном примере. О чем это говорит? Все еще мало вам пакетов? Или какие-то другие объяснения найдете? Давайте, топите себя дальше, дно уже близко :) 

 

В 15.03.2020 в 20:48, Alver сказал:

Сделайте UDP TCP тест без ограничений  в канале  20 Мгц другим  RB. 

 

За этим линком нет других микротиков, да уже и не будет в ближайшее время. RB4011 работают отлично (точно также как в ваших примерах) и нет никаких причин менять их на что-то другое. 

 

В 15.03.2020 в 20:48, Alver сказал:

В тестах RB4011    явны видны аномалии, ненормальность. Там есть трюк, примерно такой как я обьяснил. Может с  вариациями, но он точно есть.

 

Получается, что и все ваши тесты фальшивые? Их результаты очень похожи на мои тесты, которые вы называете аномальными и фальшивыми :)  

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
8 часов назад, xabarov сказал:

То что никто никогда не делал - это ваша очередная выдумка. А пруф простой:

 

1) Возьмите 4 компа и сделайте два встречных симплексных iperf-теста.

2) Возьмите 2 компа и сделайте два встречных симплексных iperf-теста.

 

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

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
8 часов назад, xabarov сказал:

этим линком нет других микротиков, да уже и не будет в ближайшее время. RB4011 работают отлично (точно также как в ваших примерах) и нет

Можно поставить вопрос по другому.  Сделайте TCP тест  на столе без ограничения  на любом оборудовании  в канале 20Мгц на  4-х ядерном RB4011 и любом другом многоядерном Микротике типа  RB750 ( два ядра)  или  даже любом одноядерном  МТ , 150 Мbps в 20 Мгц  они все  по любому вытянут. И посмотрите разницу.

Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, Alver сказал:

Можно поставить вопрос по другому.  Сделайте TCP тест  на столе без ограничения  на любом оборудовании  в канале 20Мгц на  4-х ядерном RB4011 и любом другом многоядерном Микротике типа  RB750 ( два ядра)  или  даже любом одноядерном  МТ , 150 Мbps в 20 Мгц  они все  по любому вытянут. И посмотрите разницу.

а что это даст? там же частота ядер и архитектура разная

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас

×
×
  • Створити нове...