[slv700]

Спецификации у них заявлены. Раз уж вы себя называете специалистом - расскажите нам об этом железе, как оно будет работать, с какой надежностью. Попробуйте еще раз предсказать.

 

Мimosa - это MU-MIMO на чипе АС Wave2 Quantenna, спектральная эффективность(пропускная способность в ethernet) 70-80 Mbps в каждых 10 Мгц на 256QAM5/6. Но это теоретически. Главный вопрос в софте, смогут ли они обеспечить требуемую надежность канала в точка-точка и малтипойнт в терминах потерь пакетов. Судя по их намерениям сделать полноценный FDD/TDD TDMA - у них может все получиться. Пока есть их продукты точка-точка, будем смотреть как они держат PER/BER в разных условиях, тогда будет понятно может ли быть получено на FDD 2 x 40Мгц MIMO 2x2 порядка 280-320 Mbps full duplex на разных дальностях, условиях видимости и помех.

 

к какому случаю относится удаление моего поста, в котором я критиковал ваши рассказы о распрекрасной дистрибуции Камбиум?

 

Это делал не я. Я наоборот, создал специальную тему, где вы , я и другие смогли бы высказаться по этому вопросу.

[slv700]

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

 

Надо людям разьяснить, что на самом деле означают полученные результаты.

[slv700]

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

 

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

[ReCom48]

Я говорю про то что, вот зять хоть хабарова, он сделал тесты, сделал скрины, все по уму, и выложил на общее обозрение, но я если чесно кроме аргумента "ЭТО ВСЕ ХЕРНЯ И ЭТО НЕ РАБОТАЕТ" от семисотого ничего не слышал, рез такой умный и правильный сделай тесты и скрины и докажи на практике, а трекать что это не так и это не то покрайней мере не тот уровень на который он сам себя возносит. ЭТО УРОВЕНЬ ТОЛЯ.

[Navu]

У нас есть спецраздел для слива кипящих эмоций. Примите во внимание, что в настоящее время любое случайное слово легко запускает политдискуссии на любом сайте в любом месте. За политику вне раздела про политику, буду банить без дальнейших увещеваний.

[slv700]

сделал скрины, все по уму, и выложил на общее обозрение, но я если чесно кроме аргумента "ЭТО ВСЕ ХЕРНЯ И ЭТО НЕ РАБОТАЕТ" от семисотого ничего не слышал,

Свои аргументы я привел Здесь . Если вы их не видели или не поняли, то, как говорится, учите матчасть. Мои выводы по тестированию АС следующие:

1)оборудование АС на чипе 802.11ас wave2 в реализации убнт, а также Микротик имеет низкую надежность канала, измеряемую потерями бит BER и пакетов PER. В тестах xabarov, Sonne и др. это отчетливо видно.

2) Вследствие больших потерь пакетов на МАС уровне тесты TCP в несколько потоков ( 5-20) дают заниженный ( от реальной пропускной способности результат. Я соглашусь с apn/hsw , здесь, что в реальной сети клиентов и сессий больше и потери пропускной способности канала на живом трафике TCP/IP в общей сумме меньше. Насколько больше-меньше нужно исследовать, увеличивая количество потоков в тестах до тех пор, пока остановится прирост скорости тестового TCP трафика.

3)С другой стороны, потери TCP пакетов при тестах восстанавливаются ( путем переповтора) самими тестерами, подключенными непосредственно в ethernet оборудования АС. В реальной сети эти потери восстанавливаются маршутизаторами и конечным оборудованием юзера. Тем самым потери пакетов в канале АС распространяются в реальной сети далеко за пределы собственно канала АС, вызвавшие эти потери. Поэтому реальная скорость живого трафика TCP/IP, наоборот, будет намного ниже полученного в TCP тестах на тестерах, подключенных непосредтвенно в ethernet АС. Типичным примером данного явления является случай, когда есть несколько последовательно связанных пролетов- каналов точка-точка, на каждом пролете в отдельности измеряем скорость - все нормально, а сквозная скорость - низкая.

4) тесты UDP при больших потерях не отражают реальную скорость АС канала, потому что не учитывают потерь пакетов. При этом микротик Bandwidth tester вообще не показывает потерь по перегрузу канала discarded ( в отличие скажем от iperf) , ни, как и любой UDP тест, не видит битые и потерянные пакеты. Некоторое понимание величины потерь по перегрузу канала можно получить по разнице скорости UDP тестера и скорости на erthenet интерфейсе тестера или оборудования АС. Некоторое представление сколько теряется пакетов также можно понять по параллельному тесту длинному пингу 1470 байт, причем не от тестера, а по причинам, изложенным в п.2, от граничного маршрутизатора до клиента.

