[slv700]

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

Если при 20 потоках будет похожая цифра, то опять не признаете? :)

Давайте не будем гадать. Дело не в количестве потоков. Просто ваш тест не является TCP. И если у вас якобы в одном TCP потоке 320 Mbps, то в 20 потоках точно хуже не будет.

Сделайте  тест TCP хоть в один поток ( тоже представляет интерес) , хоть в 5 , 10 ,  20  или 50.    Чем больше количество потоков, тем больше итоговая TCP  скорость . Для  TCP теста  надежного канала   достаточно 5 потоков и результат на 5, 10 и 20 потоках такого канала будет одинаков. Но вот для канала с потерями  для получения скорости 300+ Mbps , 5-10 потоков может быть недостаточно. Но 20 хватит точно.

[Olejon]

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

Cсылочку дайте пожалуйста ! Что то не припоминаю таких выкладок. А память у меня хорошая.:)

 

[slv700]

Я эти тесты Хабарова отлично помню и принимал активное участие в их обсуждении.

Итак, напомню , что вы Olejon  сказали выше. 

да что там... у AF-5X и им подобные если пишет 300 мегабит, то там 300 мегабит ТСР и есть

Сколько пишет столько и есть, але, тут не однократно выкладывали...

 

Что показали тесты по данной вами ссылке.

Канал 50 Мгц.

Дуплексные тесты в UDP (Duty Cycle 75%):

Ограничение трафика 70 + 240 - средняя задержка 1 мс без потерь

уплексные тесты в TCP (Duty Cycle 75%):

Ограничение трафика 55 + 163 - средняя задержка 3 мс без потерь

 При этом Сapacity  на трафике TCP пишет 244+72 Mbps. 

А на UDP 266+79 Mbps.

И что  Olejon совпадает то, что пишет Capacity c  TCP тестом? Нет. Так зачем же вы лжете?

Чуть позже xabarovу  удалось вытянуть в 40 Мгц

TCP Duplex (с ограничением 36М или 1 к 5) - стабильно ~185M + 40M (суммарный трафик 225M) с средней задержкой 4 мс БЕЗ ПОТЕРЬ

Duplex (с ограничением 18М или 1 к 10) - стабильно ~185M + 23M (суммарный трафик 208M) с средней задержкой 3 мс БЕЗ ПОТЕРЬ

При этом Capacity 195 +60 Mbps. Опять нет совпадения.

ЗЫ

Почему результат в 40  МГц получился лучше чем в 50 Мгц ?  И резульат TCP  ближе к UDP и Capacity. Потому что в 40 Мгц меньше помех и меньше потерь. Поэтому TCP выше.   То есть по разнице между UDP и TCP можно судить о надежности канала. Чем она меньше, тем надежней канал. Но быть одинаковыми TCP и UDP ( который у  AF близок к Capacity)  быть не могут, даже теоретически.

[fractal]

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

Какая разница, видео, не видео?  Делайте  с самого начала правильные тесты, выкладывайте, будут замечания, разбирайтесь и при необходимости, корректируйте.  Требования к тестам известны. А по скринам и без видео специалистам видны  подтасовка и ошибки, если они были допущены.  

 

Хватит пустых слов.  Сразу показывайте  результаты правильных тестов. Нафиг  нам видеть ваши тесты с 28% ошибок и верить вам на слово, что в других тестах все ОК? Никакой это у вас  с массой ошибок в канале  не предел, это тест  вообще лишен смысла.  Вы тестируете сферического коня в вакууме.  Многие  железки можно перегрузить трафиком раза в полтора больше, чем она может пропустить  без ошибок  и  деградации  задержки.

 правильные тесты делают прибором, требования и методика есть в rfc2544/6349, iperf может использоваться, но его данные так, для нормальных организаций пустой вывод, возьмите exfo или fluke и сделайте правильный тест на приборе сертифицированным под это

[slv700]

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

сть в rfc2544/6349, iperf может использоваться, но его данные так, для нормальных организаций пустой вывод, возьмите exfo или fluke и сделайте правильный тест на приборе сертифицированным под это

