[bezhetsk]

Есть необходимость в высокопроизводительном линке на 1 км, будет работать в качестве бэкапа оптики и должен обеспечить скорость до 250 мегабит. Рассматриваются варианты Микротик SXT HG5 ac http://routerboard.com/RBSXTG-5HPacD-HG и Ubiquiti NanoBeam 5AC-19. Что можете посоветовать?

[Danila]

Есть необходимость в высокопроизводительном линке на 1 км, будет работать в качестве бэкапа оптики и должен обеспечить скорость до 250 мегабит. Рассматриваются варианты Микротик SXT HG5 ac http://routerboard.c...BSXTG-5HPacD-HG и Ubiquiti NanoBeam 5AC-19. Что можете посоветовать?

Может в сторону Siklu посмотришь?

[bezhetsk]

 

Может в сторону Siklu посмотришь?

Там цена вопроса слишком высока. Все-таки бэкап, 99 процентов времени будет простаивать.

[NewUse]

ЭирФибер24

[bezhetsk]

ЭирФибер24

Фибер 24 отличная штука, стоит на бэкапе на 5 км, от оптики ничем не отличается. Ну только если очень сильный дождь, то канал падает. Но тут 1 км, хочется вариант подешевле. Вот и не знаю что выбрать UBNT или микротик для этой задачи.

[NewUse]

МТ АЦ не работает, по крайней мере работает значительно хуже ЮБНТ, неоднократно писали, хотя может уже что и поменялось...

Но стабильные 250МБит на АЦ -- есть сомнения.

Подешевле, но с нормальным качеством, будет разве что ЭирФибер 5х, но в 5ГГц если засрано -- не поможет....

[dsk]

Пару убиков АЦ влепить в езерченнеле. Для бэкапа в принципе хватит.

[head]

Аолс лантастика ас3

[Negator]

А что в линек бегает? Какой pps? Можно подробнее?

[bezhetsk]

А что в линек бегает? Какой pps? Можно подробнее?

там 200 юзеров pps большой.

[MaXToP]

для того, чтобы на AC получить приемлемые скорости у вас в эфире должно быть свободно 80Мгц, иначе смысла перед обычными N ками нет

[[anp/hsw]]

на rocketAC lite 4км линк дает в 40мгц 230 мегабит, capacity при этом показывает 260. в 80мгц помню тест гонял, там было явно больше, около 400, но живого трафика у меня столько в ту сторону нет, чтобы проверить.

N в тех же условиях давал 180 на полосе 40мгц.

[slv700]

' timestamp='1444195719' post='1183941']

на rocketAC lite 4км линк дает в 40мгц 230 мегабит, capacity при этом показывает 260. в 80мгц помню тест гонял, там было явно больше, около 400, но живого трафика у меня столько в ту сторону нет, чтобы проверить.

N в тех же условиях давал 180 на полосе 40мгц.

Да ни хрена он не дает 230Mв 40 Мгц на 4 км( 260М -это теоретический макcимум на 256QAM 5/6), может показывать это только на своем внутреннем UDP симплексном тесте и БЕЗ ПОМЕХ. Хватит морочить людям голову этим убнт АС. В подтверждение своих слов выкладывайте результаты ( скрины) дуплексного TCP теста в 5 потоков или OOKLA speedtest.net ( симплексный TCP тест в 4 потока), потому что все сказанное про работу убнт вообще и АС в частности без доказательств ( экспертизы) -это все фуфло.

[[anp/hsw]]

ох, как у вас пылает.

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

 

[slv700]

' timestamp='1444208323' post='1184072']

ох, как у вас пылает.

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

 

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

Ваш встроенный тест неадекватен, он мало о чем говорит , поскольку не учитывает потери пакетов в канале. А потери у вас в канале есть и их много, поскольку модуляция QAM256 5/6 поднята на CINR 31 dB ( local constellation diagram) и вы это увидете при встречном ( дуплексном ) трафике, когда загруженный upload канал будет терять ACK download трафика и этим деградировать download. CINR 32 dB в download также недостаточен , нужен как минимум 34dB+ 3-5 dB fage margin. Недостаток DL CINR также дает вам потери пакетов в download ( что вы не видите встроенным тестом). Протестите канал TCP дуплексным ( пусть несимметричным) трафиком и сразу все увидете сами.

[[anp/hsw]]

