sersil Опубликовано 29 сентября, 2014 · Жалоба И тут срач развели UBNT versus Cambium! Есть куча веток с обсуждением сабжа. Для меня на беседе-18 было несколько интересных моментов: - Infinet движется в сторону TDMA и почти готов девайс синхронизации секторов Глонас/GPS, - Siklu EtherHaul-600 в V-band на небольшие расстояния - ждём ценник, - опять же Камбиум - система интересная, но сырая. - повеселил IPBOOM - это просто вынос мозга)) ну и опять же живое общение с производителями и коллегами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex-Pilot Опубликовано 29 сентября, 2014 · Жалоба Да, Инфинет меня тоже очень порадовал. Особенно в плане магистральных решений. IP Boom повеселил :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дмитрий Быстрый Опубликовано 29 сентября, 2014 · Жалоба повеселил IPBOOM - это просто вынос мозга)) IP Boom повеселил :-) а что было смешного от них - расскажите Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex-Pilot Опубликовано 29 сентября, 2014 · Жалоба а что было смешного от них - расскажите Ну там выступал директор, который вроде шарит во всем, но стоит копнуть глубже, так уже вроде и не шарит... Но суть не в этом. Суть в том что сначала они использовали UBNT и монтажники очень радовались в простоте настройки и мол даже работает на не прямой видимости. Пока сетка не легла (причины не ясны), но дело не в UBNT. После этого стали строить на ePMP и тут же столкнулись с трудностями мол только прямая видимость, нудная юстировка и прочие "трудности"... Хотя по идее все должно быть наоборот так как все спецы от кэмбиум с пеной у рта доказывают что прямая видимость вообще не обязательна и куча слайдов с картинками где деревья в линке и прочее. Ну и в результате нахватали очень много физ. клиентов где попало (есть видимость, нет видимости), сетка нехило напрягается, 10% ваще не платит. Кароче вроде как около двух лет контора работает и до сих пор в ноль не вышли. Как-то так. Хотя и такой опыт может быть полезен другим, как надо делать и как не надо. То что не надо использовать ePMP при работе с физиками, так это уж точно. Для таких нагрузок нужно более серьезное и дорогое оборудование. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 29 сентября, 2014 · Жалоба Не может быть задержка 2-3 мс на ЗАПОЛНЕННОМ данными фрейме 802.11n MSDU длиной 4096 байт. Я понимаю, что вам нужно впаривать свой шлак и без прямых подтасовок это сделать очень трудно. Но лично я больше верю своим глазам чем вашим фантазиям. В моих канала с трафиком до 60 Мбит на данный момент задержки 1-3 мс. Иногда подскакивает до 10-20 в зависимости от нагрузки. Вы пытаетесь сказать, что ePMP у которой пинг от 8 мс и подскакивает до 200 лучше? Мне интересно вы в это искренне верите, или сочиняете по долгу службы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 29 сентября, 2014 · Жалоба Вы пытаетесь сказать, что ePMP у которой пинг от 8 мс и подскакивает до 200 лучше? Вы неверно измеряете задержку. Пропингайте свой линк с 60М трафиком пакетами 1500 байт или лучше 4096 байт. Получите реальную цифру. Там 2-3 мс и близко не будет. У ePMP линк с задержкой 8мс ( пусть даже при сильных помехах иногда до 200мс) одинаков что на пинге 64 байт, что 4096 байт ( как на меди или оптике) и он конечно же лучше, чем убнт. Я в это не верю, я это определенно знаю. PS И не надо сравнивать линк на убнт в идеальных условиях с линком ePMP в тяжелых условиях ( раз там задержка может достигать 200мс). Есть очень простой критерий оценки работы убнт. Известно, что в точка -точка убнт с включенным airmax работает хуже ( меньше скорость, больше задержка) чем в 802.11n. Как любое оборудование работает в стандартном протоколе 802.11n в неидеальных условиях- также известно. Отсюда выводы очевидны. И давайте прекратим здесь эту бессмысленную дискуссию про ePMP и убнт. Будут факты сравнительной работы ePMP и убнт в одинаковых условиях -выкладываем в профильной теме и обсуждаем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 29 сентября, 2014 · Жалоба 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 Видите пинги, которых по вашему не может быть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 29 сентября, 2014 · Жалоба Не может быть задержка 2-3 мс на ЗАПОЛНЕННОМ данными фрейме 802.11n MSDU длиной 4096 байт. Только для заполнения фрейма и передачи в одну сторону нужно 5.2 мс. В две стороны -минимум 10.4 мс. Давайте прикинем, в секунде 1000 мс или 1000/ 5.2 = 192 фрейма по 4 кбайта. Таким образом в вашей системе невозможно переслать больше 192 * 4 = 768 кбайт/сек. Это соответствует скорости 6144 кбит/с или чуть больше 6 Мбит. Вы понимаете какую чушь вы пишите? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 29 сентября, 2014 · Жалоба 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 убнт ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 29 сентября, 2014 · Жалоба Это пинг идеального канала убнт Ссылка отсюда С 4096: Пакетов: отправлено = 200, получено = 200, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 9мсек, Максимальное = 233 мсек, Среднее = 54 мсек С 1500: Пакетов: отправлено = 200, получено = 200, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 6мсек, Максимальное = 128 мсек, Среднее = 30 мсек С 64: Пакетов: отправлено = 200, получено = 200, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 1мсек, Максимальное = 11 мсек, Среднее = 2 мсек Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 29 сентября, 2014 · Жалоба slv700 Это не пинги, а бред. Начнем с того, что пинг размером 1500 байт не влезает в эернет пакет и фрагментируется на два при передаче из-за наличия заголовков. Продолжим тем что на идеальном канале UBNT не может быть никаких средних 30 мс. Это откровенно херовый канал. Вот как выглядит пинг канала нагруженного на 100 Мбит!!! Я вынужден констатировать, что вам не спорить в техническом разделе надо, а искать помощи докторов мозговедов с диагнозом "камбиум головного мозга". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 29 сентября, 2014 · Жалоба 1500 байт не влезает в эернет пакет и фрагментируется на два при передаче из-за наличия заголовков. Продолжим тем что на идеальном канале UBNT не может быть никаких средних 30 м Фрагментируется он или нет зависит от MTU. Если MTU больше 1500,пройдет без фрагментации. Кроме того пакеты если и фрагментируются, то два подряд фрагмента по любому агрегируются в варелесс в MSDU 4096 байт, а потом MPDU 64K байт. Вот Вы пропингайте этот же канал через ethernet пакетами 1500 ( или чтобы точно без фрагментации 1470 байт) и получите цифру реальной задержки. Причем даже на этом Вашем скрине на пингах 50 байт задержка уже далеко не 1-3 мс, а принципиально другая и сопоставима с задержкой на Камбиум 8-12 мс при той же нагрузке. ЗЫ Sonne, хамить не надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 29 сентября, 2014 · Жалоба Вы с чего пингаете убнт ? С самого убнт ? Или 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 мс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 29 сентября, 2014 · Жалоба Вы с чего пингаете убнт ? С самого убнт ? Или 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
slv700 Опубликовано 29 сентября, 2014 · Жалоба Не может быть задержка 2-3 мс на ЗАПОЛНЕННОМ данными фрейме 802.11n MSDU длиной 4096 байт. Только для заполнения фрейма и передачи в одну сторону нужно 5.2 мс. В две стороны -минимум 10.4 мс. Давайте прикинем, в секунде 1000 мс или 1000/ 5.2 = 192 фрейма по 4 кбайта. Таким образом в вашей системе невозможно переслать больше 192 * 4 = 768 кбайт/сек. Это соответствует скорости 6144 кбит/с или чуть больше 6 Мбит. Вы понимаете какую чушь вы пишите? Так нельзя считать. Кроме количества информации в байтах, времени в секундах, в радио есть частоты в МГц - полоса пропускания. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sonne Опубликовано 29 сентября, 2014 · Жалоба Вы с чего пингаете убнт ? С самого убнт ? Или 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. Я рад что к вам начинает приходить понимание. Осталось только понять, что пустой канал никому не интересен. На нагруженном канале не только пинги, но и весь полезный трафик ходит с такими задержками. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex_E Опубликовано 29 сентября, 2014 · Жалоба Спасибо организаторам за Беседу-18 ! Очень понравилось ! Насчет отчета по еРМР Кэмбиум. Да, в чем-то Кэмбиум лучше. Типа помехозащищенность, возможность работы с перекрытой зоной Френеля. Но ! Это при включении кого попало, с огромным количеством станций на секторе, предельной нагрузкой ради максимального заработка, причем, как оказалось в основном физлиц. Я со своей стороны поделился с коллегами из других компаний работой UBNT в нормальных условиях с официально полученными частотами и многие очень удивились, что такое недорогое оборудование способно так хорошо работать. а где посмотреть доклады? Презентации. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...