Ты сам то читал rfc2544/6349?  Правильный тест для нормальных организаций?  Идиотизм.

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

iperf может использоваться, но его данные так, для нормальных организаций пустой вывод,

Это для твоей пустой головы это пустой вывод.  Нормальные организации тестируют и Iperf, ixChariot (и программными и аппаратными средствами) и BT Mikrotik и  др.   Потоки E1 тестируют специализированными приборами, фиксирующими  количество и тип ошибок в потоках  E1 в проводных и радиоканалах .  Аппаратные средства тоже применяются для тестирования радио. Но не применяются в лоб устройства  для тестирования  кабельных сетей для тестирования радиоканалов - у каналов  разные BER и задержки. Как минимум у правильных аппаратных устройств должны быть настройки для  тестирования той или иной среды передачи данных. Ну нельзя например Ethernet Tester ( Packet Expert )  тестить радиоканал. Получите неадекватную херню. То же самое касается EXFO . По крайней мере возможно там есть модели и для радио ( или соответствующие настройки) , но вот взять тупо устройство для тестирования кабельной  ЛВС , позволяющие снять параметры  сети согласно RFC и применять для радио- это глупость.  Это точно также как взять, например , E1 мультиплексор ( не TDM/ IP)  для кабельных каналов и использовать его в IP сети, да еще в  радиоканале. 

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

[fractal]

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

Ты сам то читал rfc2544/6349?  Правильный тест для нормальных организаций?  Идиотизм.

Это для твоей пустой головы это пустой вывод.  Нормальные организации тестируют и Iperf, ixChariot (и программными и аппаратными средствами) и BT Mikrotik и  др.   Потоки E1 тестируют специализированными приборами, фиксирующими  количество и тип ошибок в потоках  E1 в проводных и радиоканалах .  Аппаратные средства тоже применяются для тестирования радио. Но не применяются в лоб устройства  для тестирования  кабельных сетей для тестирования радиоканалов - у каналов  разные BER и задержки. Как минимум у правильных аппаратных устройств должны быть настройки для  тестирования той или иной среды передачи данных. Ну нельзя например Ethernet Tester ( Packet Expert )  тестить радиоканал. Получите неадекватную херню. То же самое касается EXFO . По крайней мере возможно там есть модели и для радио ( или соответствующие настройки) , но вот взять тупо устройство для тестирования кабельной  ЛВС , позволяющие снять параметры  сети согласно RFC и применять для радио- это глупость.  Это точно также как взять, например , E1 мультиплексор ( не TDM/ IP)  для кабельных каналов и использовать его в IP сети, да еще в  радиоканале. 

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

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

Изменено 17 сентября, 2019 пользователем fractal

[slv700]

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

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

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

 SLA  согласно RFC ?  Чушь.

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

Вот это и обсуждаем. Демагогии, росказней про держателей бизнесов, ничего этого не надо. Мы работаем  с крупными ( типа федерального уровня) операторами. Так что все про все и SLA знаем. Это здесь  ни к чему. Есть конкретные требования  ( потребности) к каналам связи для провайдеров  ( крупных и мелких, в том числе пионеров) и есть  простые и доступные всем методы проверки выполнения этих требований. 

[fractal]

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

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

 SLA  согласно RFC ?  Чушь.

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

Вот это и обсуждаем. Демагогии, росказней про держателей бизнесов, ничего этого не надо. Мы работаем  с крупными ( типа федерального уровня) операторами. Так что все про все и SLA знаем. Это здесь  ни к чему. Есть конкретные требования  ( потребности) к каналам связи для провайдеров  ( крупных и мелких, в том числе пионеров) и есть  простые и доступные всем методы проверки выполнения этих требований. 

давайте так, тендер, с определенным ТЗ, с определенным sla, клиенту делают канал, тестят iperf-ом, а клиент приходит и принимает канал с помощью fluke или exfo, канал не проходит его методику тестирования, что вы ему будете доказывать что это чушь? и так мерят крупняки, газпром, роснефть, алроса в России, так что... голословно так утверждать

 

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

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

 SLA  согласно RFC ?  Чушь.

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

