[slv700]

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

глюки iperf.

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

[slv700]

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

Не знаю как на локальном рынке, а в России полный комплект с дуплексерами и тарелками 80 см обойдется в ~$2500. Если посмотреть общедоступные цены на PTP 550, то можно найти варианты в пределах $700-800, т.е. грубо комплект без антенн около $1500. Комплект антенн с высоким КУ обойдется минимум в $600-700, итого получаем $2100-2200 за потенциально геморройный (в плане помех) линк на 5-ке. Есть ли смысл в экономии нескольких сотен? Точно нет. Сочувствую вашему клиенту-провайдеру.

Скажу как в Украине. Розничная цена PTP550 -$695.  Антенна типа Рокетдиш 30  дБи -$130.   Всего за линк $1650.

AF11x    с   одним дуплексером стоит  $890. C двумя дуплекерами ( чтобы  получить два канала с сопоставимой с  PTP 550 скоростью) -$1100.   Антенна AF-11G35 -$430.   Всего линк $3050.   Причем эта цена на AF11x у несунов  ( челноков) только под заказ, Польша -рядом :). А  так чтобы зашел в магазин и купил -нет. А с технической точки зрения то,  что в 11 ГГц  выше качество канала связи ( например ниже задержка и    надежность канала в    BER   выше ), то это понятно. Но стоит ли за это переплачивать каждый провайдер решает для себя сам. 

Кроме того есть разница в Украине  в эксплуатационных расходах  легального линка в 5 ГГц ( они несущественные )  и легального линка в 11 Ггц . Но вот сравнить их по этому параметру нельзя.  AF11x  как и любой AF в Украине не сертифицирован. Понятно кому придется сочувствовать после конфискации  нелегального оборудования и штрафа .

В России другое ценообразование  и условия легализации.  Но не  думаю, что разница  в цене легального оборудование PTP550 и AF11x  составляет несколько сотен USD. Лукавите вы, по своему обыкновению,  с ценами :)

 

 

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

Если есть LOS, то на коротком расстоянии до 15-20 км релейка однозначно вне конкуренции.

Да это коню ясно, что релейка вне конкуренции по качеству канала связи, если есть   LOS. Но по цене намного дороже, да и LOS не всегда есть.  Больше расходы за мониторинг регулятором. В общем не туда вы xabarov углубились . Не знаю как в  России, но в Украине AF11x не  составляет конкуренции Cambium 5  Ггц вообще  и PTP 550    в частности.

[slv700]

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

Во время TCP теста iperf обратного трафика почти не было, даже мегабита. Он был похож 1 в 1 на UDP тест iperf. Можете повторить свой тест iperf TCP simplex и показать интерфейс микротика?

 Вот нашел  скрин  теста Iperf  TCP Download канала 40+40 МГц, не вошедший в отчет.  Канал пустой, нет живого трафика.

 На  интерфейсе  Микротик, который стоял  между ПК с  Iperf   и  Мастером, видна загрузка  TCP DL 509 MBps и обратный трафик  TCP UL 8.1 Mbps.

[xabarov]

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

Скажу как в Украине. Розничная цена PTP550 -$695.  Антенна типа Рокетдиш 30  дБи -$130.   Всего за линк $1650.

Все таки правильнее сравнивать с RD-5G34, который вдвое дороже, т.к. у AF11 штатная тарелка более 80 см. 30-ые диши годятся только для небольших расстояний, чтобы 256QAM стабильно держать в условиях небольших помех.

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

Кроме того есть разница в Украине  в эксплуатационных расходах  легального линка в 5 ГГц ( они несущественные )

И что же, на Украине можно за несущественные деньги оформить полосу 160 МГц? :) один хрен оба варианта будут работать нелегально в вашем случае. В России только в 20 МГц более-менее реально получить в пятерке (и это провинция).

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

В России другое ценообразование  и условия легализации.  Но не  думаю, что разница  в цене легального оборудование PTP550 и AF11x  составляет несколько сотен USD. Лукавите вы, по своему обыкновению,  с ценами :)

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

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

На  интерфейсе  Микротик, который стоял  между ПК с  Iperf   и  Мастером, видна загрузка  TCP DL 509 MBps и обратный трафик  TCP UL 8.1 Mbps.