поскольку не учитывает потери пакетов в канале.

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

 

да, прямая полоса на графике это не полка по трафику (ну не может же прием быть больше, чем генерируется на той стороне :)

это полка по cpu. httpd в этот момент витает где-то в облаках, и не успевает отдать данные до таймаута, поэтому график рисует последнее полученое значение где-то в районе старта.

на дуплексном тесте хорошо видно, что если до таких скоростей не доводить, то данные в рисовалку графика успевают попадать (в прошивке 7.1.4 возможно пофикшено, надо проверить)

[slv700]

' timestamp='1444214263' post='1184146']

поскольку не учитывает потери пакетов в канале.

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

 

да, прямая полоса на графике это не полка по трафику (ну не может же прием быть больше, чем генерируется на той стороне :)

это полка по cpu. httpd в этот момент витает где-то в облаках, и не успевает отдать данные до таймаута, поэтому график рисует последнее полученое значение где-то в районе старта.

на дуплексном тесте хорошо видно, что если до таких скоростей не доводить, то данные в рисовалку графика успевают попадать (в прошивке 7.1.4 возможно пофикшено, надо проверить)

Неужели вам нужно обьснять, что пакеты могут не только теряться , но и "долетать" до адресата битыми, что контролирутся CRC и какой конкретно битый пакет в агрегированом фрейме указыается в групповом ACK? Тестируйте канал на убнт пакетами TCP,поскольку тесты UDP ( встроенный тест убнт) , у которых вообще нет ACK для системы с высоким PER/BER ( что есть убнт АС) неадекватны.

И посмотрите, у вас помеха с одной стороны -82 dBm c CINR 30 dBm. Этот канал может без потерь работать только на 64QAM 5/6, как простой N.

[[anp/hsw]]

Неужели вам нужно обьснять, что пакеты могут не только теряться , но и "долетать" до адресата битыми, что контролирутся CRC и какой конкретно битый пакет в агрегированом фрейме указыается в групповом ACK?

Неужели вам нужно объяснять, что в статистику такие битые пакеты не попадают? Они попадают в счетчик "dropeed" на интерфейсе, и не более того.

Еще раз: пакеты на L3 дошли в нужном количестве. Зачем ковырять низлежащие уровни модели OSI? Потешить свое самолюбие?

 

И посмотрите, у вас помеха с одной стороны -82 dBm c CINR 30 dBm. Этот канал может без потерь работать только на 64QAM 5/6, как простой N.

ВОт и я думаю, что CINR в теории недостаточен. Но раз на практике работает, что теперь сделаешь? К тому же возможно калибровка несколько неправильна, это же не измерительный прибор, разброс +/- 2-4дб не редкость.

 

Тестируйте канал на убнт пакетами TCP

Гоните быстро и решительно опции iperf (как сервера, так и клиента), чтобы потом не съезжать с темы, и я их для вас проделаю.

[slv700]

' timestamp='1444220973' post=1184224]

Но раз на практике работает, что теперь сделаешь?

Зачем ковырять низлежащие уровни модели OSI? Потешить свое самолюбие?

Что делать? Тестировать линк трафиком L3, у которого есть ACK, а именно TCP. Такой тест и покажет все реальные потери на L1 и L2 и какая будет скорость живого трафика TCP/IP на L3/L4 без учета ограничений по ппс.

[[anp/hsw]]

Такой тест и покажет все реальные потери на L1 и L2 и какая будет скорость живого трафика TCP/IP на L3/L4 без учета ограничений по ппс.

ну так давайте давайте сюда уже опции iperf для клиента и сервера в соответствии с вашими хотелками. и каждый в этой теме померяет свои линки.

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

[slv700]

' timestamp='1444226557' post='1184277']

Такой тест и покажет все реальные потери на L1 и L2 и какая будет скорость живого трафика TCP/IP на L3/L4 без учета ограничений по ппс.

ну так давайте давайте сюда уже опции iperf для клиента и сервера в соответствии с вашими хотелками. и каждый в этой теме померяет свои линки.

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

TCP тест:

Server: iperf –s –w 64k

Client: iperf –c {server ip} –w 64k –P 5 –t 60 -r (или -d для дуплекса)

Также имеет смысл сравнить TCP с результатами UDP теста ( оценить потери).

UDP тест:

Server: iperf –s –u

Client: iperf –c {server IP} –u –b XXM –t 60