Вот это и обсуждаем. Демагогии, росказней про держателей бизнесов, ничего этого не надо. Мы работаем  с крупными ( типа федерального уровня) операторами. Так что все про все и SLA знаем. Это здесь  ни к чему. Есть конкретные требования  ( потребности) к каналам связи для провайдеров  ( крупных и мелких, в том числе пионеров) и есть  простые и доступные всем методы проверки выполнения этих требований. 

с Orange работали? они так последнюю милю при аренде принимают, включая и радио

[chetkiyparen]

В 16.09.2019 в 12:00, Bandit сказал:

Ставьте ррл и будет счастье)) 38 ГГц вполне нормально на 2-4 км на 0.6 м

А какие решения операторского линка возможны для расстояний 5-10км, чтобы получить 1гиг дуплекса и более? На каких частотах и какие ррл?

[fractal]

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

А какие решения операторского линка возможны для расстояний 5-10км, чтобы получить 1гиг дуплекса и более? На каких частотах и какие ррл?

https://leo.ru/catalog/sistemy/sistemy-peredachi-dannykh/rrl/dragonwave/harmony-radio/ - старая

 

https://www.dragonwavex.com/products/packet-microwave/harmony-enhanced

https://www.dragonwavex.com/products/packet-microwave/harmony-enhancedmc

 

[Bandit]

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

А какие решения операторского линка возможны для расстояний 5-10км, чтобы получить 1гиг дуплекса и более? На каких частотах и какие ррл?

Частоты 13/15/18/23 на такие расстояния, режим 2+0 это будет 485*2 Мбит это из бюджетных средств которые разгоняют до 2048 куам, если 4096 но там цена иначе в большую сторону

 

Если нужно именно больше гига то 2+0 + 1+0 

 

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

https://leo.ru/catalog/sistemy/sistemy-peredachi-dannykh/rrl/dragonwave/harmony-radio/ - старая

 

https://www.dragonwavex.com/products/packet-microwave/harmony-enhanced

https://www.dragonwavex.com/products/packet-microwave/harmony-enhancedmc

 

Какач цена на гиг будет?

 

И не забываем что 112 МГц не выдают полосу, только брать 56 МГц разные саббенд или частоты

 

Речь про РФ

[fractal]

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

Частоты 13/15/18/23 на такие расстояния, режим 2+0 это будет 485*2 Мбит это из бюджетных средств которые разгоняют до 2048 куам, если 4096 но там цена иначе в большую сторону

 

Если нужно именно больше гига то 2+0 + 1+0 

 

Какач цена на гиг будет?

не помню точную модель, но был dragonwave года 3 назад который мог 900 передавать дуплексом, вроде около 500т.р. за пролет, по новым не подскажу даже, частоты 21-23 (а ну да, походу это он https://leo.ru/catalog/sistemy/sistemy-peredachi-dannykh/rrl/dragonwave/harmony-radio/)

 

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

Частоты 13/15/18/23 на такие расстояния, режим 2+0 это будет 485*2 Мбит это из бюджетных средств которые разгоняют до 2048 куам, если 4096 но там цена иначе в большую сторону

 

Если нужно именно больше гига то 2+0 + 1+0 

 

Какач цена на гиг будет?

 

И не забываем что 112 МГц не выдают полосу, только брать 56 МГц разные саббенд или частоты

 

Речь про РФ

да, 112 редко дают, хотя в Сибири давали и на ДВ

Изменено 17 сентября, 2019 пользователем fractal

[cachua]

17 hours ago, slv700 said:

От $20 тыс. 

Не, меньше раза в 2 :)

[Urs_ak]

Мировой рекорд беспроводной передачи данных: 40 Гбит/с на 11 километров

https://habr.com/ru/post/467753/

 

Цитата

 

В августе 2019 года в России впервые в мире (Да, это правда) выполнили коммерческий проект по беспроводному резервированию магистрального оптического кабеля емкостью 40 Гбит/с. Оператор «Единство», дочерняя компания Норникеля, с помощью такого канала пробросила 11-километровый беспроводной бэкап через Енисей. 

...

