Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Высокие повторные попытки TX и время пинга., wifiman
 
Привет, у меня очень высокие TX-ретраи, даже на точках доступа, к которым подключено очень мало или вообще нет клиентов. Два смартфона подключены к SSID только на 5 ГГц, а все остальные устройства – только на 2,4 ГГц. Использую GA контроллер и GA прошивку. Есть ли что-нибудь, что я могу сделать, чтобы уменьшить эти ретраи? Меня смущает, что точка доступа без подключенных клиентов имеет самое большое количество TX-ретраев.
 
Я уже пять дней работаю с тремя точками доступа U6-LR, 2 проводные и 1 в меше. Все NanoHD и U6-Lite убраны. Ни один из клиентов не зафиксирован за какой-либо точкой доступа. U6-LR обеспечивают покрытие большей части помещений, хотя на окраинах покрытие всё ещё не очень хорошее. На данный момент, TX retries во всех диапазонах и на всех 3 точках доступа в зеленой зоне, подключено около 200 клиентов. Сейчас я не использую smokeping, поэтому не отслеживаю время пинга. Но подсветка кажется отзывчивой в комнатах с хорошим покрытием. Всё ещё большое количество клиентов в красной зоне по уровню сигнала, около 65 штук, между -81 и -96 dBm. Ещё около 30 клиентов находятся между -76 и -80 dBm. В основном это из-за того, что клиенты ошибочно подключились к дальним точкам доступа. Я думаю, что самая большая проблема — это ограничение количества клиентов на точку доступа. После отключения двух из трех U6-LR, я выяснил, что этот лимит ровно 120 клиентов. Все дополнительные подключения к 2.4 GHz IOT SSID систематически отклоняются, даже те, которые идут от моего смартфона с прямой видимостью на точку доступа в 3 метрах. Я подал заявку в Ubiquiti, чтобы снять это ограничение. Эти устройства IOT потребляют очень мало трафика, и обрабатывать 200+ не должно быть проблемой. Спецификации говорят, что U6-LR поддерживает 350+ клиентов. И даже NanoHD и U6-Lite заявляют как минимум 200. Я думаю, что это ограничение в 120 клиентов на точку доступа играет роль в том, что клиенты подключаются к дальним точкам доступа. Если ближайшая точка доступа отклоняет подключение, они подключатся к другим точкам доступа. И, к сожалению, останутся там. Я не считаю функцию блокировки практичной из-за проблем с управлением — блокировки не отображаются в списке клиентов в контроллере. Я думаю, что для решения проблемы подключения клиентов к дальним точкам доступа необходимо снять это ограничение на количество клиентов на точку доступа. Не знаю, будет ли это исправление достаточным. Даже после того, как ограничение на количество клиентов на точку доступа будет исправлено, мне потребуется подключить дополнительные точки доступа для полного покрытия. У меня всё ещё есть 4-я U6-LR в коробке. И, конечно же, существующие 5 x NanoHD и 1 x U6-Lite. Я тестировал до 9 точек доступа (2 проводные, 2 в меше) в разных местах. Покрытие было лучше, но TX retries значительно увеличились. Я рассматриваю возможность прокладки проводов для дополнительных точек доступа, чтобы уменьшить использование меша для покрытия. Это должно уменьшить количество ситуаций, когда клиенты подключаются к дальним точкам доступа, которые происходят при перезагрузке uplinks. Но это будет как минимум проект на $5K из-за очень длинных кабельных каналов, высоты, покраски и т.д. Было бы намного дешевле перейти к другому производителю Wi-Fi без этого ограничения на количество клиентов на точку доступа и с более качественным мешем. Я пока не настолько продвинулся в исследовании других производителей, чтобы понять, какие из них могут подойти. Думаю, TP-Link Omada может быть одним из вариантов. Я бы гораздо предпочёл, чтобы Unifi исправили ограничение на количество клиентов, чем заниматься этим.
 
Знаю, это не научный подход, но так и произошло. Не хочу снова возвращаться к этому. Вчера я забрал 4 U6-LR в Central Computers. А сегодня – 4 инжектора 802.3at, lol. Не подумал, что они не идут в комплекте.

Я сделал бэкап моей UniFi-настройки с 5 Nanos + 1 U6-Lite, и там куча заблокированных устройств. Потом я отключил все AP, чтобы снять блокировки с клиентов.

