Alver

Нет, и это ему ну нужно. Но к облачному NMS он подключается Вирус . Сначала встали заводы в Китае, остановилась логистика в Европе. Все откладывается на неопределенный срок.

ОСББ и Облэнерго владеют инфраструктурой, к которой провайдеры хотят получить доступ. Этот доступ не может быть бесплатным, он часто из за чрезмерных технических и административных требований требует существенных вложений при инсталляции и эксплуатации сети. Собственно в технической возможности соблюдения условий размещения оборудования и стоимости этого для провайдера и состоит суть проблемы. Есть несколько путей ее решения 1) Законодательный. Должно быть все четко и однозначно прописать в законах кто , что и как должен делать и сколько платить. Даже если все это будет принято , то по любому собственники будут нарушать закон и свои же собственные правила. С ними судиться можно, нужно, но неразумно и бесперспективно ( будет себе дороже). Само написание и принятие законов , где будет все правильно (с точки зрения провайдера) приписано и устраивает собственников , и они соблюдаются всеми сторонами- это из области фантастики. Поэтому нужно готовиться к худшему. И если цена доступа к инфраструктуре будет высока- повышать тарифы для населения . И делать это нужно согласовано, чтобы никто отдельно из провайдеров не пострадал. Да, это называется картельный сговор. Но это вынужденный шаг, его необходимость можно будет при необходимости доказать в судах. 2) Как говорит искусство войны по китайски, нужно сделать своих врагов своими друзьями. И как говорят китайцы они будут самыми верными вашими друзьями, помощниками и слугами. Как это сделать? Заинтересовать их помогать вам. Ключом к решению проблемы является совместное с собственниками инфраструктуры предоставление провайдерами помимо Интернет также перспективной услуги Internet Of Things ( IoT). Это не LORA, и не NB-IoT. Их там не будет. Не спрашивайте почему, это долгий и непростой вопрос, и, главное, это не ваша тема. А вот новое поколение WiFi6 - это ваше. Вы же все равно предлагаете ( ставите) домашние вайфай роутеры вашим юзерам в многоквартирных домах и в частном секторе. Такими роутерами со временем будут недорогие wifi 6 роутеры, которые также заточены под IoT и очень скоро ( и это неизбежно будет с вами или без вас ) будут обслуживать счетчики электроэнергии для Облэнерго, счетчики воды, тепла, сигнализации и многое другое -для ОСББ. Вот и отдайте собственником инфраструктуры обслуживание вайфай свичей/роутерой/точек доступа , к которым подключены домашние вайфай роутеры в многоквартирном доме и на улице в частном секторе. Это подключение может быть по кабелю ( оптика, пон) или радио, используйте то, что в данном месте эффективно и рентабельно. И эти ваши новые бизнес партнеры помимо своих задач будут помогать ( а не препятствовать) решать и ваши задачи- предоставлять юзерам также и доступ в Интернет. А по деньгам - договоритесь. ЗЫ И если организаторы УКОС на этот раз ( в этом году) скорректируют в вменяемую сторону свои требования к доступу к своей инфраструктуре участия в конференции, то я бы поделился своим видением возможных путей решения этой темы.

Ставьте Cambium - в доме бюджетный cnPilot E425H, на улице E505 Outdoor .Роуминг работает без контролера, автоматически, ничего настраивать не надо. NMS облачный, там можно настроить доступ разных групп клиентов или это сделать локально на ТД. Все нужная для базы отдыха, гостиницы и типа того функциональность есть. Ничего платить за лицензии, сервисные контракты и всякую навязываемую производителями фичи - не надо. Все есть из коробки. Обслужит 100 клиентов.

Это криворукие видимо ставили, возможно те же самые, что и в парке Шевченко в Киеве. Так это вы ? Аруба стоит в районе SOHO Шарм-эль-Шейх, Тысячи гуляющих отдыхающих в районе. К доступу и роумингу вопросов нет.

Повышайте лучше свой кругозор.

Приезжай в Киев, парк Шевченко и можешь увидеть как "хорошо" работает Аруба, в том числе в роуминге (типа Smart City.). Пройдешь на Майдан Незалежности- Крещатик, Контрактовая пл. ( Подол) - увидишь Cambium, Михайловская площадь -Ruckus, Софиевская - Микротик. Аутдор Cisco я не видел ( но это не значит что их там нет ;), видимо проблема что нет у них хороших интегрированных oudoor антенн ( Cisco не радисты). Есть у Cisco Meraki - но это другая линейка. Как работает indoor Cisco ( точнее как можно неправильно настроить роуминг), можно увидеть в аэропорту Борисполь ( Киев). Есть еще Enterprise ТД - китайцы, типа Edimax, Engenius- глюкавые по обыкновению. Huawei стабильней,но как реально в работает в oudoor, точнее как можно обосрасть хорошую идею ( тоже типа Smart City, б*ть :) - можно прибыть к общагам КПИ ( Киев) и посмотреть вживую. По плану должны были покрыть вайфай парк КПИ, но ничего нет, что то пошло не так :). И еще, Хуавей пока под санкциями , в том числе по чипсетам вайфай. Если снимут , то выкрутится , нет - то придется уйти с рынка вайфай ТД Enterprise, и возможно не только с него.