В общем получается не все так просто и очевидно с этими тестами.

Я думаю, что в данном случае наиболее адекватным для оценки пропускной способности АС будет тест на speedtest.net. Там хоть и 4 потока TCP , но главное, восстановление потерь производится так, как это есть в реальной сети ( не тестерами). То что 4 потока, ну значит надо с этим смириться, потому что юзерам не докажешь, что такая скорость для него одного, спидтест вот так измеряет, а типа реальная пропускная способность канала в сумме для сотни юзеров будет больше. Никто этого не примет.

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

[ReCom48]

Вот тут реальный и нормальный разговор, ато взяли привычку срать друг на друга, есть что почитать и о чем подумать и что почепнуть для себя. За такие посты только как говорит мой сын РЕСПЕКТ И УВАЖУХА)))

[[anp/hsw]]

оборудование АС на чипе 802.11ас wave2 в реализации убнт, а также Микротик имеет низкую надежность канала

Вот те раз! Уже на wave2 накинулись. До этого основная претензия была, что wave1 не вывезет из-за того, что сырой, а теперь что?

 

измеряемую потерями бит BER и пакетов PER

Я тут просто промолчу, а вы в следующий раз не пишите так коряво, тут все понимают эти термины.

 

Тем самым потери пакетов в канале АС распространяются в реальной сети далеко за пределы собственно канала АС, вызвавшие эти потери.

Это не только для AC применимо, а даже для вашего хваленого камбиума, и вообще для любого железа, которое способно потерять пакет.

Причем тут AC?

 

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

На самом деле это очень нетипичный случай. В таком случае один из пролетов явно генерит ошибок больше остальных, и найти его можно. Если же процент ошибок примено одинаков на всех пролетах, то скорость будет снижаться достаточно медленно. Единственно, где такое возможно, это ~1-2% потерь в каждом пролете, то это явно нештатная работа.

 

тесты UDP при больших потерях не отражают реальную скорость АС канала, потому что не учитывают потерь пакетов.

Ни AC, ни N, ни G, ни B, ни камбиума, ни микротика, вобщем, можете продолжить.

Еще раз обозначу свою точку зрения на тестирование: либо подрезаете шейпером, пока потерь не будет, либо генерите трафика столько, сколько нужно для нужного уровня потерь. Кому-то и 0.1% нормален, а кому-то и 0.03% подавай.

 

Я думаю, что в данном случае наиболее адекватным для оценки пропускной способности АС будет тест на speedtest.net.

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

[slv700]

' timestamp='1434617421' post=1140580]

Сообщение #33

 

Звание: Доцент

Группа: VIP

Сообщений: 1 494

Регистрация: 08 апреля 05

 

 

Просмотр сообщенияslv700 (Сегодня, 09:32) писал:

оборудование АС на чипе 802.11ас wave2 в реализации убнт, а также Микротик имеет низкую надежность канала

 

Вот те раз! Уже на wave2 накинулись. До этого основная претензия была, что wave1 не вывезет из-за того, что сырой, а теперь что?

Это описка, конечно речь идет о АС wave1.

[slv700]

' timestamp='1434617421' post=1140580]

Это не только для AC применимо, а даже для вашего хваленого камбиума, и вообще для любого железа, которое способно потерять пакет.

Причем тут AC?

Это очевидно. Речь идет о АС вот и сказано про потери АС, у которых их больше, чем у других. Следует сказать что у убнт BER/PER канала был всегда высокий (хуже конкурентов), и в случае убнт АС потери стали еще больше, что стало проблемой.

[slv700]

' timestamp='1434617421' post=1140580]

Еще раз обозначу свою точку зрения на тестирование: либо подрезаете шейпером, пока потерь не будет,

Вы эти потери на udp не увидите, только дропы по перегрузу канала. Сравнение in и out ничего не даст. Точную оценку и пропускной спосности и потерь может, например, дать тестер Chariot. Видимо его, как вариант, и следует применять для тестирования АС.

[[anp/hsw]]

Речь идет о АС вот и сказано про потери АС, у которых их больше, чем у других.

А у N потерь больше, чем в G, а у G больше, чем B. И что с того? Корректно обрабатывать их надо, вот и все.

 

Вы эти потери на udp не увидите, только дропы по перегрузу канала.

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

 

Точную оценку и пропускной спосности и потерь может, например, дать тестер Chariot. Видимо его, как вариант, и следует применять для тестирования АС.

И толку с этого тестера, если это синтетика? Вы осознаете, что письками меряться и строить реальные каналы связи - две совершенно разные вещи?

[slv700]

' timestamp='1434630613' post=1140696]

А у N потерь больше, чем в G, а у G больше, чем B. И что с того? Корректно обрабатывать их надо, вот и все.