Установил первый U6-LR AP в своем домашнем офисе, по проводу, совсем один, без mesh, с выключенными всеми остальными AP. Все выглядело неплохо, когда я включал цепи освещения. 20 лампочек в домашнем кинотеатре включались и выключались быстро, синхронно. А потом я продолжал нажимать все больше и больше выключателей, чтобы включить еще больше лампочек. Настоящий бардак начался, когда в контроллере появилось около 120 клиентов. Мой Android-телефон больше не мог подключиться к SSID IOT. Выдавал ошибку аутентификации. Ни одна из лампочек от дополнительных включенных цепей не появилась в контроллере. Пиковое число клиентов, которое я видел, было, кажется, 155, но не все работали корректно.

Только что воткнул NanoHD в баре, рядом с офисом. Он работает в режиме mesh, так как нет проводки. Общее число клиентов в контроллере сейчас около 180. Мой телефон S22 Ultra по-прежнему не может подключиться к SSID IOT из моего офиса. Все еще выдает "ошибка подключения" из-за ошибки аутентификации. Я только что пошел в бар рядом с Nano. Он может подключиться к SSID IOT на Nano, но телефон предупреждает, что он "подключен без интернета". Однако, если запустить Ookla speedtest, видно, что это не так – интернет есть.

Похоже, что есть какой-то жесткий предел на количество клиентов 2.4 GHz на AP. Это полностью противоречит спецификациям для любого из этих AP. Возможно, указанные числа относятся к клиентам 5 GHz, но их у меня всего несколько штук, так что я бы никогда не столкнулся с каким-то пределом. Я не совсем уверен, как это решить, не прибегая к очень трудоемкому процессу блокировки каждого клиента к самому "лучшему" AP, который не всегда самый близкий по расстоянию. Попробую распределить имеющиеся Nanos и U6-Lite, чтобы улучшить плотность AP. У меня еще 3 U6-LR в коробке. Скорее всего, открою хотя бы один, чтобы посмотреть, сможет ли mesh между этажами работать немного быстрее, чем между двумя Nanos.
 
Ты это уже упоминал, и это кажется действительно странным. SSID-per-AP должно быть вполне приемлемым решением, чтобы лампочки не взаимодействовали с другими точками доступа, не нужно так уж придираться к уровням TX. Я понимаю твое желание не перенастраивать все эти лампочки снова… но… должно было сработать, а "локальная сеть развалилась" — это довольно непрофессиональный отчет о том, что пошло не так. Немного думаю про пересылаемые циклы, но это всего лишь догадка.
 
Спасибо. Лампы видят несколько точек доступа, но судя по данным, которые я выкладывал ранее, они, кажется, не переходят между точками доступа. Хотя они иногда и выбирают не ту точку доступа и остаются с ней. Я использую функцию "закрепить за точкой доступа", чтобы предотвратить это, кажется, это помогает. Я продолжу добавлять закрепления. Однако очень сложно отслеживать, так как контроллер не показывает статус закрепления ни в одном списке клиентов. Интерфейс пользователя действительно очень бедный в отношении этой функции. Я также пробовал создать одну сеть для каждой точки доступа и подключить каждую лампу к сети, соответствующей ближайшей точке доступа. Это привело к полному провалу. Вся беспроводная сеть развалилась, некоторые сети не удавалось подключить даже с телефона, сети отображались как имеющие недоступный Интернет, хотя он был включен. Я больше не буду двигаться по этому пути, по крайней мере, с моими текущими точками доступа. У меня нет ничего от Apple, только ПК и Android-телефоны. Я бы действительно предпочёл что-то текстовое. Wifi Explorer, похоже, нет в Google Play Store. Однако есть WifiMan. Кажется, он справляется с делом довольно хорошо. В моем офисе он показывает, что Comcast XB8 всё ещё транслирует скрытые сети на всех диапазонах. И сигнал перекрывает NanoHD. Там не должно быть никакого трафика, хотя. Я собираюсь пройтись по другим комнатам и проверить.
 
Кстати, у тебя включена функция UAPSD для SSID, которые используют эти лампочки? Это напрямую связано с поведением "немного поспать с радио выключенным", о котором я говорю, так что было бы полезно узнать, нравятся ли этим Wiz лампочкам такие настройки.
 