Вызов принял отечественный разработчик из Санкт-Петербурга — компания ДОК. У нее уже были разработки радиомостов, которые обеспечивали необходимую дальность. А перед этим проектом они протестировали канал 40 Гбит/c в виде 4-х совместно работающих радиомостов по 10 Гбит/c на своем 4 км — полигоне, и были уверены, что такую емкость получить возможно. Но на практике, никто никогда в телекоммуникационной индустрии не пробовал поставить вместе 4 параллельно работающих радиомоста по 10 Гбит/c на дистанции 11 км. 

 

 

Цитата

8) Не уж то нет просадок совсем? Никогда-никогда? Мне, например, интересно
Просадки ессно есть при дожде. Главное, чтобы до обрыва не падало. Но на северах 9 месяцев в году идет снег, который радиопрозрачен. Статистику имеет только админ линка, она непубличная. Обычно ниже QAM 16 (5.4 Гбит/с) не падает.

 

P.S. Просто :)

[Constantin]

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

Мировой рекорд беспроводной передачи данных: 40 Гбит/с на 11 километров

а в чем проблема? 90 Ггц  легко и на 13 км зацепиться и заработает, но доступность будет убогая, любой дождь и але улю, в ясную погоду проблем не будет.

 

это только рекламная компания не более, ничего практического в этом нет.

 

у ДОКа есть и в 40 ггц релейки но на 10+ км ничего не меняется,  теже яйца только в профиль.

 

[xabarov]

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

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

Сейчас этих тестов нет. Были бы -вам бы никто слова не сказал.

Этих тестов нет, поскольку тема посвящена другому. После обработки всего материала выложу в существующей теме в полном объеме.

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

Эти цифры ничего не значат. Они не могут нравиться или не нравиться, они просто ни о чем не говорят, окромя некомпетентности  тестировщика.

Еще раз спрошу - как вы это определили?

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

Давайте не будем гадать. Дело не в количестве потоков. Просто ваш тест не является TCP. И если у вас якобы в одном TCP потоке 320 Mbps, то в 20 потоках точно хуже не будет.

Повторили тест с 20-ю потоками, цифры получились немного больше. Есть смысл выкладывать скрины или опять обвините в некомпетентности тестировщика?

[slv700]

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

Повторили тест с 20-ю потоками, цифры получились немного больше. Есть смысл выкладывать скрины или опять обвините в некомпетентности тестировщика?

Меньше слов и обещаний. Выкладывайте фактурный материал. Будем смотреть, увидим ошибки, подскажем. Исправите, если что не так.

[xabarov]

10 потоков ТСР iperf в одну сторону и 20 потоков ТСР ВТ в обратную (с ограничением 50М). На интерфейсе 350+60 Мбит/с (всего 410). С увеличением количества потоков увеличиваются потери и трафик подрастает незначительно.

 

50 Мбит/с в обратном канале - максимальное ограничение, при котором держится ~330 Мбит/с в прямом канале. Если увеличивать ограничение в обратном канале до 60-70-80-90-100, то скорость в прямом канале пропорционально снижается 310-300-290 и так далее.

 

В UDP BT такой проблемы нет - там полностью утилизируется весь доступный капасити с потерями и если ограничить 100/340 - без потерь совсем.

[slv700]

 Итак, IMHO  все сделано правильно. Вопрос только один- видим 2 % потерь коротких пингов, это недопустимые потери.

Результат AF5x,  дальность 3 км LOS,  антенны 30 дБи. Помех или нет, или если даже есть, но они полностью подавлены мощным сигналом RSSI -42 dBm .

TCP Download 330Mbps + Upload 50 Mbps= 380 Mbps DL+UL в 50 Мгц. Задержка avg 5 ms, потери  пингов  длиной 64 байта -2%.

Соответственно в 40 МГц  будем иметь 265Mbps+ 40 Mbps =305 Mbps.

Capacity  в 50 МГц= 350+115 Mbps=465Mbps. Реальная скорость намного меньше.

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

PS

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

