Cambium Force 300 CSM vs Ubiquiti AF5X HD

[Alver 335]

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

 

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

 

 

 

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

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

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

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

[Alver 335]

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

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

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

[Alver 335]

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

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

 

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

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

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

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

Відредаговано 2020-03-12 22:14:57 Alver

[Alver 335]

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

 

 

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

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

[xabarov 40]

В 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 Ггц, он более протяженный и на нем мы можем делать все что угодно.

[Alver 335]

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. 

Відредаговано 2020-03-15 07:55:04 Alver

[Alver 335]

 Также рассмотрим в чем есть фокус с 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.

Відредаговано 2020-03-15 09:56:20 Alver

[xabarov 40]

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-тест без ограничений:

 

 

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

 

 

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

 

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

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

 

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

[Alver 335]

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

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

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

[Alver 335]

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    явны видны аномалии, ненормальность. Там есть трюк, примерно такой как я обьяснил. Может с  вариациями, но он точно есть.

Відредаговано 2020-03-15 18:11:04 Alver

[Alver 335]

5 часов назад, xabarov сказал:

 

 

 

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

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

ЗЫ

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

Відредаговано 2020-03-15 22:22:33 Alver

[xabarov 40]

В 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. Посмотрим на ваши скрины:

 

 

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

 

 

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

 

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

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

 

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

 

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

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

 

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

[Alver 335]

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

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

 

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

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

 

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

Відредаговано 2020-03-17 05:38:02 Alver

[Alver 335]

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

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

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

[Diter_ua 78]

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

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

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

[Alver 335]

29 минут назад, Diter_ua сказал:

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

Независимо от количества ядер и архитектуры генератор тестов должен давать  идентичную нагрузку  ( скорость трафика )  в идентичных условиях ( один и тот же тестируемый канал)  при условии что загрузка  ни одного из ядер не достигла 100% (точнее больше 90 %).

Если разница есть, а собcтвенно в этом и подозревается RB4011, то  работа  приложения, генерирующего тест, некорректно  распределяется между ядрами с  изменением стека  протокола TCP , что приводит к получению ошибочного результат теста.

Відредаговано 2020-03-17 10:22:45 Alver

[xabarov 40]

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

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

 

Ну хорошо, я тупой. Ну а вы-то нахрена советовали раньше тестировать канал двумя встречными симплексами iperf? 

 

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

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

 

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

[Alver 335]

13 часов назад, xabarov сказал:

Ну а вы-то нахрена советовали раньше тестировать канал двумя встречными симплексами iperf? 

Есть разница между работой двух приложений  (клиент и сервер   iPerf или    BT MT) в одной задаче   однозадачной ОС   на ПК   и  работы двух приложений в  РАЗНЫХ задачах многозадачной ОС  Linux на ПК.  В чем разница я обьяснил выше.  Если вы не понимаете, то хотя бы воздержитесь от неконструктивного спора и обычных заявлений типа вы все врете.

[Alver 335]

14 часов назад, xabarov сказал:

 

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

 

В моих тестах есть обратный живой трафик +  тестовый 30 М, это  примерно 3K pps. Тем самым что отношение ппс    прямого и обратного канала в моем симплексном тесте  на    RB  типа 750 - до 40%. При этом у меня на тестируемом линке  сильные помехи   с плавающим  размером окна        стека TCP (  видно по трафику)  и             ACKов больше, чем обычно 30-35%.  У вас  же соотношение ппс в прямом и обратном канале в симплексном тесте -52%.  Значит стек TCP  в вашем тесте на   RB4011  отличается от моего теста и живого трафика.    И просто невооруженным глазом видно,  что трафик в ваших  тестах аномально ровный, причем он такой же и в ваших тестах     Airmax,    что ранее в тестах этого типа устройств  никогда такого не было. Те, кто хоть раз тестил канал     тестом TCP  заметит, что есть что то ненормальное в ваших тестах, слишком они нереально красивые, что вызывает подозрения в их неадекватности. В чем может быть фокус, я пояснил. Но для предъявления прямого обвинения в  фабрикации  тестов на  RB4011  пока не хватает фактурного материала и более детальных исследований. Но это все будет. А пока просто скажем, что доверия к вашим тестам нет и не пытайтесь нам их впарить как доказательства отличной работы AF5X HD   и тем более невероятной , просто супервеликолепной, выше теоретического предела , работы канала на   Airmax   Rocket , а также, набрались же наглости, известного всем  мусора   LiteBeam.  

Відредаговано 2020-03-18 10:13:27 Alver

[xabarov 40]

В 18.03.2020 в 12:29, Alver сказал:

Есть разница между работой двух приложений  (клиент и сервер   iPerf или    BT MT) в одной задаче   однозадачной ОС   на ПК   и  работы двух приложений в  РАЗНЫХ задачах многозадачной ОС  Linux на ПК.  В чем разница я обьяснил выше.  Если вы не понимаете, то хотя бы воздержитесь от неконструктивного спора и обычных заявлений типа вы все врете.

 