Что показывает UNA, это измерение сигнала от клиента, полученное AP. Это не обязательно хорошо коррелирует с тем, что клиент видит как силу сигнала от AP – мощность Tx с другой стороны отличается, антенны разные и т.д. Более того, это ничего не говорит о том, как клиент воспринимает силу сигнала от других AP, к которым он не подключился. Идеальная ситуация для того, что вы пытаетесь сделать, это чтобы каждый клиент (Wiz bulb) видел только один AP с силой сигнала выше примерно -70dBm. Если он видит больше одного, они могут взаимодействовать друг с другом, рискуя создать проблему перегрузки клиента, которую вы хотите избежать. Так что я думаю, вам нужно понять, сколько сигнала доходит до каждой из ваших ламп от разных AP. У меня нет большого опыта работы со сканерными приложениями. Я попробовал три-четыре на macOS, и из них мой любимый – WiFi Explorer. Возможно, он доступен и на других платформах, не уверен. На iOS я использовал только Apple's Airport Utility. Это более-менее работоспособно, но вывод чисто текстовый, что, на мой взгляд, не очень (хотя вы можете думать иначе). Airport Utility бесплатный, что немаловажно, если вам нужно использовать его для решения разовой проблемы. Я вообще ничего не знаю о том, что хорошего есть на других платформах.
 
И не показывает ли сила сигнала в контроллере, какой сигнал доходит до каждой лампочки? Есть ли какое-то конкретное приложение для обследования участка, которое вы могли бы порекомендовать?
 
Больше точек доступа с меньшей мощностью передачи, теоретически, могли бы помочь. Но чтобы понять, где лучше всего разместить устройства и какую мощность выбрать, нужно провести обследование территории — то есть, установите приложение-сканер Wi-Fi на телефон или ноутбук и пройдитесь по помещению, измеряя уровень сигнала, который достигают все лампочки.
 
У меня этого не было включено. У меня были только отмечены пункты Proxy ARP и улучшение Multicast. Я экспериментировал с контролем минимальной скорости передачи данных. Значение 24 Мбит/с приводило к тому, что некоторые лампочки отключались. 12 Мбит/с пока что, кажется, нормально работает.
 
Да, видел, как устройства засыпают, и у них странные пинги. Пингую телефон с проводной системы, когда телефон заблокирован, и получаю похожие случайные пинги. Меня это не беспокоит. Когда телефон в использовании, время пинга тоже падает. Но вот по поводу того, что я могу включить/выключить свет или изменить цвет в разумное время – вот это уже вызывает опасения. Может, вы и правы, что TX retries — не та метрика, на которую стоит обращать внимание. Время пинга, задержка при обмене данными и потеря пакетов гораздо важнее.

Попробую добавить AP, но не уверен, какие модели выбрать. NanoHD можно найти на ebay примерно за $50, и большинство продавцов принимают возвраты, если это не решит проблему. Могу добавить 2-4 штуки.
 
Хм, я как-то упустил, что можно сортировать список клиентов Radios/Performance по TX Retries. Вот тут посмотрел, и оказывается, что с процентом повторных передач больше 1% отображаются всего несколько клиентов. И это те клиенты, которые большую часть времени "спят". Я раньше заметил, что у некоторых беспроводных клиентов очень нестабильное время отклика на ping, что, я думаю, связано с тем, что, если они в остальном неактивны, они включают свои радиомодули и проверяют наличие входящего трафика только время от времени (может быть, пару раз в секунду). Например, я только что пинговал почти новый MacBook моей жены, пока он был в спящем режиме, и получил время отклика на ping от 40 мс до 925 мс со средним значением 411 мс. Как только она открыла его, время отклика на ping упало ниже 10 мс. Мне раньше не приходило в голову связать это поведение с TX retries, но, наверное, имеет смысл, что AP приходится делать дополнительные повторные передачи со спящим клиентом. Начинаю склоняться к мысли, что вы в основном гоняетесь за миражом, сосредотачиваясь на TX retries (и, в меньшей степени, на времени отклика на ping). Обе эти статистики могут выглядеть ужасно для клиентов, которые не держат свои радиомодули включенными постоянно, но это не обязательно означает, что что-то не так. Думаю, мы выяснили, что у вас слишком много клиентов на одну точку доступа, когда включены все лампочки Wiz, так что, думаю, вам нужно сосредоточиться на исправлении именно этого.
 