Хотелось бы увидеть работу AF5x на большей дальности, скажем на 10-15 км.

 На большей дальности 10+ км , более низком сигнале и высоких помехах ( меньше CINR ) результат будет очевидно хуже.  И конечно интересует работа AF5x HD.

И если мы сравниваем с Cambium Force 300 CSM,   то он  выдает  на дальности 10 км , антенны 30 дБи ,  в присутствии  сильных помех,  в 40 МГц  TCP 290 Mbps UL+DL.  Результат выложен в профильной теме Force 300 CSM.

В режиме ePTP результат  в 40 МГц примерно TCP 270+30 Mbps ( что почти одинаково  c AF5x).  В 80 МГц  > TCP 500  Mbps . Тесты в режиме ePTP выложим  позже в профильной теме.

PS2

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

Тогда полученный результат можно будет зафиксировать и использовать как референсный для AF5x. Потому что 2 % потерь- кусок говна в бочке меда, превращающее все результаты  в бочку говна. :)

 

 

[xabarov]

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

Вопрос только один- видим 2 % потерь коротких пингов, это недопустимые потери.

Если скажете как в iperf ограничить скорость - попробую выловить вариант без потерь.

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

Помех или нет, или если даже есть, но они полностью подавлены мощным сигналом RSSI -42 dBm .

Уровень помех до -80 и напомню - в ближней зоне есть обильная листва, которая очень близко в зоне Френеля, не перекрывает прямую видимость. Плюс половина линка над водой. Позже выложу подробный отчет в теме про AF-5X.

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

TCP Download 330Mbps + Upload 50 Mbps= 380 Mbps DL+UL в 50 Мгц

Мне вот интересно - в своих тестах вы берете максимальные цифры с интерфейса микротика (например тут), в моих тестах - минимальные с графика. Что за двойные стандарты?

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

Хотелось бы увидеть работу AF5x на большей дальности, скажем на 10-15 км.

 

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

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

И если мы сравниваем с Cambium Force 300 CSM

По-моему тут никто не сранивал с вашим форсом. Вы "Поле чудес" насмотрелись? "Пользуясь случаем, хочу передать привет прорекламировать Cambium" :)

[slv700]

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

Уровень помех до -80 и напомню - в ближней зоне есть обильная листва, которая очень близко в зоне Френеля, не перекрывает прямую видимость. Плюс половина линка над водой.

При сигнале -42 дБм CINR  будет 38 дБ. Этого достаточно для 256QAM 5/6. 

 

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

По-моему тут никто не сранивал с вашим форсом. Вы "Поле чудес" насмотрелись? "Пользуясь случаем, хочу передать привет прорекламировать Cambium" :)

Конечно любой продукт сравнивается с альтернативными решениями. И это правильно. Все познается в сравнении. 

И мы все всегда все сравниваем и в профильных для оборудования темах и здесь.

[slv700]

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

Мне вот интересно - в своих тестах вы берете максимальные цифры с интерфейса микротика (например тут), в моих тестах - минимальные с графика. Что за двойные стандарты?

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

В UDP тестах можно брать цифры и с генератора тестов и с интерфейса.   Цель UDP тестов- оценить максимальные возможности канала , которая никогда на реальном линке не будет достигнута.  При этом желательно видеть обе цифры  и   с интерфейса  и с генератора тестов ,  для сравнения с TCP. Что есть  в моих тестах. 

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

 

[slv700]

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

Плюс половина линка над водой

Потери 2 % могут быть от переотражений от воды.  Попробуйте уменьшить мощность Tx. 

 

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

Если скажете как в iperf ограничить скорость - попробую выловить вариант без потерь.

Шейп поставьте на роутере в DL.

[Olejon]

В 18.09.2019 в 22:11, xabarov сказал:

Если скажете как в iperf ограничить скорость - попробую выловить вариант без потерь.

Вроде вот, при включении, потерь нет и пинг 20...40 когда канал в 100%

[SSD]

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

Конечно любой продукт сравнивается с альтернативными решениями. И это правильно. Все познается в сравнении. 

И мы все всегда все сравниваем и в профильных для оборудования темах и здесь.

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

 

Ты о себе уже в третьем лице?