Не завалялось аналогичного с UDP?

[slv700]

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

Все таки правильнее сравнивать с RD-5G34, который вдвое дороже,т.к. у AF11 штатная тарелка более 80 см. 30-ые диши годятся только для небольших расстояний, чтобы 256QAM стабильно держать в условиях небольших помех.

 34 дБи RD-5G34 мало пользуются спросом, во всяком случае  на линках на Камбиум. 30 дБи RD обычно хватает до 40-50 км, дает  в LOS  при Tx 24 dBm  сигнал  -55/-57 dBm.   Если помех  немного, то этого Камбиум достаточно для  работы на 256QAM 5/6.

 

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

И что же, на Украине можно за несущественные деньги оформить полосу 160 МГц? :) один хрен оба варианта будут работать нелегально в вашем случае. В России только в 20 МГц более-менее реально получить в пятерке (и это провинция).

В Украине обладателям лицензий на частоты  можно использовать 20, 40 МГц.   Для 2x40 Мгц оформляется как два передатчика. 80 Мгц и 2x80 Мгц разрешено   специальным  пользователям, которым не требуются  лицензии и разрешения частотнадзора.  

И в России тогда получается можно легально получить  для PTP550 20+20 МГц, что даст  легальных 300 Mbps.

 

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

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

Вообще то AF11x не совсем релейка, хоть и работает в 11 Ггц. , Мимоза на вайфай чипсете  тоже может работать в 11 ГГц, и она точно не релейка. А настоящая релейка со скоростями  под 1 Гиг так и стоит от 10K USD.

[slv700]

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

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

На  интерфейсе  Микротик, который стоял  между ПК с  Iperf   и  Мастером, видна загрузка  TCP DL 509 MBps и обратный трафик  TCP UL 8.1 Mbps.

Не завалялось аналогичного с UDP?

На UDP нет подтверждения доставки пакетов, поэтому нет обратного трафика ни на BT Микротик, ни на  Iperf. Вот скрин DL UDP в 40+40 МГц Badwidth  Test Микротик. Как мы видим, обратного трафика  на UDP  нет.

[xabarov]

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

30 дБи RD обычно хватает до 40-50 км, дает  в LOS  при Tx 24 dBm  сигнал  -55/-57 dBm.   Если помех  немного, то этого Камбиум достаточно для  работы на 256QAM 5/6.

 

Вы серьезно? Ваш же пример:

В 18.03.2019 в 17:59, slv700 сказал:

Дальность  - 12 км LOS. Антенны 29 и 32 дБи. Сигналы -54  дБм.

Какие 40-50 км? Вы даже на этом линке проваливались на 64QAM, а про 256QAM на 40-50 км можно забыть, особенно с такими антеннами.

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

На UDP нет подтверждения доставки пакетов, поэтому нет обратного трафика ни на BT Микротик, ни на  Iperf. Вот скрин DL UDP в 40+40 МГц Badwidth  Test Микротик. Как мы видим, обратного трафика  на UDP  нет.

Зачем мне показывать скрины c бэндвичтеста? Я сам такие тесты пачками делал. Меня интересует сравнение именно iperf TCP и iperf UDP.

[slv700]

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

Какие 40-50 км? Вы даже на этом линке проваливались на 64QAM, а про 256QAM на 40-50 км можно забыть, особенно с такими антеннами.

Есть универсальные калькуляторы энергетики линка в LOS,  есть специализированные, например Cambium  LINKPLanner , которые это делают с учетом рельефа местности.  Так вот согласно расчетам на этом   линке сигнал должен быть -47  dBm,   но реально получили  -53/54 dBm (  в пределах погрешности расчетов, а также некачественные пигтейлы, плохая юстировка ). Но на этом линке очень сильные помехи. В 40 Мгц такого сигнала  с такими помехами  достаточно чтобы работать  на 256QAM  5/6, но вот в 80 Мгц помех собирается больше и система  работает преимущественно   на 64QAM 5/6. 

Я еще раз повторяю, что на 40-50 км  можно на 30 дБи получить -55/-57 дБм, что в условиях отсутствия или невысоких помехах достаточно антенн с усилением 30 дБи. Если средние или высокие помехи, то тогда конечно чтобы работать на 256QAM  надо ставить антенны с усилением 32 или даже 34 дБи. Но это частный случай, совсем не обязательно для линка на PTP550 всегда рекомендовать дорогие антенны 34 дБи и еще включать их в ценовое сравнение  с другим оборудованием.

 

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