Вот перевод сообщения:

Сегодня вот такая картина. Вчера ночью я снизил мощность передатчиков в 2,4 ГГц для 4 точек доступа с мешированием до уровня "низкий". В гараже и ванной комнате у каждой точки доступа очень мало подключенных устройств, но при этом много повторных попыток передачи (TX retries). В спальне и в комнате на этаже подключено по 8 устройств, но с высокими повторными попытками только в первой.

Я впервые за всё время использования Unifi заглянул в раздел "Радио / Производительность". Никогда бы не подумал, что там информация о клиентах. Я всегда был больше сторонником командной строки, а не графического интерфейса. И теперь, с ухудшением зрения, мне стало гораздо сложнее ориентироваться в графических интерфейсах. Впрочем, в этом разделе отображаются повторные попытки передачи (TX retries), чего нет во вкладке "Клиенты". А также показываются скорость загрузки и максимальная физическая скорость (Max PHY rate). К сожалению, данные не в реальном времени, а за последние 24 часа. Это меня немного смущает, ведь во вкладке "Клиенты" можно увидеть силу сигнала в реальном времени, а также узнать, какие клиенты подключены в данный момент. Но в разделе "Производительность" такой возможности нет. По моему мнению, во вкладке "Клиенты" тоже должны отображаться повторные попытки передачи.

Что касается повторных попыток передачи, то у огромного количества клиентов они очень высоки, хотя у многих хороший сигнал. Это всего лишь первая страница, на которой перечислены самые проблемные 40 устройств.  Только на четвертой странице, для устройства #124, процент повторных попыток передачи (TX retries) опускается ниже 20%.  До 10% они опускаются для устройства #164.

Всего 11 клиентов зарегистрированы как совершающие роуминг. Два лидера — смартфоны, когда мы перемещаемся по дому. Смена точки доступа 50-100 раз в день кажется мне чересчур.

Вот устройства, отсортированные по максимальной физической скорости:

Меня очень удивило, что у некоторых ламп такая низкая максимальная физическая скорость. Например, у лампы на верхней строке, на крыльце, она указана как 1 Мбит/с. Это не может быть правдой для устройства Wi-Fi 4. Соседние лампы той же модели указаны с гораздо более высокой максимальной физической скоростью. Значит, это ошибка в отчётности контроллера. Я пытался заменить эту лампу на другую модель, но проблема не исчезла. Я думаю, виновато расположение за кирпичной стеной. В настоящий момент я вообще не могу пропинговать эту лампу, и третью, но могу пинговать остальные пять поблизости.
C:\Windows\System32>ping terrace-ceiling-can1

Pinging terrace-ceiling-can1.localdomain [192.168.101.46] with 32 bytes of data:
Reply from 192.168.101.46: bytes=32 time=51ms TTL=255
Reply from 192.168.101.46: bytes=32 time=68ms TTL=255
Reply from 192.168.101.46: bytes=32 time=81ms TTL=255
Reply from 192.168.101.46: bytes=32 time=98ms TTL=255

Ping statistics for 192.168.101.46:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 51ms, Maximum = 98ms, Average = 74ms

C:\Windows\System32>ping terrace-ceiling-can2

Pinging terrace-ceiling-can2.localdomain [192.168.101.47] with 32 bytes of data:
Reply from 192.168.100.3: Destination host unreachable.
Reply from 192.168.100.3: Destination host unreachable.
Reply from 192.168.100.3: Destination host unreachable.
Reply from 192.168.100.3: Destination host unreachable.

Ping statistics for 192.168.101.47:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\Windows\System32>ping terrace-ceiling-can3

Pinging terrace-ceiling-can3.localdomain [192.168.101.48] with 32 bytes of data:
Reply from 192.168.101.48: bytes=32 time=68ms TTL=255
Reply from 192.168.101.48: bytes=32 time=76ms TTL=255
Reply from 192.168.101.48: bytes=32 time=85ms TTL=255
Reply from 192.168.101.48: bytes=32 time=104ms TTL=255

