[linkodd]

Наткнулись на проблему, что радио в нв2 в одну сессию пропускает намного хуже,чем в нстрим. к примеру, сижу у абонента сегодня и вижу, что спидтест на тарифе до 12 мбит показывает 4-6 мбит. Бтест стабильно от 10-15 свободного канал показывает. Запускаю 3 спидтеста, скорость скачками доходит до 9 на РРТР интерфейсе клиента.

 

решаем перейти на нстрим, сходу пропустил 9 мбит трафика через спидтест.

 

прошивки 6.32.3

 

 

 

Кто ситуацию знает и как ее победил?

[Saab95]

Так вы пинг запустите в нстриме и в нв2, в первом будет 1мс, во втором около 4-5. Вот и ответ.

[linkodd]

ок...т.е. мне можно до 1мс уменьшить и скорость в одном потоке резко возрастет?

 

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

Edited November 19, 2015 by linkodd

[divxl]

ок...т.е. мне можно до 1мс уменьшить и скорость в одном потоке резко возрастет?

 

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

 

 

А как Вы трафик шейпите?

[linkodd]

централизованный узел в городе, далее тик, а в нем симпл квэнис и pcq в нем.

[slv700]

ок...т.е. мне можно до 1мс уменьшить и скорость в одном потоке резко возрастет?

 

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

Задержка здесь вообще не причем. Ситуация классическая, мною ( и не только ) описанная много раз. UDP трафик (тест) не учитывает ошибки в канале ( потери пакетов). На этом трафике нет ACKов, отправитель полностью загружает канал UDP пакетами, не ждет подтверждения успешной доставки пакетов( ACK). TCP пакеты имеют подтверждение доставки ACK, для этого требуется время ожидания ACK . Но главное, в случае потери или искажения пакетов, эти пакеты,а точнее вся пачка пакетов (TCP окно), где есть хотя бы один битый пакет, повторяется на передачу заново.

Тем самым, если в канале низкие потери- то UDP примерно равен TCP. Если много потерь - то разница может быть в разы. Спидтест.com - это TCP тест. Сделайте TCP тест микротиком BT, будет такая же цифра.

Увеличение количества потоков TCP догружает канал. Но правильное количество потоков TCP при тестировании канала 4-5 потоков. В тесте speedtest.com - 4 ( вроде бы) TCP потока. У TCP теста МТ по дефолту 20 TCP потоков, но это, в принципе, допустимо.

И надо иметь в виду, что реальный трафик -это преимущественно TCP/IP. Поэтому цифра скорости UDP на канале с большими потерями с точки зрения реальной скорости неинформативна.

И даже если трафик в канале преимущество UDP ( типа торрент), но есть потери, то обольщаться не стоит. Потерянные пакеты же по любому надо воcстанавливать ( повторной передачей). Причем в случае TCP/IP это делает IP роутер ( или сам торрент в случае UDP) , который может находиться очень далеко. Представляете себе, что этот например граничный маршрутизатор будет гонять повторными передачами весь битый трафик, который образовался из за какого то урода ( устройства) на одном из беспроводных фрагментов сети. А если это будет делать торрент для UDP трафика по всей сети , откуда идет закачка трафика?

Классическое проявление такого явления, это когда есть несколько пролетов каналов точка-точка. На каждом пролете скорость высокая, в том числе по TCP, а сквозная - низкая.

ЗЫ

А почему в Nstreme TCP скорость ( а значит и реальная ) выше чем Nv2 обьяснется очень просто. Потерь пакетов в Nstreme меньше чем в NV2, протокол Nstreme более надежный- обеспечивает более низкий PER/BER канала. Но вот что интересно и очень познавательно, измерив на Nv2 скорость UDP можно получить выше результат, чем Nstreme. Но это будет трюк, фуфел. Реальная скорость канала на Nstreme по описанной выше причине будет выше.

[Saab95]

ок...т.е. мне можно до 1мс уменьшить и скорость в одном потоке резко возрастет?

 

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

 

Так нужно поставить в шейпере буфер пакетов побольше, например 1000.

[TTvs]

Потерь пакетов в Nstreme меньше чем в NV2, протокол Nstreme более надежный- обеспечивает более низкий PER/BER канала.

Я отказался от Nstreme в пользу NV2, т.к. он у меня работает с большим кол-вом обрывов. Клиенты то отключаются, то подключаются. Скорости вообще никакие! NV2 работает месяцами. Так почему Nstreme более надёжный? Только из-за более низкого PER/BER канала?

[slv700]

Потерь пакетов в Nstreme меньше чем в NV2, протокол Nstreme более надежный- обеспечивает более низкий PER/BER канала.

Я отказался от Nstreme в пользу NV2, т.к. он у меня работает с большим кол-вом обрывов. Клиенты то отключаются, то подключаются. Скорости вообще никакие! NV2 работает месяцами. Так почему Nstreme более надёжный? Только из-за более низкого PER/BER канала?

У nstreme еcть свои недостатки. То что он обрывает сессию, то это может быть. И время аптайма -это не имеет отношения к надежности канала- PER/BER. Речь идет о том, что Nstreme пытается повторять передачу битых или потерянных пакетов до последнего, даже ценой увеличения задержки для всех остальных клиентов. Nv2 имеет свой тайминг, это не TDMA, но зачатки этого там есть. Если в течении какого то времени или попыток повторной передачи фрейм не восстановлен, то он дискардится- что дает потери на TCP уровне. В этом отношении Nstreme -более помехоустойчивый, чем Nv2.