Зачем мне показывать скрины c бэндвичтеста? Я сам такие тесты пачками делал. Меня интересует сравнение именно iperf TCP и iperf UDP.

Iperf в UDP не использовали. BT Микротик UDP трафика может генерировать  сколько нужно  и в Iperf UDP нет необходимости. . Речь идет о том, что если в UDP тестах  на Микротик нет обратного трафика, то почему он должен появиться у UDP на Iperf?  Даже если он вдруг каким то чудесным образом там появился, то это все  равно противоречит вашему  тезису о том, что у Iperf нет обратного трафика ни в TCP, ни в UDP. 

 

[slv700]

И еще.  Iperf удовлетворяет стандарту RFC 2544 Методология тестирования устройств для соединения сетей.

Интересен  пункт 1  RFC 2544

________________

Введение

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

___________________

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

А вот возьмем UBNT. Это именно у него каждый новый продукт типа революционный.Вспомнить хотя бы заявленные 450+ Mbps   для  UBNT 5AC.  Сколько копий было поломано вокруг одного из первых адекватных  тестов   этого оборудования   OOKLA Speed Test c результатом 200 Mbps в 40 МГц. Кричали что это не  Airmax  UBNT 802.11  ac, вы все врете... Прошло время.  И кто нибудь где нибудь когда нибудь  видел эти  450 MBps TCP в 80 МГц на этом  UBNT 5AC? Нет!!! 

И вот предьявлены тесты Камбиум, тоже  802.11 ac ( только wave 2) .

Дуплекс TCP   в 2x40 =80МГц без труда  пробивает эту самую планку 450 Mbps, выдавая  TCP 500+ Mbps ( UL+DL), а в 2x80 МГц- более  900Mbps , выдавая под  1  Gbps  TCP duplex UL+DL.

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

,

 

[[anp/hsw]]

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

И кто нибудь где нибудь когда нибудь  видел эти  450 MBps TCP в 80 МГц на этом  UBNT 5AC? Нет!!! 

Еще в 2015 видели 630 на 2.6км в UDP. А уж 450 TCP в 80мгц выдать - да вообще нифига не редкость, на самом деле...

https://community.ubnt.com/t5/airMAX-AC/AirMAX-ac-Real-Throughput/m-p/1214734/highlight/true#M4946

 

[xabarov]

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

Некоторые тут скажут, что вот мол Камбиум приукрашивает параметры своей продукции,

Поправочка. Не Камбиум приукрашивает, а вы.

 

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

А вот возьмем UBNT.

Вам мало срача? Зачем провоцируете?

[slv700]

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

Еще в 2015 видели 630 на 2.6км в UDP. А уж 450 TCP в 80мгц выдать - да вообще нифига не редкость, на самом деле...

https://community.ubnt.com/t5/airMAX-AC/AirMAX-ac-Real-Throughput/m-p/1214734/highlight/true#M4946

 

Это встроенный  UDP  duplex 50/50 тест UBNT. Ничего общего c Real Throughput нет.

[[anp/hsw]]

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

Ничего общего c Real Throughput нет.

Помнится, вы говорили также, когда iperf tcp в 40мгц канале показывал результаты, близкие к тесту ubnt.

Хорошо, давайте я вам с барского плеча пожалую -15%. 535 мегабит в 80мгц. Ну как, согласны? Или будете как обычно отрицать реальность?

 

[slv700]

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

Помнится, вы говорили также, когда iperf tcp в 40мгц канале показывал результаты, близкие к тесту ubnt.

Чей тест  iperf tcp в 40мгц близок к какому тесту UBNT?   Можно внятно и конкретики?

 

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

Хорошо, давайте я вам с барского плеча пожалую -15%. 535 мегабит в 80мгц. Ну как, согласны? Или будете как обычно отрицать реальность?

Пока нечего отрицать. Показывайте  TCP Iperf dupleх при  DL/UL= 75/25  или 85/15 %  в 80  МГц и не на столе, а полевой тест, и не 500 метров, а хотя бы  3-5 км.  Будем  смотреть, если все правильно сделано- подтвердим результат, нет - укажем. 