Ping statistics for 192.168.101.48:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 68ms, Maximum = 104ms, Average = 83ms

C:\Windows\System32>ping terrace-ceiling-can4

Pinging terrace-ceiling-can4.localdomain [192.168.101.49] with 32 bytes of data:
Reply from 192.168.101.49: bytes=32 time=74ms TTL=255
Reply from 192.168.101.49: bytes=32 time=82ms TTL=255
Reply from 192.168.101.49: bytes=32 time=91ms TTL=255
Reply from 192.168.101.49: bytes=32 time=105ms TTL=255

Ping statistics for 192.168.101.49:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 74ms, Maximum = 105ms, Average = 87ms

C:\Windows\System32>ping terrace-ceiling-can5

Pinging terrace-ceiling-can5.localdomain [192.168.101.50] with 32 bytes of data:
Reply from 192.168.101.50: bytes=32 time=69ms TTL=255
Reply from 192.168.101.50: bytes=32 time=77ms TTL=255
Reply from 192.168.101.50: bytes=32 time=86ms TTL=255
Reply from 192.168.101.50: bytes=32 time=95ms TTL=255

Ping statistics for 192.168.101.50:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 69ms, Maximum = 95ms, Average = 80ms

C:\Windows\System32>ping terrace-ceiling-can6

Pinging terrace-ceiling-can6.localdomain [192.168.101.51] with 32 bytes of data:
Reply from 192.168.100.3: Destination host unreachable.
Reply from 192.168.100.3: Destination host unreachable.
Reply from 192.168.100.3: Destination host unreachable.
Reply from 192.168.100.3: Destination host unreachable.

Ping statistics for 192.168.101.51:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\Windows\System32>ping terrace-ceiling-can7

Pinging terrace-ceiling-can7.localdomain [192.168.101.52] with 32 bytes of data:
Reply from 192.168.101.52: bytes=32 time=69ms TTL=255
Reply from 192.168.101.52: bytes=32 time=76ms TTL=255
Reply from 192.168.101.52: bytes=32 time=85ms TTL=255
Reply from 192.168.101.52: bytes=32 time=95ms TTL=255

Ping statistics for 192.168.101.52:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 69ms, Maximum = 95ms, Average = 80ms

C:\Windows\System32>

Возможно, причиной недостижимости двух ламп является то, что пару дней назад я установил минимальную скорость передачи данных на уровне 24 Мбит/с в сети IOT. Я думал, что это поможет уменьшить количество устройств, переходящих на удаленные точки доступа. Думаю, это, возможно, и получилось. Но у многих устройств все равно очень много повторных попыток передачи.
 
По определению, все соединенные точки доступа создают помехи в одном канале. Они работают на одном канале и их сигнал значительно выше -70dBm!
 
Когда мне стоит ожидать помех в mesh-сети? Слишком много точек доступа, слишком близко друг к другу? Возможно, отчетность и вправду неверна. Но когда возникают проблемы, такие как задержки пинга до 4 секунд, я вынужден думать, что дело не только в некорректной отчетности.
 
У меня давно сложилось впечатление, что UniFi APs переоценивают количество повторных передач (Tx retries), если трафика мало. В моем случае квартира длинная и узкая, а основные жилые и рабочие зоны находятся в конце. У меня 3x U6E AP, расположенные вдоль одной длинной стены, все работают с довольно низкой мощностью передачи. Два AP, расположенные по краям, обрабатывают основной трафик, а тот, что посередине, нужен в основном для устранения небольшого "мертвого" места в покрытии; в большинстве случаев он обслуживает всего одного клиента. И у этого клиента отличный сигнал, но все равно этот AP обычно сообщает о заметно большем количестве повторных передач, чем остальные. Думаю, это связано с взаимодействием с клиентами, которые находятся на краю зоны его действия и в итоге "переключаются" на один из других AP ... или, может быть, эти повторные передачи просто призраки? У @madbrain 's гаражного AP, кажется, происходит что-то похожее.

ДОБАВЛЕНИЕ: Чтобы подкрепить это впечатление, вот моя текущая панель Radios: Забавно, что AP, сообщающие о большом количестве повторных передач, как раз те, у которых минимальный трафик. Показатели трафика за 24 часа выглядят вполне реалистично.
 
