slv700 Опубликовано 16 сентября, 2019 · Жалоба 1 час назад, xabarov сказал: Если при 20 потоках будет похожая цифра, то опять не признаете? :) Давайте не будем гадать. Дело не в количестве потоков. Просто ваш тест не является TCP. И если у вас якобы в одном TCP потоке 320 Mbps, то в 20 потоках точно хуже не будет. Сделайте тест TCP хоть в один поток ( тоже представляет интерес) , хоть в 5 , 10 , 20 или 50. Чем больше количество потоков, тем больше итоговая TCP скорость . Для TCP теста надежного канала достаточно 5 потоков и результат на 5, 10 и 20 потоках такого канала будет одинаков. Но вот для канала с потерями для получения скорости 300+ Mbps , 5-10 потоков может быть недостаточно. Но 20 хватит точно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Olejon Опубликовано 16 сентября, 2019 · Жалоба 12 минут назад, slv700 сказал: Cсылочку дайте пожалуйста ! Что то не припоминаю таких выкладок. А память у меня хорошая.:) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 16 сентября, 2019 · Жалоба Я эти тесты Хабарова отлично помню и принимал активное участие в их обсуждении. Итак, напомню , что вы 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) быть не могут, даже теоретически. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 17 сентября, 2019 · Жалоба 7 часов назад, slv700 сказал: Какая разница, видео, не видео? Делайте с самого начала правильные тесты, выкладывайте, будут замечания, разбирайтесь и при необходимости, корректируйте. Требования к тестам известны. А по скринам и без видео специалистам видны подтасовка и ошибки, если они были допущены. Хватит пустых слов. Сразу показывайте результаты правильных тестов. Нафиг нам видеть ваши тесты с 28% ошибок и верить вам на слово, что в других тестах все ОК? Никакой это у вас с массой ошибок в канале не предел, это тест вообще лишен смысла. Вы тестируете сферического коня в вакууме. Многие железки можно перегрузить трафиком раза в полтора больше, чем она может пропустить без ошибок и деградации задержки. правильные тесты делают прибором, требования и методика есть в rfc2544/6349, iperf может использоваться, но его данные так, для нормальных организаций пустой вывод, возьмите exfo или fluke и сделайте правильный тест на приборе сертифицированным под это Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 17 сентября, 2019 · Жалоба 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 придуман для тестирования проводных каналов. Ничего там практически полезного и особенностей для тестирования радио нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 17 сентября, 2019 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 17 сентября, 2019 · Жалоба 1 час назад, fractal сказал: нормальные операторы тестируют прибором согласно RFC - его специально придумали для стандартизации различных вещей, чтобы не было огородников которые живут в своем мирке и привносят свои правильные тесты, радио теми же приборами и тестируют, если для тебя это новость то поздравляю, бери, изучай! Я сам такие же типа RFC только для спецприменения и разрабатывал и использовал. SLA согласно RFC ? Чушь. Есть конкретное оборудование, конкретные линки, конкретный доступный нам инструментарий тестирования и методика тестирования, применимая для данного инструментария, без всякого малопригодного для наших задач RFC. Вот это и обсуждаем. Демагогии, росказней про держателей бизнесов, ничего этого не надо. Мы работаем с крупными ( типа федерального уровня) операторами. Так что все про все и SLA знаем. Это здесь ни к чему. Есть конкретные требования ( потребности) к каналам связи для провайдеров ( крупных и мелких, в том числе пионеров) и есть простые и доступные всем методы проверки выполнения этих требований. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 17 сентября, 2019 · Жалоба 1 час назад, slv700 сказал: Я сам такие же типа RFC только для спецприменения и разрабатывал и использовал. SLA согласно RFC ? Чушь. Есть конкретное оборудование, конкретные линки, конкретный доступный нам инструментарий тестирования и методика тестирования, применимая для данного инструментария, без всякого малопригодного для наших задач RFC. Вот это и обсуждаем. Демагогии, росказней про держателей бизнесов, ничего этого не надо. Мы работаем с крупными ( типа федерального уровня) операторами. Так что все про все и SLA знаем. Это здесь ни к чему. Есть конкретные требования ( потребности) к каналам связи для провайдеров ( крупных и мелких, в том числе пионеров) и есть простые и доступные всем методы проверки выполнения этих требований. давайте так, тендер, с определенным ТЗ, с определенным sla, клиенту делают канал, тестят iperf-ом, а клиент приходит и принимает канал с помощью fluke или exfo, канал не проходит его методику тестирования, что вы ему будете доказывать что это чушь? и так мерят крупняки, газпром, роснефть, алроса в России, так что... голословно так утверждать 1 час назад, slv700 сказал: Я сам такие же типа RFC только для спецприменения и разрабатывал и использовал. SLA согласно RFC ? Чушь. Есть конкретное оборудование, конкретные линки, конкретный доступный нам инструментарий тестирования и методика тестирования, применимая для данного инструментария, без всякого малопригодного для наших задач RFC. Вот это и обсуждаем. Демагогии, росказней про держателей бизнесов, ничего этого не надо. Мы работаем с крупными ( типа федерального уровня) операторами. Так что все про все и SLA знаем. Это здесь ни к чему. Есть конкретные требования ( потребности) к каналам связи для провайдеров ( крупных и мелких, в том числе пионеров) и есть простые и доступные всем методы проверки выполнения этих требований. с Orange работали? они так последнюю милю при аренде принимают, включая и радио Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chetkiyparen Опубликовано 17 сентября, 2019 · Жалоба В 16.09.2019 в 12:00, Bandit сказал: Ставьте ррл и будет счастье)) 38 ГГц вполне нормально на 2-4 км на 0.6 м А какие решения операторского линка возможны для расстояний 5-10км, чтобы получить 1гиг дуплекса и более? На каких частотах и какие ррл? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 17 сентября, 2019 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bandit Опубликовано 17 сентября, 2019 · Жалоба 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 МГц разные саббенд или частоты Речь про РФ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fractal Опубликовано 17 сентября, 2019 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cachua Опубликовано 17 сентября, 2019 · Жалоба 17 hours ago, slv700 said: От $20 тыс. Не, меньше раза в 2 :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Urs_ak Опубликовано 17 сентября, 2019 · Жалоба Мировой рекорд беспроводной передачи данных: 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. Просто :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Constantin Опубликовано 17 сентября, 2019 · Жалоба 2 минуты назад, Urs_ak сказал: Мировой рекорд беспроводной передачи данных: 40 Гбит/с на 11 километров а в чем проблема? 90 Ггц легко и на 13 км зацепиться и заработает, но доступность будет убогая, любой дождь и але улю, в ясную погоду проблем не будет. это только рекламная компания не более, ничего практического в этом нет. у ДОКа есть и в 40 ггц релейки но на 10+ км ничего не меняется, теже яйца только в профиль. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xabarov Опубликовано 17 сентября, 2019 · Жалоба 18 часов назад, slv700 сказал: Вы делали тесты и с перегрузом и без. Представляли интерес тесты без перегруза интерфейса, они были представлены. Сейчас этих тестов нет. Были бы -вам бы никто слова не сказал. Этих тестов нет, поскольку тема посвящена другому. После обработки всего материала выложу в существующей теме в полном объеме. 18 часов назад, slv700 сказал: Эти цифры ничего не значат. Они не могут нравиться или не нравиться, они просто ни о чем не говорят, окромя некомпетентности тестировщика. Еще раз спрошу - как вы это определили? 17 часов назад, slv700 сказал: Давайте не будем гадать. Дело не в количестве потоков. Просто ваш тест не является TCP. И если у вас якобы в одном TCP потоке 320 Mbps, то в 20 потоках точно хуже не будет. Повторили тест с 20-ю потоками, цифры получились немного больше. Есть смысл выкладывать скрины или опять обвините в некомпетентности тестировщика? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 17 сентября, 2019 · Жалоба 4 часа назад, xabarov сказал: Повторили тест с 20-ю потоками, цифры получились немного больше. Есть смысл выкладывать скрины или опять обвините в некомпетентности тестировщика? Меньше слов и обещаний. Выкладывайте фактурный материал. Будем смотреть, увидим ошибки, подскажем. Исправите, если что не так. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xabarov Опубликовано 17 сентября, 2019 · Жалоба 10 потоков ТСР iperf в одну сторону и 20 потоков ТСР ВТ в обратную (с ограничением 50М). На интерфейсе 350+60 Мбит/с (всего 410). С увеличением количества потоков увеличиваются потери и трафик подрастает незначительно. 50 Мбит/с в обратном канале - максимальное ограничение, при котором держится ~330 Мбит/с в прямом канале. Если увеличивать ограничение в обратном канале до 60-70-80-90-100, то скорость в прямом канале пропорционально снижается 310-300-290 и так далее. В UDP BT такой проблемы нет - там полностью утилизируется весь доступный капасити с потерями и если ограничить 100/340 - без потерь совсем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 17 сентября, 2019 · Жалоба Итак, 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 % потерь- кусок говна в бочке меда, превращающее все результаты в бочку говна. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xabarov Опубликовано 18 сентября, 2019 · Жалоба 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" :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 19 сентября, 2019 · Жалоба 11 часов назад, xabarov сказал: Уровень помех до -80 и напомню - в ближней зоне есть обильная листва, которая очень близко в зоне Френеля, не перекрывает прямую видимость. Плюс половина линка над водой. При сигнале -42 дБм CINR будет 38 дБ. Этого достаточно для 256QAM 5/6. 11 часов назад, xabarov сказал: По-моему тут никто не сранивал с вашим форсом. Вы "Поле чудес" насмотрелись? "Пользуясь случаем, хочу передать привет прорекламировать Cambium" :) Конечно любой продукт сравнивается с альтернативными решениями. И это правильно. Все познается в сравнении. И мы все всегда все сравниваем и в профильных для оборудования темах и здесь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 19 сентября, 2019 · Жалоба 12 часов назад, xabarov сказал: Мне вот интересно - в своих тестах вы берете максимальные цифры с интерфейса микротика (например тут), в моих тестах - минимальные с графика. Что за двойные стандарты? В TCP тестах для оценки пропускной способности берется ( в том числе в моих тестах ) обязательно нагрузка TCP тестера ( ipref и BT MT). Если есть живой трафик, то снимается нагрузка с интерфейса. Но только в TCP тестах. Но это будет несколько искаженный результат. В UDP тестах можно брать цифры и с генератора тестов и с интерфейса. Цель UDP тестов- оценить максимальные возможности канала , которая никогда на реальном линке не будет достигнута. При этом желательно видеть обе цифры и с интерфейса и с генератора тестов , для сравнения с TCP. Что есть в моих тестах. Если сравнить цифры трафика UDP генератора тестов и нагрузки интерфейса, на интерфейсе она выше ( примерно на 10-15% ), особенно в пиках, за счет служебного трафика и потерь ( для UDP) , поэтому и нужно показывать график загрузки интерфейса, чтобы была видна средняя цифра. И она по любому в UDP будет выше, чем трафик генератора тестов. В TCP тестах средние значения трафика с генератора тестов и с интерфейса обычно близки. Но в пиках может быть существенная разница. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 19 сентября, 2019 · Жалоба 12 часов назад, xabarov сказал: Плюс половина линка над водой Потери 2 % могут быть от переотражений от воды. Попробуйте уменьшить мощность Tx. 12 часов назад, xabarov сказал: Если скажете как в iperf ограничить скорость - попробую выловить вариант без потерь. Шейп поставьте на роутере в DL. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Olejon Опубликовано 19 сентября, 2019 · Жалоба В 18.09.2019 в 22:11, xabarov сказал: Если скажете как в iperf ограничить скорость - попробую выловить вариант без потерь. Вроде вот, при включении, потерь нет и пинг 20...40 когда канал в 100% Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SSD Опубликовано 20 сентября, 2019 · Жалоба 20 часов назад, slv700 сказал: Конечно любой продукт сравнивается с альтернативными решениями. И это правильно. Все познается в сравнении. И мы все всегда все сравниваем и в профильных для оборудования темах и здесь. Все твои сравнения и тесты однобоки, там все подгоняется под единственную цель. Выставить камбиум в выгодном свете + попутно налить грязи на конкурентов. Ты о себе уже в третьем лице? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...