где ХХ - это ~110% от макс. ёмкости, а если при этом тесте нужно проверять ещё и пинг, то должен быть ~95%

Ключи -r (симплекс) и -d (дуплекс) при тестах UDP не использовать - глючит сам iperf.

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

Можно использовать iperf версии 1.8, и более поздние,главное смотреть, чтобы не глючили.

[[anp/hsw]]

вот вам результаты, любуйтесь:

 

TCP simplex:

R5E2-R54 ~ # iperf -c y.y.y.y -w 64k -P 5 -t 60 -r -B x.x.x.x
bind failed: Address already in use
bind failed: Address already in use
bind failed: Address already in use
------------------------------------------------------------
Server listening on TCP port 5001
Binding to local address x.x.x.x
TCP window size:  128 KByte (WARNING: requested 64.0 KByte)
------------------------------------------------------------
bind failed: Address already in use
bind failed: Address already in use
------------------------------------------------------------
Client connecting to y.y.y.y, TCP port 5001
Binding to local address x.x.x.x
TCP window size:  128 KByte (WARNING: requested 64.0 KByte)
------------------------------------------------------------
[  9] local x.x.x.x port 49248 connected with y.y.y.y port 5001
[  4] local x.x.x.x port 49245 connected with y.y.y.y port 5001
[  5] local x.x.x.x port 49246 connected with y.y.y.y port 5001
[  3] local x.x.x.x port 49244 connected with y.y.y.y port 5001
[  8] local x.x.x.x port 49247 connected with y.y.y.y port 5001
Waiting for server threads to complete. Interrupt again to force quit.
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-60.0 sec   359 MBytes  50.2 Mbits/sec
[  4]  0.0-60.0 sec   359 MBytes  50.2 Mbits/sec
[  3]  0.0-60.0 sec   361 MBytes  50.4 Mbits/sec
[  8]  0.0-60.0 sec   360 MBytes  50.4 Mbits/sec
[  9]  0.0-60.0 sec   361 MBytes  50.4 Mbits/sec
[sUM]  0.0-60.0 sec  1.76 GBytes   252 Mbits/sec

 

UDP overload:

R5E2-R54 ~ # iperf -c y.y.y.y -u -b 270M -t 60 -B x.x.x.x
------------------------------------------------------------
Client connecting to y.y.y.y, UDP port 5001
Binding to local address x.x.x.x
Sending 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local x.x.x.x port 5001 connected with y.y.y.y port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  1.85 GBytes   265 Mbits/sec
[  3] Sent 1350628 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  1.85 GBytes   265 Mbits/sec   0.043 ms  435/1350627 (0.032%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order

 

UDP simplex:

R5E2-R54 ~ # iperf -c y.y.y.y -u -b 260M -t 60 -B x.x.x.x
------------------------------------------------------------
Client connecting to y.y.y.y, UDP port 5001
Binding to local address x.x.x.x
Sending 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local x.x.x.x port 5001 connected with y.y.y.y port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  1.78 GBytes   254 Mbits/sec
[  3] Sent 1297490 datagrams
[  3] Server Report:
[  3]  0.0-60.0 sec  1.78 GBytes   254 Mbits/sec   0.065 ms  354/1297489 (0.027%)
[  3]  0.0-60.0 sec  1 datagrams received out-of-order

 

дуплексный тест по вашему рецепту не работает:

 

Waiting for server threads to complete. Interrupt again to force quit.
[ 38]  0.0-60.0 sec  71047787080639520 bits  0.00 (null)s/sec
[ 36]  0.0-60.0 sec  71483447088207848 bits  0.00 (null)s/sec
[ 37]  0.0-60.0 sec  72499236918246416 bits  0.00 (null)s/sec
[  8]  0.0-60.0 sec  71172590240297632 bits  0.00 (null)s/sec
[ 39]  0.0-60.0 sec  72660551594793888 bits  0.00 (null)s/sec
[sUM]  0.0-60.0 sec  358863612922185280 bits  0.00 (null)s/sec

 

графики tcp и udp при тестах имеют вид:

[slv700]

' timestamp='1444231401' post='1184332']

вот вам результаты, любуйтесь:

 

 

Дуплекс запустите с двух сторон симплекс.

[h3ll1]

На Cambium какие результати теста??? Покажите

[slv700]

На Cambium какие результати теста??? Покажите

Смотрите в профильной теме.