[[anp/hsw]]

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

Чей тест  iperf tcp в 40мгц близок к какому тесту UBNT?   Можно внятно и конкретики?

 

Вам тут совсем недавно кидали мою тему, как я вдоль и поперек тестировал по вашим методикам линк на rocket 5AC lite, а вы потом под шумок испарились. Вот в нем конкретика.

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

а полевой тест, и не 500 метров, а хотя бы  3-5 км.

Я вам ссылку дал на 2.6км, это совсем не на столе.

 

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

Будем  смотреть, если все правильно сделано- подтвердим результат, нет - укажем.

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

 

 

[slv700]

Хватит демагогии. Тесты - в студию. Чтобы была видна дальность, сигналы и ,помехи.. И обязательно дуплекс  в указанной пропорции. 

[[anp/hsw]]

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

Тесты - в студию.

Хорошо, тесты - так тесты. Но сначала давайте закончим с предыдущими, вот они: 

 

В прошлый раз вы что-то ушли из темы не попрощавшись.

 

[slv700]

19 часов назад, [anp/hsw] сказал:

Хорошо, тесты - так тесты. Но сначала давайте закончим с предыдущими, вот они: 

 

В прошлый раз вы что-то ушли из темы не попрощавшись.

 

Что там заканчивать ? Там тесты 40 Мгц, и симметричный дуплекс.

Нужно 80 Мгц и ассиметрия  на TCP 75/25 или 85/15.

Поясню , чтобы было понятно откуда взялись такие требования.

Канал на UBNT 5AC ( как впрочем  и на M5/M2 ) имеет низкую надежность,  в смысле имеет высокие потери пакетов на физическом и канальном MAC уровне.

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

Поэтому в тестах TCP ( учитывает потери)  канал на UBNT  проседает, что особенно заметно  на высоких скоростях - больше 200Мbps TCP  (  потенциально достигаемой  не при  50/50,  а при DL/ UL =75/25% ,или  DL/ UL= 85/ 15 %)   в Download  в 40 Мгц  и еще больше заметно в канале 80 МГц.  Я все понятно обьяснил ?

Есть основания полагать, что в канале Airmaх UBNT из -за потерь  пакетов  невозможно  разогнать скорость TCP больше  250Мbps ни в 40 Мгц, ни в 80 Мгц  в ассиметричном  дуплексе ( есть встречный трафик)  на дальности от 3 км и больше.

 Покажите в своих тестах , что я ошибаюсь.

 Тест нужен  TCP в канале 80 МГц, асимметричный  дуплекс. Покажите, что на UBNT можно получить то, что заявлено, а именно 450М TCP ( UL+DL), а именно при делении 75/25  -   335+ Mbps  TCP download + 115 Mbps TCP Upload( DL/UL 75/25  или 380 Mbps TCP  Download + 70 Mbps TCP Upload ( DL/UL =85/15).

Как мы видим в представленных выше тестах Камбиум это выдает. Теперь покажите что это может UBNT

[[anp/hsw]]

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

Что там заканчивать ? Там тесты 40 Мгц, и симметричный дуплекс.

А как же принятие или непринятие результата? А вы просто ушли.

 

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

Канал на UBNT 5AC ( как впрочем  и на M5/M2 ) имеет низкую надежность,  в смысле имеет высокие потери пакетов на физическом и канальном MAC уровне.

Кто сказал? Утилита athstats показывает обратное.

 

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

Есть основания полагать, что в канале Airmaх UBNT из -за потерь  пакетов  невозможно  разогнать скорость TCP больше  250Мbps ни в 40 Мгц, ни в 80 Мгц  в ассиметричном  дуплексе ( есть встречный трафик)  на дальности от 3 км и больше.

На чем основаны ваши подозрения? На малом размере tcp-окна? :)

 

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

Теперь покажите что это может UBNT

В прошлый раз я тоже показал. Свое поведение, полагаю, вы тоже можете вспомнить.

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

Докажите действиями, что вы можете адекватно вести себя в таких ситуациях, и я сделаю вам тесты.

 

[slv700]

13 часов назад, [anp/hsw] сказал:

Кто сказал? Утилита athstats показывает обратное.

Это видно по работе TCP, что вам и предлагается показать.   Athstats показывает совсем не то.

[slv700]

13 часов назад, [anp/hsw] сказал:

На чем основаны ваши подозрения? На малом размере tcp-окна? :)

 

Размер TCP Windows size можно задать. Но  дело в другом , сколько сегментов  размером до 1460 байт может быть получено  приемником в одном TCP окне без подтверждения доставки  отправителю . Если есть ошибки ( хотя бы один сегмент принят с ошибкой) , то окно ( количество сегментов в окне)  уменьшается   до размера, когда все сегменты принимаются без ошибок. При этом скорость при уменьшении окна падает. Собственно именно по снижению скорости и судят о потерях в канале и реальной пропускной способности канала. 

ЗЫ

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

Давайте  не будем разбираться как работает TCP.  Вы это хорошо знаете . 

Хватит юлить . Тесты - в студию. Попкорном уже запаслись. 

[[anp/hsw]]

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

Athstats показывает совсем не то.

То есть потери по вашему мнению идут не на L1/L2 а выше?

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

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

Зависит от алгоритма congestion control. Сейчас вам не 2000 год, года были только bic/cubic, vegas и reno.

 

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

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

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

 

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

потому что  задача сейчас другая

Уточните, какая сейчас задача, чтобы потом с темы не сьезжать.

 

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

Хватит юлить . Тесты - в студию. Попкорном уже запаслись. 

Я - запасся. Методику тестирования будем применять из прошлого теста, или будете переобуваться в воздухе?

 

[slv700]

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

То есть потери по вашему мнению идут не на L1/L2 а выше?

Ошибки  идут на L1/L2, но на этих уровнях ошибки  ( не все) исправляются  и пакеты  ( не все )  восстанавливаются как в радио, так и на канальном уровне. Вот сколько из этих ошибок пройдет выше на уровень TCP и как они там восстанавливаются и определяется размером окна TCP и скоростью TCP.

 

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

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

 

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

Уточните, какая сейчас задача, чтобы потом с темы не сьезжать.

 

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

Я - запасся. Методику тестирования будем применять из прошлого теста, или будете переобуваться в воздухе?

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

Напомню, изначально топикстартер спрашивал на чем можно получить 250  MBps  реальной ( TCP/IP)    скорости на линке 1 км из  Микротик SXT HG5 ac и Ubiquiti NanoBeam 5AC-19.

Большинство ответивших  людей ответили, что на этих девайсах это невозможно. И это правильно , все так и есть. И я тоже так считаю.

Но вот  вы заявили, что  на rocketAC lite 4км линк дает в 40мгц 230 мегабит, capacity при этом показывает 260.

И предьявили 

1)  линк 4км на Рокет АС Lite,  загруженный 75  Mbps, догруженный  встроенным тестом до цифры 358 Mbps.

Во первых, догрузка живого TCP/IP трафика  встроенным тестом UDP  не дает адекватный результат, получаемая цифра  не соответствует реальной пропускной  способности . Это очевидно.

Во -вторых, цифра 358 Mbps встроенного теста ( причем это цифра догрузки живого трафика 75 Mbps)  в 40 МГц свидетельствует о подтасовке. Это совершенно очевидно встроенный тест канала 80 Мгц . И   вы сударь или мошенник или показания встроенного теста ubnt настолько дебильны, что их вообще нельзя рассматривать для оценки скорости. А ваши аргументы, то вот типа этот Рокет AC решит задачу TC не выдерживают никакой критики и свидетельствуют вашей некомпетентности.

2) После сделанных вам замечаний вы предьявили скрин DL TCP simpleх- 252  Mbps, DL UDP simplex 254 Mbps. Весьма странный результат для линка 4 км (особенно для UBNT) вызвавший подозрения , что он сделан в совсем другом месте, на столе.  

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

Почему нужен дуплексный тест ? Потому что нужно загрузить  трафиком обратный канал, по которому идут ACK подтверждения   доставки  пакетов.   Потому что в реальном канале всегда есть обратный трафик ( UL 10-20% от DL) и он мешает этим ACK   вовремя подтверждать успешную доставку, передатчик должен больше ждать подтверждения от приемника  и скорость  при наличии обратного трафика ( в дуплексе) будет падать.  