Это есть неверно. А значит, все остальное, сказанное вами - вызывает большие сомнения. CIsco, Ruckus, NP( Aruba), Cambium - все Enterprise ТД и удовлетворяют по фукционалу требованиям программы построения вайфай в Европе, что конкретно- можно посмотреть обсуждение в теме Бесшовный роуминг, UNIFI vs Mikrotik здесь WiFi4EU. В частности все они умеют роуминг любой (OKC, 802.11r) и все держат реальных 100-200 клиентов под нагрузкой. Чуть лучше других (на 10-15% меньше деградация суммарной пропускной способности с увеличением количества клиентов) это делают Cambium и Ruckus. Больше 200-300 клиентов держит только Xirrus - до 600 и делает он это за счет того, что у него несколько радиоинтерфейсов в одной ТД и у него SDR (FPGA ) чипсет. Такие ТД ставят на стадионах и вокзалах. Cambium полтора года назад купил Xirris и только что выпустил новую точку доступа 802.11ax/WiFi6 - SDR c тремя радио ( один MIMO 4x4 в 2.4 Ггц и два MIMO4x4 в 5Ггц) cnPilotXirrus XV3-8 WiFi6 Access Point - держит 1000+ клиентов. Это лучшая по этому показателю точка доступа в мире и одна из немногих -SDR, возможен программный upgrade до 802.11 ax wave2 - OFDMA+ MU-MIMO 8x8 . И поскольку Cambium это exMotorola, то у него лучшее среди списка выше радио. При этом Cisco в 5 раз дороже Сambium, имеет закрытую архитектуру (работает только в своей сетевой инфраструктуре , требующей платных лицензий), сложное обслуживание, требующее квалифицированных сисадминов. Аруба стала HP и есть сомнения, что это ей пошло на пользу. Ruckus за последние 3 года раза три перепродавался, последний раз оказался в в руках гиганта Сommscope и что там будет с его развитием - есть неопределенность.

Не, я тут подумал ( еще раз ) разнесение по вертикали в случае синхронизации не нужно. Сорри не туда посмотрел

Немного не так. База не должна слышать чужой 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%. С таким каналом синхронизация, даже если бы она работала, никому не нужна. Есть ли сейчас деградация канала в точка-точка и в малтипойнт при переходе с переменного фрейма , с фиксированного фрейма с переменным делением UL/DL на фиксированный фрейм с фикcированным делением UL/DL? Меняются ли параметры канала ( пропускная способность, задержка) при при включении синхронизации? Нет ли ограничения на количество клиентов в малтипойнт с фиксированным фреймом в количестве 60 штук ? Есть такие данные о работе Rocket 5AC ? Вот на эти вопросы ответьте. Потом можно исследовать работает ли синхронизация и при каких условиях она работает. Вы сами дали ссылку на этот кейс. Я его прокомментировал, что там, по моему мнению, сделано не так.

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

Все наоборот. Система работает на 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. Почему, я уже обьяснял. В целом тесты проведены почти правильно. Нужно уменьшить помеху c -69 дБм до -90 дБм ( в случае Target RSSI на Мастер -точка А равной - 55Дбм) Как это сделать? Уменьшить Тх Рокета А длинного линка на 20 дБ ? !!!. Вряд ли тогда линк AB будет работать. 3) Антенны Рокетов в точке А работают в разных поляризациях. Одна антенна -это обычная H и V, вторая - dual slant +- 45 град. Это может давать развязку + 25 дб, что для сигнала -58дБм даст снижение помехи до -83 дБм и вполне может быть что на Flexible фрейме эта помеха мешает, а на фиксированном - мешает не сильно и без работающей синхронизации. В целом методологически тесты сделаны правильно и похоже синхронизация таки имеет эффект на Рокетах с фиксированым фреймом. Это значит, что синхроимпульсы заставляют передатчики двух устройств передавать фрейм фиксированной длины с делением UL/DL 50/50 в одно и то же время и не создавать помехи друг другу при передаче. Это сделать в системе с фиксированным фреймом несложно, это самое простое в синхронизации. Вопрос работающей синхронизации на самом деле стоит шире . Как хорошо работает система в точка-точка и малтипойнт, падает ли и насколько скорость при полной нагрузке при FR ? Тесты следует немного доработать ( с учетом высказанных замечаний) и тогда можно будет делать выводы с тестами, на которых можно ссылаться как доказательство работающей синхронизации у UBNT 5AC Airmax. Однако главный вопрос заключается все же не в том , работает ли синхронизация сама по себе , а насколько хорошо или хуже система работает при использовании синхронизации. На него нужно дать ответ.

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

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

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

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