[sersil]

И тут срач развели UBNT versus Cambium! Есть куча веток с обсуждением сабжа.

Для меня на беседе-18 было несколько интересных моментов:

- Infinet движется в сторону TDMA и почти готов девайс синхронизации секторов Глонас/GPS,

- Siklu EtherHaul-600 в V-band на небольшие расстояния - ждём ценник,

- опять же Камбиум - система интересная, но сырая.

- повеселил IPBOOM - это просто вынос мозга))

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

[Alex-Pilot]

Да, Инфинет меня тоже очень порадовал. Особенно в плане магистральных решений. IP Boom повеселил :-)

[Дмитрий Быстрый]

повеселил IPBOOM - это просто вынос мозга))

IP Boom повеселил :-)

а что было смешного от них - расскажите

[Alex-Pilot]

а что было смешного от них - расскажите

Ну там выступал директор, который вроде шарит во всем, но стоит копнуть глубже, так уже вроде и не шарит...

Но суть не в этом. Суть в том что сначала они использовали UBNT и монтажники очень радовались в простоте настройки и мол даже работает на не прямой видимости. Пока сетка не легла (причины не ясны), но дело не в UBNT. После этого стали строить на ePMP и тут же столкнулись с трудностями мол только прямая видимость, нудная юстировка и прочие "трудности"...

Хотя по идее все должно быть наоборот так как все спецы от кэмбиум с пеной у рта доказывают что прямая видимость вообще не обязательна и куча слайдов с картинками где деревья в линке и прочее. Ну и в результате нахватали очень много физ. клиентов где попало (есть видимость, нет видимости), сетка нехило напрягается, 10% ваще не платит. Кароче вроде как около двух лет контора работает и до сих пор в ноль не вышли. Как-то так. Хотя и такой опыт может быть полезен другим, как надо делать и как не надо. То что не надо использовать ePMP при работе с физиками, так это уж точно. Для таких нагрузок нужно более серьезное и дорогое оборудование.

[Sonne]

Не может быть задержка 2-3 мс на ЗАПОЛНЕННОМ данными фрейме 802.11n MSDU длиной 4096 байт.

Я понимаю, что вам нужно впаривать свой шлак и без прямых подтасовок это сделать очень трудно. Но лично я больше верю своим глазам чем вашим фантазиям. В моих канала с трафиком до 60 Мбит на данный момент задержки 1-3 мс. Иногда подскакивает до 10-20 в зависимости от нагрузки.

 

Вы пытаетесь сказать, что ePMP у которой пинг от 8 мс и подскакивает до 200 лучше? Мне интересно вы в это искренне верите, или сочиняете по долгу службы?

[slv700]

Вы пытаетесь сказать, что ePMP у которой пинг от 8 мс и подскакивает до 200 лучше?

Вы неверно измеряете задержку. Пропингайте свой линк с 60М трафиком пакетами 1500 байт или лучше 4096 байт. Получите реальную цифру. Там 2-3 мс и близко не будет.

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

PS

И не надо сравнивать линк на убнт в идеальных условиях с линком ePMP в тяжелых условиях ( раз там задержка может достигать 200мс).

Есть очень простой критерий оценки работы убнт. Известно, что в точка -точка убнт с включенным airmax работает хуже ( меньше скорость, больше задержка) чем в 802.11n. Как любое оборудование работает в стандартном протоколе 802.11n в неидеальных условиях- также известно. Отсюда выводы очевидны.

И давайте прекратим здесь эту бессмысленную дискуссию про ePMP и убнт. Будут факты сравнительной работы ePMP и убнт в одинаковых условиях -выкладываем в профильной теме и обсуждаем.

[Sonne]

root@mon:~# ping 192.168.8.81
PING 192.168.8.81 (192.168.8.81) 56(84) bytes of data.
64 bytes from 192.168.8.81: icmp_req=1 ttl=62 time=1.78 ms
64 bytes from 192.168.8.81: icmp_req=2 ttl=62 time=1.35 ms
64 bytes from 192.168.8.81: icmp_req=3 ttl=62 time=2.80 ms
64 bytes from 192.168.8.81: icmp_req=4 ttl=62 time=1.61 ms
64 bytes from 192.168.8.81: icmp_req=5 ttl=62 time=2.10 ms
64 bytes from 192.168.8.81: icmp_req=6 ttl=62 time=1.36 ms
64 bytes from 192.168.8.81: icmp_req=7 ttl=62 time=2.35 ms
64 bytes from 192.168.8.81: icmp_req=8 ttl=62 time=1.35 ms
64 bytes from 192.168.8.81: icmp_req=9 ttl=62 time=1.30 ms
64 bytes from 192.168.8.81: icmp_req=10 ttl=62 time=1.46 ms
64 bytes from 192.168.8.81: icmp_req=11 ttl=62 time=1.46 ms
^C
--- 192.168.8.81 ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10015ms
rtt min/avg/max/mdev = 1.308/1.725/2.802/0.471 ms

 