Поэтому эти 252  Mbps  при наличии обратного трафика скажем в 20 Mbps превратятся даже не в 232  Mbps,      а вполне возможно намного меньше, я бы сказал, меньше DL 200 Mbps+  UL 20 Mbps.   И эти скорости, пусть даже в идеале 232М+20M не решают задачу ТС,который хочет получить 250Mbps .  Очевидно  нужно иметь 250 Mbps в DL,  когда на реальном линке обязательно будет UL не менее 15-20 Mbps. то есть постановка задачи иметь  TCP DL 250+ UL 15-20 Mbps не решена.

3) Далее вы предьявили дуплексный тест TCP 151+149 Mbps в 40 Мгц ( не факт что он на 4 км). Однако этот тест также не дает ответ на вопрос ТС сможет ли Рокет пропустить 250 Mbps реального трафика. Я уже выше говорил, что  UBNT  сложно выдать 200 Mbps в одном направлении при наличии трафика в обратном направлении  , а  DL TCP 250 MBps  при наличии +UL TCP 15-20 Mbps   в 40 Мгц - невозможно. Поэтому ваши тесты , сделанные тогда ничего не показали и не  доказали. Обсуждать их далее бессмысленно. Проводить  тесты тем же самым образом, что вы делали тогда и опять  не получить нужный результат, не надо.

Поэтому, постановка задачи сейчас такая:

Нужен тест TCP в канале 80 МГц, асимметричный  дуплекс.  Мы ждем от вас   на этот раз  не пруфа своих измышлений для топикстартера, а демонстрация соответствия  результата  заявленным в спецификациях UBNT цифре 450 Мbps реального трафика  ( UL+DL), а именно при делении 75/25  -   335 Mbps  TCP download + 115 Mbps TCP Upload -  деление трафика DL/UL 75/25

или

380 Mbps TCP  Download + 70 Mbps TCP Upload - деление трафика DL/UL =85/15.

[[anp/hsw]]

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

Во -вторых, цифра 358 Mbps встроенного теста ( причем это цифра догрузки живого трафика 75 Mbps)  в 40 МГц свидетельствует о подтасовке. Это совершенно очевидно встроенный тест канала 80 Мгц . И   вы сударь или мошенник или показания встроенного теста ubnt настолько дебильны, что их вообще нельзя рассматривать для оценки скорости. А ваши аргументы, то вот типа этот Рокет AC решит задачу TC не выдерживают никакой критики и свидетельствуют вашей некомпетентности.

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

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

То, что iperf дал в дуплексном тесте на 80, вам тоже не понравится:

cs17 / #iperf3 -B x.x.x.x -c y.y.y.y -w 64k -P 5 -t 60 -i 60 -R -p 5201 &
[1] 22204
cs17 / #Connecting to host y.y.y.y, port 5201
Reverse mode, remote host y.y.y.y is sending
[  4] local x.x.x.x port 41847 connected to y.y.y.y port 5201
[  6] local x.x.x.x port 49086 connected to y.y.y.y port 5201
[  9] local x.x.x.x port 45117 connected to y.y.y.y port 5201
[ 11] local x.x.x.x port 36639 connected to y.y.y.y port 5201
[ 13] local x.x.x.x port 52071 connected to y.y.y.y port 5201
iperf3 -B x.x.x.x -c y.y.y.y -w 64k -P 5 -t 60 -i 60 -p 5000
Connecting to host y.y.y.y, port 5000
[  4] local x.x.x.x port 45623 connected to y.y.y.y port 5000
[  6] local x.x.x.x port 45434 connected to y.y.y.y port 5000
[  9] local x.x.x.x port 46636 connected to y.y.y.y port 5000
[ 11] local x.x.x.x port 48912 connected to y.y.y.y port 5000
[ 13] local x.x.x.x port 37582 connected to y.y.y.y port 5000
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-60.00  sec   389 MBytes  54.4 Mbits/sec                  
[  6]   0.00-60.00  sec   386 MBytes  54.0 Mbits/sec                  
[  9]   0.00-60.00  sec   384 MBytes  53.7 Mbits/sec                  
[ 11]   0.00-60.00  sec   386 MBytes  53.9 Mbits/sec                  
[ 13]   0.00-60.00  sec   381 MBytes  53.3 Mbits/sec                  
[SUM]   0.00-60.00  sec  1.88 GBytes   269 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   389 MBytes  54.4 Mbits/sec   33             sender
[  4]   0.00-60.00  sec   389 MBytes  54.4 Mbits/sec                  receiver
[  6]   0.00-60.00  sec   386 MBytes  54.0 Mbits/sec    1             sender
[  6]   0.00-60.00  sec   386 MBytes  54.0 Mbits/sec                  receiver
[  9]   0.00-60.00  sec   384 MBytes  53.7 Mbits/sec   24             sender
[  9]   0.00-60.00  sec   384 MBytes  53.7 Mbits/sec                  receiver
[ 11]   0.00-60.00  sec   386 MBytes  54.0 Mbits/sec    1             sender
[ 11]   0.00-60.00  sec   386 MBytes  53.9 Mbits/sec                  receiver
[ 13]   0.00-60.00  sec   381 MBytes  53.3 Mbits/sec   28             sender
[ 13]   0.00-60.00  sec   381 MBytes  53.3 Mbits/sec                  receiver
[SUM]   0.00-60.00  sec  1.88 GBytes   269 Mbits/sec   87             sender
[SUM]   0.00-60.00  sec  1.88 GBytes   269 Mbits/sec                  receiver

