nanobeam vs nano bridge

[keep3r]

Что лучше на 5км и на 10км?

[xabarov]

Одинаково, только бим собирается проще и может работать на более высоких скоростях из-за гигабитного порта. Если не планируете гонять трафик больше 100 мбит - бриджа хватит.

 

Вот кстати тема по бимам:

http://forum.nag.ru/forum/index.php?showtopic=93182

[keep3r]

На бриджах м2 20дб на 2 км поднялось по 150 на канал,но на спидтесте 55 загрузка а 40 отдача....

[xabarov]

На бриджах м2 20дб на 2 км поднялось по 150 на канал,но на спидтесте 55 загрузка а 40 отдача....

Какая была полоса? 20 дБ - имеете ввиду выходную мощность?

[keep3r]

40мг полоса....мощность убавил до 14 дб....макс там вообще был 28...получилась хорошая середина. Агрегацию менял на 8-8000, шум -96 помоему был.....я теперь думаю хватит ли гридов на 10 км или лучше бимы, прямая видимость есть(только что заметил что шапку не так сделал, не бриджи а гриды блин)

[kayot]

На бриджах м2 20дб на 2 км поднялось по 150 на канал,но на спидтесте 55 загрузка а 40 отдача....

wi-fi девайсы N-стандарта нельзя тестировать спидтестом в силу его однопоточности. Iperf в 10 потоков показал бы вам 100/100, как и любой реальный трафик(если конечно специально не ложить 64 байт пакетами).

[Saab95]

wi-fi девайсы N-стандарта нельзя тестировать спидтестом в силу его однопоточности. Iperf в 10 потоков показал бы вам 100/100, как и любой реальный трафик(если конечно специально не ложить 64 байт пакетами).

 

Где вы видели однопоточность на спидтесте? Бывает просто сам комп, с которого запускают тест не тянет больше, особенно касается дешевых/старых ноутбуков. Хотя может быть виноват и убнт - для спидтеста важна постоянная и минимальная задержка, а так же отсутствие потери пакетов. УБНТ не может поддерживать в радио требуемые параметры, вот скорость и падает. Попробуйте параллельно с запуском теста, запустить и пинг пакетами 1500 байт с интервалом 100мс.

[slv700]

wi-fi девайсы N-стандарта нельзя тестировать спидтестом в силу его однопоточности. Iperf в 10 потоков показал бы вам 100/100, как и любой реальный трафик(если конечно специально не ложить 64 байт пакетами).

Дело не спидтесте ( там несколько потоков), а в той самой пресловутой агрегации 802.11n. Пакеты МАC уровня нескольких потоков TCP не могут заполнить весь агрегированный фрейм 4K и суперфрейм 64K и поэтому скорость низкая. Это было замечено с момента появления 802.11n, и в том числе, первых образцов убнт 802.11n. Прочитайте их форум тех времен, их суппорт обьяснял этот "феномен" именно так, как сказано, и советовал в тестах увеличивать количество потоков На оборудовании без агрегации max скорость достигается на 5 потоках TCP.

Данный "феномен" проявляется на реальном трафике в малтипойнт, когда фреймы 802.11n A-MPDU, A-MSDU на клиентов не успевают полностью паковаться пакетами MAC уровня. В этом и есть причина низкой пропускной способности 802.11n ( включая убнт, мт) в малтипойнт.

Что касается низких показателей спидтеста ( пакеты TCP), то если есть потери TCP пакетов то уменьшается окно стека протокола TCP( количество пакетов TCP передаваемой в одной пачке на L3 уровне ). Чем больше передается пакетов в пачке- тем больше скорость. Если найдена ошибка хотя бы в одном пакете стек уменьшается и повторяет передачу пачки. Если не найдена ошибка- стек увеличивается для следующей передачи. Поэтому при низкой надежности канала трафик все время плывет. Следует добавить, что обнаружить ошибку в пакетах TCP может только роутер и терминальное устройство. Так что пакеты могут теряться далеко в сети на каком нибудь пролете например, на нанобридже,потери обнаруживаться на маршрутизаторе например ,на оптической магистрали входа в Интернет, а трафик плыть совсем на другом линке , например, на нанобиме.