Не может быть задержка 2-3 мс на ЗАПОЛНЕННОМ данными фрейме 802.11n MSDU длиной 4096 байт. Только для заполнения фрейма и передачи в одну сторону

нужно 5.2 мс. В две стороны -минимум 10.4 мс.

 

root@mon:~# ping 192.168.8.81 -s 1400
PING 192.168.8.81 (192.168.8.81) 1400(1428) bytes of data.
1408 bytes from 192.168.8.81: icmp_req=1 ttl=62 time=2.21 ms
1408 bytes from 192.168.8.81: icmp_req=2 ttl=62 time=4.06 ms
1408 bytes from 192.168.8.81: icmp_req=3 ttl=62 time=1.86 ms
1408 bytes from 192.168.8.81: icmp_req=4 ttl=62 time=4.06 ms
1408 bytes from 192.168.8.81: icmp_req=5 ttl=62 time=4.90 ms
1408 bytes from 192.168.8.81: icmp_req=6 ttl=62 time=2.01 ms
1408 bytes from 192.168.8.81: icmp_req=7 ttl=62 time=1.82 ms
1408 bytes from 192.168.8.81: icmp_req=8 ttl=62 time=2.00 ms
1408 bytes from 192.168.8.81: icmp_req=9 ttl=62 time=3.06 ms
1408 bytes from 192.168.8.81: icmp_req=10 ttl=62 time=2.81 ms
1408 bytes from 192.168.8.81: icmp_req=11 ttl=62 time=4.59 ms
1408 bytes from 192.168.8.81: icmp_req=12 ttl=62 time=2.46 ms
1408 bytes from 192.168.8.81: icmp_req=13 ttl=62 time=1.61 ms
1408 bytes from 192.168.8.81: icmp_req=14 ttl=62 time=4.81 ms
1408 bytes from 192.168.8.81: icmp_req=15 ttl=62 time=2.90 ms
1408 bytes from 192.168.8.81: icmp_req=16 ttl=62 time=1.91 ms
1408 bytes from 192.168.8.81: icmp_req=17 ttl=62 time=1.67 ms
1408 bytes from 192.168.8.81: icmp_req=18 ttl=62 time=2.21 ms
1408 bytes from 192.168.8.81: icmp_req=19 ttl=62 time=6.80 ms
1408 bytes from 192.168.8.81: icmp_req=20 ttl=62 time=2.17 ms
^C
--- 192.168.8.81 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19029ms
rtt min/avg/max/mdev = 1.614/3.000/6.802/1.379 ms

 

Видите пинги, которых по вашему не может быть?

[Sonne]

Не может быть задержка 2-3 мс на ЗАПОЛНЕННОМ данными фрейме 802.11n MSDU длиной 4096 байт. Только для заполнения фрейма и передачи в одну сторону

нужно 5.2 мс. В две стороны -минимум 10.4 мс.

 

Давайте прикинем, в секунде 1000 мс или 1000/ 5.2 = 192 фрейма по 4 кбайта. Таким образом в вашей системе невозможно переслать больше 192 * 4 = 768 кбайт/сек. Это соответствует скорости 6144 кбит/с или чуть больше 6 Мбит.

 

Вы понимаете какую чушь вы пишите?

[slv700]

root@mon:~# ping 192.168.8.81
PING 192.168.8.81 (192.168.8.81) 56(84) bytes of data.
64 bytes from 192.168.8.81: icmp_req=1 ttl=62 time=1.78 ms
64 bytes from 192.168.8.81: icmp_req=2 ttl=62 time=1.35 ms
64 bytes from 192.168.8.81: icmp_req=3 ttl=62 time=2.80 ms
64 bytes from 192.168.8.81: icmp_req=4 ttl=62 time=1.61 ms
64 bytes from 192.168.8.81: icmp_req=5 ttl=62 time=2.10 ms
64 bytes from 192.168.8.81: icmp_req=6 ttl=62 time=1.36 ms
64 bytes from 192.168.8.81: icmp_req=7 ttl=62 time=2.35 ms
64 bytes from 192.168.8.81: icmp_req=8 ttl=62 time=1.35 ms
64 bytes from 192.168.8.81: icmp_req=9 ttl=62 time=1.30 ms
64 bytes from 192.168.8.81: icmp_req=10 ttl=62 time=1.46 ms
64 bytes from 192.168.8.81: icmp_req=11 ttl=62 time=1.46 ms
^C
--- 192.168.8.81 ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10015ms
rtt min/avg/max/mdev = 1.308/1.725/2.802/0.471 ms

 