iperf Done.
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-60.00  sec   286 MBytes  40.0 Mbits/sec  142   82.0 KBytes       
[  6]   0.00-60.00  sec   297 MBytes  41.6 Mbits/sec  155   79.2 KBytes       
[  9]   0.00-60.00  sec   289 MBytes  40.5 Mbits/sec  161   84.8 KBytes       
[ 11]   0.00-60.00  sec   292 MBytes  40.8 Mbits/sec  161   53.7 KBytes       
[ 13]   0.00-60.00  sec   294 MBytes  41.1 Mbits/sec  136   72.1 KBytes       
[SUM]   0.00-60.00  sec  1.42 GBytes   204 Mbits/sec  755             
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   286 MBytes  40.0 Mbits/sec  142             sender
[  4]   0.00-60.00  sec   286 MBytes  40.0 Mbits/sec                  receiver
[  6]   0.00-60.00  sec   297 MBytes  41.6 Mbits/sec  155             sender
[  6]   0.00-60.00  sec   297 MBytes  41.6 Mbits/sec                  receiver
[  9]   0.00-60.00  sec   289 MBytes  40.5 Mbits/sec  161             sender
[  9]   0.00-60.00  sec   289 MBytes  40.5 Mbits/sec                  receiver
[ 11]   0.00-60.00  sec   292 MBytes  40.8 Mbits/sec  161             sender
[ 11]   0.00-60.00  sec   292 MBytes  40.8 Mbits/sec                  receiver
[ 13]   0.00-60.00  sec   294 MBytes  41.1 Mbits/sec  136             sender
[ 13]   0.00-60.00  sec   294 MBytes  41.1 Mbits/sec                  receiver
[SUM]   0.00-60.00  sec  1.42 GBytes   204 Mbits/sec  755             sender
[SUM]   0.00-60.00  sec  1.42 GBytes   204 Mbits/sec                  receiver

iperf Done.
[1]+  Done                    iperf3 -B x.x.x.x -c y.y.y.y -w 64k -P 5 -t 60 -i 60 -R -p 5201

 

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

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

Чукча не читатель, чукча писатель? Никто не говорил о 250+250 дуплекса. Одновременный дуплексный тест дал 150+150 или около того. Загляните уже в тему, освежите память.

 

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

Поэтому ваши тесты , сделанные тогда ничего не показали и не  доказали.

"Ваши доказательства не доказательства"? Я же не отказывался от новых тестов, это вы куда-то пропали.

Давайте теперь я пропаду, оставив вам для размышления данные с теста iperf и скринов.

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

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

 

 

[slv700]

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

 

 

 

Что это за загрузка 450М? Опять встроенный тест? Или что? К чему это все ? Вам внятно сказали  какие  нужны тесты и аргументировано обьяснили почему именно такие тесты,а не другие?   Почему вы с такой настойчивостью пытаетесь  впарить всем  это г*но?