Alver

Немного не так. База не должна слышать чужой CPE. Это требование secondary self-interference Uplink

Это и есть требование по secondary self-interference в Downlink

Это Secondary self Interference в Downlink. См ниже обьяснение. Попробуйте разнести антенны по вертикали

Тест OOKLA speedtest.com - адекватен и это уже другой вопрос. Нужны еще другие результаты в других условиях видимости и помех. Тогда можно делать выводы. Но от вас, на данном этапе ваших изысканий, нужны только результаты загрузки канала реальным живым трафиком. Исследование адекватности инструментов тестирования- отдельный и другой вопрос.

1) понизить насколько возможно мощность дальнего устройства. 2) отвернуть насколько возможно обе антенны друг от друга по азимуту, чтобы снизить взаимное влияние линков 3) поменять одну из антенны в точке А на рупорную ( хорн) с большим side lobe подавлением. В этом нет никакой проблемы. Запускайте трафик на линках не 30М дуплекса, а по полной. То есть нужно посмотреть снижает ли фиксированный фрейм и синхронизация пропускную способность по крайней мере в точка-точка. В малтипойнт это конечно сделать сложнее, но там уже можно разделить испытания синхронизации и работы сек

Можно поменять антенну с большим side lobe suppresiion. Конечно повторно отправлются. Но при этом должна падать скорость TCP. Этого не происходит, потому что такой стек TCP у BT RB4011. В этом суть проблемы.

Это главное. Реализация фиксированного фрейма потребовало от UBNT кардинального изменения прокола доступа . Это новый шедулер, другой фрейминг , таиминг и много другое. Как UBNTработает на новом шедулере? Может включение синхронизации точно также как на AirSync М5 приводит к деградации канала? Тогда синхронизация теряет смысл, даже если она работает. Исследуйте все составляющие проблемы.

Да не видно из его тестов реальной скорости ни 450 ни 400М. Он измеряет и видит неизвестно что. Там нечего обсуждать, а тем более всяким разным придуркам вопить восторженными отзывами и делать из представленной галиматьи ложные выводы. Одно слово - далб*бы

У UBNT пару лет назад появился фиксированный фрейм с фиксированным делением UL/DL. Это есть необходимое, но не достаточное условие работы синхронизации и тем более что это TDMA. Я внимательно прочитал ваш отчет по тестам синхронизации и сделал свои замечания. Могу добавить к ним следующее. В первых попытках UBNT сделать синхронизацию только одно включение AirSync приводило к деградации параметров канала на >50%. С таким каналом синхронизация, даже если бы она работала, никому не нужна. Есть ли сейчас деградация канала в точка-точка и в малтипойнт при переходе с перем

Дело в том что если потери пакетов малы ,то и тесты Iperf TCP и BT TCP на RB4011 идентичны , в том числе по соотношению количества пакетов в сек прямого и обратного трафика. То есть, если нет или мало потерь, то количество пакетов ACK не растет. Если потери ест, то у стека TCP BT RB4011 % пакетов ACK в UL относительно пакетов данных в DL в полтора и более раз превышает % Iperf TCP. У вас линк на AF5x HD находится практически в идеальных близких к лабораторным условиях с минимумом потерь. Поэтому такой результат. Что касается Airmax 5AC , то у него и в идеальных усл

Все наоборот. Система работает на 19dBm, а ползунок остался на 29 дБм.

Ладно, иди с миром :). Только не лезь со мной спорить по радио:)

Есть замечания к тестам. Удаленный Рокет на коротком АС линке не должен слышать второй Рокет в точке A линка AB. А он у вас его слышит c сигналом -69 dBm. Это называется secondary self-interference. Ее быть не должно, даже если синхронизация работает. При этом линк AC тем не менее работает 1) потому что сигнал -38 dBm с CINR -38+69=31 dBm, что для 256QAM 5/6 недостаточно, нужно > 36 dB. Поэтому есть потери пакетов, которые в тесте не видны. 2) потери не видны, потому что линки тестятся 4-х ядерным RB4011. Почему, я уже обьяснял. В целом тесты проведены поч

Речь идет о стеке протокола TCP , и понятия TCP Window Size и принцип его работы. ОС Windows тут не причем и особенности реализации стека TCP на разных ОС в данном случае не важны. Ты точно *нутый на голову. Открыть глаза людям он собрался. :). Матчасть изучи, погугли хотя бы основные понятия, термины и определения сетевых протоколов и технологии радиосвязи, почитай что там написано. Ты вообще в ВУЗе учился? В каком и по какой специальности?