Ты прав. Проблема с избыточным количеством мешей не проявится на 2.4 ГГц, но со временем возникнут проблемы на 5 ГГц из-за всех этих конфликтов на одном канале.  Я вслух размышляю, может ли это быть связано с плохой прошивкой/отчетом контроллера? Захват пакетов был бы полезен.
 
1) Спасибо за ответ. Моя локация изолирована, но не сельская – скорее пригородная. Население составляет около 3300 человек на квадратную милю. Рядом со мной, на холме, есть ферма. Однажды стадо коз вырвалось в окрестности и начало есть траву у всех. Животных точно больше, чем людей. Плотность населения очень низкая. Мы не можем голосовать лично, так как в нашем избирательном округе зарегистрировано менее 200 избирателей. Учитывая всю эту изоляцию, меня очень удивляет, что извне наблюдается такое сильное Wi-Fi помехи. Например, прямо сейчас Garage AP имеет только одного клиента. У клиента 0% повторных попыток, хороший RSSI и близкий к максимальным скоростям Tx/Rx, которые поддерживает устройство. И тем не менее, AP, к которому он подключен, испытывает 26,8% повторных попыток на частоте 2,4 ГГц. И 0% повторных попыток на 5 ГГц.

2) re: поиск устройств, вызывающих помехи, к сожалению, контроллер не позволяет отображать повторные попытки в виде столбца. Мне пришлось бы нажать на каждый из 300+ устройств, чтобы выяснить это, что непрактично. Контроллер отображает сигнал и скорость Tx/Rx, поэтому я могу сузить круг поиска и затем проверить повторные попытки. Спасибо за MCS карту.

3) re: больше AP, я не вижу, как проводное или мешочное соединение может существенно повлиять на ситуацию. Повторные попытки на частоте 5 ГГц низкие на всех 6 AP, как проводных, так и мешочных. Например, Garage AP работает по мешочному соединению и имеет 0% повторных попыток на частоте 5 ГГц. Это все кажется мне логичным, поскольку в большинстве случаев подключено всего два клиента на частоте 5 ГГц — смартфоны, и они обычно не потребляют много трафика. Вероятно, не более 30 Мбит/с для потокового видео, и редко оба телефона делают это одновременно. Единственное, когда трафик превышает этот показатель, — это когда я запускаю Ookla speedtest или iperf3 с телефона. По сути, частота 5 ГГц почти полностью посвящена мешочному соединению, для передачи данных с Ethernet-устройств и IoT-устройств, которые не могут подключиться к проводному AP. Я также использую два непересекающихся канала шириной 80 МГц для мешочного соединения — один с 2 AP (проводной родитель/мешочный ребенок) на канале 149, и 4 на канале 36 (проводной родитель/мешочный ребенок/мешочный ребенок+родитель/мешочный ребенок). Я разделил их таким образом, а не 3 и 3, из-за расположения и силы сигнала. Поэтому я сомневаюсь, что частота 5 ГГц является ограничивающим фактором для повторных попыток и высокого пинга на частоте 2,4 ГГц. Использование проводных AP вместо мешочных соединений позволило бы обойти очень неприятные ошибки приоритета uplink, которые преследуют эти AP на протяжении многих лет, но я не вижу, как они решат эту конкретную проблему на частоте 2,4 ГГц. У нас есть один телефон и один ноутбук, совместимые с AX. Ноутбук в основном подключен к док-станции и использует Ethernet, и редко используется. Мой телефон поддерживает AX, но я использую его только в режиме AC. SSID 5 ГГц работает только на 5 NanoHD, поддерживающих AC. Он не работает на U6-Lite в гараже, поддерживающем AX. Этот гаражный AP предназначен только для IoT-устройств. По сути, AX не имеет никакого отношения к этому случаю, и я бы не стал платить больше за AP только ради поддержки AX или BE. Огорчительно слышать, что нет Unifi AP, которые лучше работают на частоте 2,4 ГГц, чем NanoHD или U6-Lite. Это ограничено ли предложениями Ubiquiti, или есть ли другие производители, на которых мне следует обратить внимание?
 