В этом и есть проблема, что протокол Airmax даже в N не обеспечивает должный уровень обработки ошибок на MAC уровне. Именно поэтому на убнт всегда даже в идеальных условиях есть большая разница между синтетическими тестами TCP и UDP. А в АС ошибок еще больше, и разница между UDP и TCP в разы. Такого быть не должно. В этом и есть проблема.

[slv700]

' timestamp='1434630613' post=1140696]

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

Речь идет о потерях пакетов A-MSDU на MAС ( L2) уровне, которые потеряны или битые, и не восстановлены на MAC уровне протоколом Airmax путем ретрансмиттов. В АС я не вижу счетчика таких ошибок. Для этих пакетов или нет вообще ретрасмиттов ( в этом случае джиттер не растет) или их max количество превышено ( тогда растет средняя задержка для всех пакетов) и эти потери с MAC уровня идут наверх на TCP уровень, которые отрабатываются повторами перадачи уже TCP пакетов на L4. Именно эти потери уменьшают размер окна стека TCP и снижают скорость трафика TCP и резко увеличивают среднюю задержку ( что мы видим на АС).

[slv700]

' timestamp='1434630613' post=1140696]

И толку с этого тестера, если это синтетика? Вы осознаете, что письками меряться и строить реальные каналы связи - две совершенно разные вещи?

Когда потери в пределах нормы, то синтетика TCP и UDP близки, может различаются max на 5-10% ( что есть на Камбиум ePMP), тогда можно обоснованно считать, что реальная пропускная способность канала на живом TCP трафике находится где то посередине между синтетикой TCP и UDP и погрешность ( ошибка ) оценки будет невелика.

Если потери большие и синтетика TCP и UDP отличаются в разы, то даже если каким то образом узнать процент потерь по тестам UDP, то как оценить реальную пропускную способность канала? Тоже как среднее арифметическое между UDP и TCP ? Нет, так будет точно неверно, погрешность оценки будет соизмерима с самой оцениваемой величиной. В этом случае если скажем Chariot или другим способом мы видим что потери большие и различия синтетики UDP и TCP неприемлемы, то мне думается, что из синтетики спидтест.net будет относительно более точным методом оценки пропускной способности канала. Или надо брать старый добрый способ измерения скорости путем прокачки файлов с FTP сервера. Но здесь опять мы рискуем получить ошибочный результат, поскольку FTP -это пакеты 1500 байт, то есть мы не учитываем пакетную производительность канала.

Самый точный результат - снятие статистики типа MRTG c ethernet интерфейса девайса путем загрузки синтетикой, но реальными приложениями- миксом торрентов, видео, ftp и др. А если будет живой трафик, то это будет самый точный результат- даже уже не синтетический тест, а натурный эксперимент.

В общем все эти проблемы вызваны только одной причиной - высокие потери в канале АС, когда привычные нам синтетические тесты становятся неадекватными. Для правильного оборудования с допустимыми потерями обычные методы тестирования синтетикой UDP и TCP - норма.

Поэтому как реально работает канал на АС можно IMHO относительно более точно ( чем другие методы) узнать спидтестом ( тестом на speedtest.net) или нагрузив канал имитацией живого TCP/IP трафика.

Xabarov конечно проделал большую работу, но похоже реальной оценки пропускной способности канала убнт АС мы так и не получили. Однако это дало понимание выше изложенных закономернойстей работы и тестирования канала АС, в чем уже есть большая польза для дела.

[SSD]

нет еще неотказался, просто на 1-й башне 5 линков и на другой 5 линков, директор в отпуске, на днях выйдет буду потихонечку линк за линком делать, тесты в своей теме выкладывать буду.

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

О-ло-ло не стоит на зло маме морозить уши. Слв700 хоть и едко говорит но в его словах есть толк.

[[anp/hsw]]

А в АС ошибок еще больше, и разница между UDP и TCP в разы. Такого быть не должно. В этом и есть проблема.

Это вообще не проблема, покуда он работает при этом лучше N _И_ эти ошибки не влияют на передачу трафика, больше чем в N. Оба условия соблюдаются.

 

 

Речь идет о потерях пакетов A-MSDU на MAС ( L2) уровне, которые потеряны или битые, и не восстановлены на MAC уровне протоколом Airmax путем ретрансмиттов. В АС я не вижу счетчика таких ошибок.

Вообще-то обнаружение ошибок прекрасно работает. А за счетчиками загляните в telnet.

 

Xabarov конечно проделал большую работу, но похоже реальной оценки пропускной способности канала убнт АС мы так и не получили.

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

[slv700]

' timestamp='1434708283' post=1141149]

И_ эти ошибки не влияют на передачу трафика