Не может быть задержка 2-3 мс на ЗАПОЛНЕННОМ данными фрейме 802.11n MSDU длиной 4096 байт. Только для заполнения фрейма и передачи в одну сторону

нужно 5.2 мс. В две стороны -минимум 10.4 мс.

 

root@mon:~# ping 192.168.8.81 -s 1400
PING 192.168.8.81 (192.168.8.81) 1400(1428) bytes of data.
1408 bytes from 192.168.8.81: icmp_req=1 ttl=62 time=2.21 ms
1408 bytes from 192.168.8.81: icmp_req=2 ttl=62 time=4.06 ms
1408 bytes from 192.168.8.81: icmp_req=3 ttl=62 time=1.86 ms
1408 bytes from 192.168.8.81: icmp_req=4 ttl=62 time=4.06 ms
1408 bytes from 192.168.8.81: icmp_req=5 ttl=62 time=4.90 ms
1408 bytes from 192.168.8.81: icmp_req=6 ttl=62 time=2.01 ms
1408 bytes from 192.168.8.81: icmp_req=7 ttl=62 time=1.82 ms
1408 bytes from 192.168.8.81: icmp_req=8 ttl=62 time=2.00 ms
1408 bytes from 192.168.8.81: icmp_req=9 ttl=62 time=3.06 ms
1408 bytes from 192.168.8.81: icmp_req=10 ttl=62 time=2.81 ms
1408 bytes from 192.168.8.81: icmp_req=11 ttl=62 time=4.59 ms
1408 bytes from 192.168.8.81: icmp_req=12 ttl=62 time=2.46 ms
1408 bytes from 192.168.8.81: icmp_req=13 ttl=62 time=1.61 ms
1408 bytes from 192.168.8.81: icmp_req=14 ttl=62 time=4.81 ms
1408 bytes from 192.168.8.81: icmp_req=15 ttl=62 time=2.90 ms
1408 bytes from 192.168.8.81: icmp_req=16 ttl=62 time=1.91 ms
1408 bytes from 192.168.8.81: icmp_req=17 ttl=62 time=1.67 ms
1408 bytes from 192.168.8.81: icmp_req=18 ttl=62 time=2.21 ms
1408 bytes from 192.168.8.81: icmp_req=19 ttl=62 time=6.80 ms
1408 bytes from 192.168.8.81: icmp_req=20 ttl=62 time=2.17 ms
^C
--- 192.168.8.81 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19029ms
rtt min/avg/max/mdev = 1.614/3.000/6.802/1.379 ms

 

Видите пинги, которых по вашему не может быть?

Вы с чего пингаете убнт ? С самого убнт ? Или c ПК ? У вас что стоит между ПК ( если с него запущен пинг ) и ethernet убнт ?

[slv700]

Это пинг идеального канала убнт

Ссылка отсюда

С 4096:

Пакетов: отправлено = 200, получено = 200, потеряно = 0

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 9мсек, Максимальное = 233 мсек, Среднее = 54 мсек

 

С 1500:

Пакетов: отправлено = 200, получено = 200, потеряно = 0

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 6мсек, Максимальное = 128 мсек, Среднее = 30 мсек

 

С 64:

Пакетов: отправлено = 200, получено = 200, потеряно = 0

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 1мсек, Максимальное = 11 мсек, Среднее = 2 мсек

[Sonne]

slv700 Это не пинги, а бред.

 

Начнем с того, что пинг размером 1500 байт не влезает в эернет пакет и фрагментируется на два при передаче из-за наличия заголовков. Продолжим тем что на идеальном канале UBNT не может быть никаких средних 30 мс. Это откровенно херовый канал.

 

Вот как выглядит пинг канала нагруженного на 100 Мбит!!!

 

 

 

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

[slv700]

1500 байт не влезает в эернет пакет и фрагментируется на два при передаче из-за наличия заголовков. Продолжим тем что на идеальном канале UBNT не может быть никаких средних 30 м

Фрагментируется он или нет зависит от MTU. Если MTU больше 1500,пройдет без фрагментации. Кроме того пакеты если и фрагментируются, то два подряд фрагмента по любому агрегируются в варелесс в MSDU 4096 байт, а потом MPDU 64K байт. Вот Вы пропингайте этот же канал через ethernet пакетами 1500 ( или чтобы точно без фрагментации 1470 байт) и получите цифру реальной задержки. Причем даже на этом Вашем скрине на пингах 50 байт задержка уже далеко не 1-3 мс, а принципиально другая и сопоставима с задержкой на Камбиум 8-12 мс при той же нагрузке.

ЗЫ

Sonne, хамить не надо.

[Sonne]

Вы с чего пингаете убнт ? С самого убнт ? Или c ПК ? У вас что стоит между ПК ( если с него запущен пинг ) и ethernet убнт ?

 