MCS в контроллере указан как PHY, что немного сбивает с толку старика вроде меня. Я понимаю PHY как физические возможности устройства, например, 1x1 802.11n и т.д. Прошу прощения за путаницу. Если вы не находитесь в каком-то отдалённом сельском районе, то часто встречается много помех 2G, и контроллер не всегда хорошо это показывает. Конкретные нарушители – это всё, что имеет более 10% повторных попыток, не отличное качество соединения, низкий MCS и, что особенно, не соответствует RSSI – смотрите график ниже. Больше точек доступа было бы неплохо, особенно если они проводные. Я не могу предсказать, что получится, если они будут mesh, но думаю, что результат будет не очень. К сожалению, нет точек доступа, которые действительно лучше других на 2,4 ГГц, если только ваши устройства не совместимы с AX, тогда бы я сказал, что U6-Pro – это минимум. U6-LR и AC-HD не будут отличаться от nanoHDs, которые у вас сейчас, несмотря на характеристики. C
 
Да, проблемы похожи в приложении Wiz для Android. Я вижу много ламп, которые появляются и исчезают в сети, пока смотрю приложение. Те, что отмечены как "в сети", нельзя контролировать, и Wiz даже не пытается связаться с лампой в этом случае. Интеграция Wiz с Home Assistant все еще пытается, и если лампы временно подключаются, они реально включаются/выключаются/меняют цвет. HA, видимо, использует более длимый таймаут. Иногда возникают ошибки с лампами, особенно с большой группой, например, с группой "весь дом". Помогает, что у 90% моих ламп настроены статические DHCP-резервирования. В списке дел нужно все-таки пофиксить последние 10%. Это довольно длинный перечень MAC-адресов, IP-адресов и описаний. Процесс добавления ламп в приложение Wiz, контроллер Unifi (для комментариев/описаний) и, наконец, pfSense для DHCP-резервирований, в основном ручной. Интерфейсы Unifi и pfSense просто не подходят для добавления большого количества устройств сразу. Ну и есть smokeping. Я написал немного кода для экспорта DHCP-резервирований pfSense в smokeping (я включаю и выключаю эту службу, она не причина повторных подключений или высокого пинга). Я начал писать код для синхронизации данных между pfSense и Unifi, но еще не закончил. И я до сих пор не уверен, какой алгоритм слияния использовать, потому что в обоих источниках есть частичные данные, нет единой правды.

Что касается Home Assistant, я запускал его ранее на Raspberry Pi, и на 3B, и на 4B. Но было просто слишком медленно, особенно I/O, даже на SSD. Резервные копии/восстановления были, наверное, самой большой проблемой. Я не мог допустить, чтобы система простаивала больше 1 часа при восстановлении. Также, все становилось медленнее с увеличением количества IoT-устройств. Сейчас HA показывает 562 устройства, включая Wifi, Ethernet, Z-Wave и Yolink. Некоторые из 562 - виртуальные/программные устройства. Я отфильтровал интеграции, которые являются реальным оборудованием, и нашел в сумме 456. Думаю, даже Raspberry Pi 5 может испытывать трудности.

Я запускаю HA под VMWare уже два года. Виртуальной машине выделено 4 ядра и 8 ГБ ОЗУ. Процессор - AMD 5700G APU. Хост также работает с несколькими другими серверами, такими как контроллер Unifi, Plex, JRiver Media Center. Недавно пришлось увеличить ОЗУ с 16 ГБ до 32 ГБ, потому что оно слегка превышало 16 ГБ. Просто позаимствовал несколько планок DDR4 из других систем, которые используются реже (HTPC). Операционная система хоста была Win10 Pro, а недавно обновилась до Win11 Pro. Система работала совершенно безвентиляторно с Noctua NH-D15, примерно 3 месяца назад. Как только я начал заниматься ресурсоемкими задачами с видео, хост начал сбоить. Я установил один большой кулер Noctua для процессора. Система все равно работает очень тихо, и я очень чувствителен к шуму. Пришлось заменить мои 10-гигабитные коммутаторы на бесшумные модели, потому что маленькие вентиляторы были слишком громкими. Они все вышли из строя по гарантии TP-Link на всю жизнь и были заменены бесплатно. Я буду заменять их по мере возможности, потому что никогда не смогу купить коммутатор с маленьким вентилятором.
Страницы: 1 2 След.
Читают тему (гостей: 2)