' timestamp='1434708283' post=1141149]

Вообще-то обнаружение ошибок прекрасно работает. А за счетчиками загляните в telnet.

Обнаружение ошибок конечно какое то есть, это CRC для битых фреймов A-MSDU и групповой АСК для потерянных фреймов A-MPDU. Но проблема в том, что ошибок слишком много, так что они не успевают восстаналиваться на MAC ретрансмитами и похоже , что алгоритм построения очередей этих ретрасмиттов не расчитан на большое количество потерянных и битых пакетов. Почему много потерь ? Ну раз убнт АС позволяет себе работать на 256QAM 5/6 при недостаточном для этой модуляции CINR 27-28 Mbps, то ошибки непременно будут и чем больше трафик, тем больше ошибок, в тестах это видно совершенно определенно по росту средней задержки и недобору скорости.

И если эти невосстановленные ошибки с L2 уходят наверх на TCP уровень, то что должно заниматься восстановлением этих ошибок ? Понятно это делают IP роутеры, которых в L2 сети вообще может и не быть, и терминальные устройства. Что значит мне не понравились результаты тестов ? Вы смотрите в книгу- видите фигу? Это все азбучные истины работы сетевых протоколов. Я вижу результаты тестов, даю им объяснение и делаю выводы именно из понимания того, как работают сетевые протоколы, независимо от того , Убнт это или Камбиум.

[Sonne]

Пока вы балаболите, я выкладываю утилизацию второго магистрального канала на Powerbeam AC. К сожалению, оптический бекбон работает на 100Мбит, поэтому максимальную скорость на 40МГц не удалось проверить.

 

 

Есть еще одна проблема - интерфейс почему то не запускается на 1 Гбит. Но это достаточная частая ситуация на телевизионных вышках. Будем искать какое-то универсальное решение.

 

Для построения каналов на короткие дистанции Power Beam AC500 является идеальным недорогим решением. Благодаря модуляции 256QAM в полосе 20МГц обеспечивается стабильный дуплексный канал в пропорции 100/20M = 120М со средней задержкой в мониторинге 3-5 мс. Это более чем удовлетворяет потребности беспроводных операторов в категории 100M.

 

Разница между 802.11n и AC продуктами UBNT в режиме P2P неоспорима и не требует обсуждения. Она не видна либо дилетанту, который не понимает принципов работы радио, либо вруну, который выгораживает конкурентнов не имеющих подобного продукта в своей линейке.

[NewUse]

Есть еще одна проблема - интерфейс почему то не запускается на 1 Гбит. Но это достаточная частая ситуация на телевизионных вышках. Будем искать какое-то универсальное решение.

SFTP + фиритовые кольца + пое-инжектор с поддержкой 1Гбита (в одной из первых партий был косяк, в комплекте клали 100МБитные ПоЕ, правда не помю с какими дивайсами, возможно не с пауэрбимами ) :)

[xabarov]

Это делал не я. Я наоборот, создал специальную тему, где вы , я и другие смогли бы высказаться по этому вопросу.

Добавим это в копилку вашего вранья. Я напомню - дело было глубокой ночью, в момент удаления постов в теме находились только два пользователя - slv700 и xabarov. Один добавлял пост, другой - удалял через минуту. И так 4-5 раз. Как думаете, кому из этих двух пользователей был невыгоден критикующий пост о дистрибуции Камбиум? Может вспомните? А то можно попросить модератора проверить, кто удалял.

Надо людям разьяснить, что на самом деле означают полученные результаты.

Многим будут интересны разъяснения от сторонних профессионалов, а не от завравшихся пиар-ботов.

[BeHalf]

Чуть чуть не в тему, но мне вот что интересно, а как у ubnt ac с загрузкой процессора при большом трафике?

У меня есть реальный магистральный линк на мт при нагрузке 120-130/30-40 загрузка проца ~50-55% (по пакетам ~15к/10к), я так подозреваю что когда трафик дойдет до 2-х сотен, то проц будет на полке. К бордам подходит оптика.

Я собственно к чему, народ тут пишет про большие скорости, а проц их пережует?)

[NewUse]

раньше загибается радио, чем ложится проц... хотя на специфичном трафике, например, на voip проц может загнуться раньше...

[xabarov]

Чуть чуть не в тему, но мне вот что интересно, а как у ubnt ac с загрузкой процессора при большом трафике?

Вот тут я приводил скрины, на которых видно при какой нагрузке загрузка проца 100%. Полная загрузка была при TCP трафике 200-220 мбит.

[BeHalf]

Вот тут я приводил скрины, на которых видно при какой нагрузке загрузка проца 100%. Полная загрузка была при TCP трафике 200-220 мбит.

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