Я пингаю с линукс сервера через два промежуточных маршрутизатора и одну оптоволоконную линию канал с живым трафиком на UBNT за которым стоит Микротик. Именно так ходит живой трафик, нет нужды устраивать подтасовку данных.

 

Вот так выглядит mtr -s 1470:

 

                                      My traceroute  [v0.82]
mon (0.0.0.0)                                                             Mon Sep 29 22:10:48 2014
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                         Packets               Pings
Host                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. gw3.mywimax.me                                       0.0%   197    0.2   0.1   0.1   0.6   0.0
2. 192.168.9.10                                         0.0%   196    1.6   1.8   0.6  15.2   1.2
3. 192.168.8.81                                         0.0%   196    2.4   2.9   1.6   9.6   1.5

 

С учетом задержки промежуточных хопов те самые 1-2 мс.

[slv700]

Вы с чего пингаете убнт ? С самого убнт ? Или c ПК ? У вас что стоит между ПК ( если с него запущен пинг ) и ethernet убнт ?

 

Я пингаю с линукс сервера через два промежуточных маршрутизатора и одну оптоволоконную линию канал с живым трафиком на UBNT за которым стоит Микротик. Именно так ходит живой трафик, нет нужды устраивать подтасовку данных.

 

Вот так выглядит mtr -s 1470:

 

                                      My traceroute  [v0.82]
mon (0.0.0.0)                                                             Mon Sep 29 22:10:48 2014
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                         Packets               Pings
Host                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. gw3.mywimax.me                                       0.0%   197    0.2   0.1   0.1   0.6   0.0
2. 192.168.9.10                                         0.0%   196    1.6   1.8   0.6  15.2   1.2
3. 192.168.8.81                                         0.0%   196    2.4   2.9   1.6   9.6   1.5

 

С учетом задержки промежуточных хопов те самые 1-2 мс.

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

В общем это получается такой себе визуальный трюк. Чтобы получить адекватную цифру задержки на пинге ( для 802.11n) надо кроме длинного пинга еще нагрузить канал трафиком, чтобы заполнялся фрейм агрегации или просто использовать правильную утилиту измерения параметров канала, в том числе задержки, например, Chariot.

[slv700]

Не может быть задержка 2-3 мс на ЗАПОЛНЕННОМ данными фрейме 802.11n MSDU длиной 4096 байт. Только для заполнения фрейма и передачи в одну сторону

нужно 5.2 мс. В две стороны -минимум 10.4 мс.

 

Давайте прикинем, в секунде 1000 мс или 1000/ 5.2 = 192 фрейма по 4 кбайта. Таким образом в вашей системе невозможно переслать больше 192 * 4 = 768 кбайт/сек. Это соответствует скорости 6144 кбит/с или чуть больше 6 Мбит.

 

Вы понимаете какую чушь вы пишите?

Так нельзя считать. Кроме количества информации в байтах, времени в секундах, в радио есть частоты в МГц - полоса пропускания.

[Sonne]

Вы с чего пингаете убнт ? С самого убнт ? Или c ПК ? У вас что стоит между ПК ( если с него запущен пинг ) и ethernet убнт ?

 

Я пингаю с линукс сервера через два промежуточных маршрутизатора и одну оптоволоконную линию канал с живым трафиком на UBNT за которым стоит Микротик. Именно так ходит живой трафик, нет нужды устраивать подтасовку данных.

 

Вот так выглядит mtr -s 1470:

 

                                      My traceroute  [v0.82]
mon (0.0.0.0)                                                             Mon Sep 29 22:10:48 2014
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                         Packets               Pings
Host                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. gw3.mywimax.me                                       0.0%   197    0.2   0.1   0.1   0.6   0.0
2. 192.168.9.10                                         0.0%   196    1.6   1.8   0.6  15.2   1.2
3. 192.168.8.81                                         0.0%   196    2.4   2.9   1.6   9.6   1.5

 

С учетом задержки промежуточных хопов те самые 1-2 мс.

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

В общем это получается такой себе визуальный трюк. Чтобы получить адекватную цифру задержки на пинге ( для 802.11n) надо кроме длинного пинга еще нагрузить канал трафиком, чтобы заполнялся фрейм агрегации или просто использовать правильную утилиту измерения параметров канала, в том числе задержки, например, Chariot.

 

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

[Alex_E]

Спасибо организаторам за Беседу-18 ! Очень понравилось !

Насчет отчета по еРМР Кэмбиум. Да, в чем-то Кэмбиум лучше. Типа помехозащищенность, возможность работы с перекрытой зоной Френеля. Но ! Это при включении кого попало, с огромным количеством станций на секторе, предельной нагрузкой ради максимального заработка, причем, как оказалось в основном физлиц.

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

а где посмотреть доклады? Презентации.