Конечно скорость обмена данными с разными серверами в Интернет будет разная. Кто с этим спорит? Вы вообще вменяемый человек? У вас есть вообще область, где вы что то хорошо знаете и делаете свою работу , не хуже, а желательно лучше других? Монтаж ПОН? Ну так сосредочьтесь на этом. Что вы здесь вступаете в спор в теме. которой не владеете?

Может и туда упираться. Ну и что из этого? Мы измеряем в тестах TCP скорость в канале с учетом всех факторов. Тогда измеренная величина будет соответствовать пропускной способности канала на реальном TCP/IP трафике. Матчасть изучите. Начните с того, что погуглите и узнайте, что есть TCP Windows. Потом, приобретя соответствующие знания, можете вступать в дискуссию с людьми. которые это уже знают.

Есть служебный трафик - это само собой. У TCP есть ACKи, у UDP - нет. У TCP если приходит ACK - пакет с информацией, что пакет не дошел до приемника или поврежден, то 1) стек ( окно) TCP пакетов на передачу уменьшается в размерах ( количестве пакетов пачке) 2) пачка пакетов TCP передается повторно. Это все уменьшает реальную скорость в канале.

Конечно это свежий пример неграмотности человека. Но с него какой спрос, это обычный кастомер. Но вот с вас то нужно просить. Совершенно очевидно что упоминаемая там скорость 500М- это data rate. И каким трафиком тестится скорость ip2.ru с результатом 250М ? Это TCP c учетом потерь? Правильно вы ему там сказали, нужно сделать адекватный TCP тест OOKLA speedtest.com. После этого можно что то обсуждать. На данный момент - это все не имеет ничего общего с реальной оценкой работы куска **** sensored под названием LiteBeam 5 AC . Ну и напрашиваются выводы ( понятно какие ) о

Да он там хорошо работает на той нагрузке, что есть. Так и было сказано, все же записано, посмотрите. Было сказано, что плохо работает при высокой нагрузке, в том случае -тестовой нагрузке , показано как факт. Из этих тестов совершенно понятно, что устройство работает на пределе своих возможностей, если встроенный тест не тянет. Вот собственно и все. Вы же очередной раз и с этим кейсом все извратили и сделали все по своему обыкновению, как я сказал выше.

Я же вам сказал, что RB4011 в тестах TCP не учитывает ( некорректно учитывает) ошибки в канале, работает почти также как и в UDP. Там где ощибок в канале нет ( на столе ) то тесты RB4011 не отличаются например от RB3011. RB4011 только может больше генерировать нагрузку TCP. На столе - пользуйтесь им без вопросов. а вот на улице, где тест TCP должен показать ошибки в канале и реальную скрость с учетом ошибок - этого делать не надо. Конечно я изучал RB4011 и тестил им разные устройства , НО НА СТОЛЕ. И я сказал, что никогда RB4011 в своих тестах линков ( не на столе) не применял и рез

Ну вы передергивается. Да, согласен, тесты повторили с помощью iperf, но повторили то для AF5X HD. Повторите для UBNT 5AC. А лучше всего сделайте на UBNT 5AC скрин живого трафика с загрузкой 200-250+ Mbps на дальности скажем 5-7 км.

Есть понятие максимальная мощность vs modulation . Cогласно спецификации AF5X HD называется Suggested Max, на 1024 QAM она составляет 19 - 20 dBm. Почему Suggested ? Потому что до этой макс. мощности усилитель работает в нормальном режиме, сигнал не искажается и в приемнике обеспечивается требуемый ( не выше) уровень ошибок EVM ( error vector magnitude). И что Вы показали, что на QAM1024 система работает на 29dBm? Так это 100% ошибка отображения Tх power на веб. Возьмите Power Meter и измерьте мощность передатчика, все увидите точно +-0.5 дБ. Я лично так и делал в далеко

Вот например суточный график Cacti, снятый с порта свича, к которому подключен линк PTP550, канал 80 МГц.

Вот, например здесь . И это не тест, а реальный живой трафик Download 420Mbps + Upload 40 Mbps в канале 80 Мгц, снятый с wireless интерфейса PTP550.

Провайдер сначала быстро и недорого зашел в поселок по радио на Камбиум, потом ,когда уяснил платежеспособный спрос в этом поселке, посчитал , что переход на ПОН в данном конкретном поселке рентабелен и построил там ПОН. Радиооборудование снял и либо использовал его в другом новом поселке , либо, как в данном случае, продал оборудование, которое ликвидное и его БУ с удовольствием покупают. Что тут странного и непонятного?