Бывают случаи ( и их много) , когда Nv2 работает лучше Nstreme. Какого то определенного "железного" правила предпочтения того или иного протокола нет. ( Сааб может больше сказать в каких практических случаях cледует применять то или другое). Но вот PER/BER у Nstreme обычно ( но тоже не всегда) выше чем Nv2.

Вообще это относительно легко можно измерить утилитой тестирования канала IxChariot, там помимо прочего, измеряется packet loss, сразу все видно.

[linkodd]

ок...т.е. мне можно до 1мс уменьшить и скорость в одном потоке резко возрастет?

 

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

 

Так нужно поставить в шейпере буфер пакетов побольше, например 1000.

 

на 300-400 в онлайне в сегменте около 4000 очередей на каждый тариф..

и в тотал очереди дефолт_смол 10000 стоит...

 

помоему более чем достаточно.

[linkodd]

По поводу УДП тут я согласен и знаю это. Все тесты только tcp.

 

по вододу ошибок, количество посмотреть не знаю как на тике, но ССQ как правило ровный независимо от протокола и держится в диапазоне 90-100.

 

У спидтеста 1 сессия.

 

Бтестом проводил вчера тесты.

 

1) Нстрим в одним тсп поток грузит весь канал и если это 20мгц, то пропускает 30 мбит.

2) нв2 в 10мс пропускает 10-14 мбит.

3) нв2 в 2 мс пропускает 20-24 мбит.

 

 

НО! нстрим на 6.32.3 на стороне стэйшена либо отваливается(на одном из линков), либо канальная скорость прыгает с 65 до 6 мбит несколько раз в минуту и сразу возвращается на 65, хотя на тсп бтесте это никак не отображется.

 

Нстрим в 5.26 работает мегастабильно, но как обычно грузит проц.

 

 

П.с. вопрос не решен. что делать-то? ))

 

И еще, у нас все пролеты роутятся

[linkodd]

Кстати, если hw-retries в 15 поставить, оно будет больше пропускать в один поток?

[slv700]

И еще, у нас все пролеты роутятся

Вообще роутинг каждого пролета была вынужденная мера, которую начали применять в ШБД где то лет так 15 назад, чтобы повысить надежность сквозных линков , состоящих из нескольких ненадежных пролетов. Помогает и сейчас если линк на 802.11, убнт Airmax или МТ nv2. И практически это бесполезно, если линк на оборудовании с контролем уровня PER/BER,это как правило, или устройства TDMA типа Radwin, или любой Камбиум , или из не TDMA типа Infinet или Proxim. Возможно к таковым с большой натяжкой можно отнести и МТ Nstreme. Но в Nstreme задается степень агрегации пакетов Frame Policy и Frame Limit, от его значения при сильных помехах сильно зависит PER и скорость. Значение Nstreme Frame Limit 3200 байт при сильных помехах- много, оптимально при помехах( по опыту других систем) до 2048 байт. и похоже в Nv2 агрегированный фрейм вообще 4096 байт( точно не знаю). И для сравнения в Airmax A-MSDU фрейм 4096 байт, - точно. Видимо Nv2 и Airmax также по этой причине имеют более низкий PER. Попробуйте протестировать канал в nstreme пакетами TCP c разными значениями Frame Policy и Frame Limit. Интересно будет посмотреть.

 

но ССQ как правило ровный независимо от протокола и держится в диапазоне 90-100.

Это фуфел, малоинформативен. Понижается если уж очень плохи дела.

 

Кстати, если hw-retries в 15 поставить, оно будет больше пропускать в один поток?

Это в Nv2 ? Видимо, теоретически, да, но, опять же теоретически, ценой увеличения джиттера.

[linkodd]

в общем, потестируем. Есть несколько боевых линков ПТП. на неделе отпишусь по принципу ДО, порядок измений и ПОСЛЕ.

 

ретраи проверим, хотел еще поиграться с заданием уровня шума статически

[linkodd]

Но меня все же интересует момент с тем, что канальная скорость скачит на нстриме..

[Saab95]

1) Нстрим в одним тсп поток грузит весь канал и если это 20мгц, то пропускает 30 мбит.

2) нв2 в 10мс пропускает 10-14 мбит.

3) нв2 в 2 мс пропускает 20-24 мбит.

 

У вас проблема не с протоколом, а с радио, поэтому нужно решать проблему с радио, и только потом выбирать протокол, т.к. в нв2 с 10мс должны были получить выше скорость, чем с 2мс.

 

Вам нужно определить максимальные канальные скорости, на которых работает, тогда и CCQ будет под 100. Что бы получить помощь от коллективного разума, нужно приложить скрин с клиента окна Status беспроводного адаптера во время запуска к нему дуплексного теста со скоростью 5/5 мегабит.

[linkodd]

снял с реального линка

[Saab95]

снял с реального линка

 

Это не та картинка, которую нужно было показать. Заходите на клиента в раздел Wireless, нажимаете 2 раза мышкой по беспроводному адаптеру, заходите на вкладку Status.