Хватит испускать словесный понос. Вы на вопрос ответите? Зачем вы сами рекомендовали использовать два встречных симплексных теста?

 

В 18.03.2020 в 12:55, Alver сказал:

В моих тестах есть обратный живой трафик +  тестовый 30 М, это  примерно 3K pps. Тем самым что отношение ппс    прямого и обратного канала в моем симплексном тесте  на    RB  типа 750 - до 40%. При этом у меня на тестируемом линке  сильные помехи   с плавающим  размером окна        стека TCP (  видно по трафику)  и             ACKов больше, чем обычно 30-35%.  У вас  же соотношение ппс в прямом и обратном канале в симплексном тесте -52%.  Значит стек TCP  в вашем тесте на   RB4011  отличается от моего теста и живого трафика.

 

АСК-ов больше, а количество пакетов такое же  О чем это говорит? Мой тест с использованием RB4011 более, чем правильный  

 

В 18.03.2020 в 12:55, Alver сказал:

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

 

Запустите тест в хороших условиях или на столе, и увидите тоже самое.

 

В 18.03.2020 в 12:55, Alver сказал:

причем он такой же и в ваших тестах     Airmax,    что ранее в тестах этого типа устройств  никогда такого не было.

 

Если вы этого никогда не видели, то это обязательно обозначает, что это невозможно?

 

В 18.03.2020 в 12:55, Alver сказал:

Те, кто хоть раз тестил канал     тестом TCP  заметит, что есть что то ненормальное в ваших тестах, слишком они нереально красивые, что вызывает подозрения в их неадекватности.

 

В 18.03.2020 в 12:55, Alver сказал:

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

 

Прошло еще две недели. Каковы результаты?

[Alver 335]

10 часов назад, xabarov сказал:

Зачем вы сами рекомендовали использовать два встречных симплексных теста?

Проблема в том, что дуплексный тест iPerf  глючит, одна версия больше, другая -меньше, есть реализации, где такой тест вообще не работает( не предусмотрен).

Поэтому  дуплексный тест  iPerf  нужно   делать  двумя  встречными симплескными тестами. Что тут может быть непонятного ?

Другой вопрос в том, КАК нужно делать два симплексных теста. 

На одном ПК нужно поднять сервер и клиент iPerf и одновременно запустить тесты в обоих направлениях. При этом  работа программ сервера и клиента должна производиться в рамках  одной задачи ОС  , а не в разных задачах ( виртуальных машинах) со своим виртуальным масштабом  временем, с работой на один  буфер  интерфейса ввода-вывода   в рамках одной задачи ( виртуальной машины).

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

10 часов назад, xabarov сказал:

АСК-ов больше, а количество пакетов такое же  О чем это говорит? Мой тест с использованием RB4011 более, чем правильный  

 

Он говорит о том, что стек TCP протокола в  Bandwidth Test  RB4011   просто другой. Правильный он , неправильный он -неважно,  он есть другой, отличающийся от других BT и ,главное, от  стека TCP в реальной сети.

Відредаговано 2020-04-01 05:47:01 Alver

[Alver 335]

10 часов назад, xabarov сказал:

Запустите тест в хороших условиях или на столе, и увидите тоже самое.

Такой аномальный трафик возможен если потерь TCP пакетов НОЛЬ -  в тестах на столе, либо  на реальном канале, когда, например,   на разных ядрах одновременно работают ДВА стека  TCP  и один стек компенсирует потери пакетов в другом стеке так,  что потери в сумме то есть, но НЕ уменьшается  суммарное окно стека TCP в пачке пакетов на передачу - то есть скорость не плывет, как это должно было быть в случае потерь пакетов и соответствующем уменьшении окна стека TCP.

 

Відредаговано 2020-04-01 05:57:51 Alver

[xabarov 40]

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

Поэтому  дуплексный тест  iPerf  нужно   делать  двумя  встречными симплескными тестами. Что тут может быть непонятного ?

Другой вопрос в том, КАК нужно делать два симплексных теста. 

 

Что ж вы раньше об этом не говорили? Наверно много времени ушло на придумывание?

 

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

На одном ПК нужно поднять сервер и клиент iPerf и одновременно запустить тесты в обоих направлениях. При этом  работа программ сервера и клиента должна производиться в рамках  одной задачи ОС  , а не в разных задачах ( виртуальных машинах) со своим виртуальным масштабом  временем, с работой на один  буфер  интерфейса ввода-вывода   в рамках одной задачи ( виртуальной машины).

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

 

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

[Alver 335]

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

 

Что ж вы раньше об этом не говорили? Наверно много времени ушло на придумывание?

 

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

Відредаговано 2020-04-01 09:51:24 Alver

[Alver 335]

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

 

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

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

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