Итак, тема с огромными потерями пакетов, бешеным джиттером, цикличными скачками задержки каждые несколько секунд и проблемой совместимости нового MacBook Pro 2019 16" с NanoHD APhttps://community.ui.com/questions/NanoHD-Connection-issues-with-2019-MacBook-Pro/9439ff47-dd50-4bd1-95e1-8f091f4c6979 заблокирована без ясного ответа, как это исправить и когда ждать решение.
Похоже, проблема уходит, если отключить MIMO, но для этого нужна какая-то закрытая версия прошивки.
Типичные симптомы — пинги на роутер выглядят так:
ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=1.862 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.454 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=32.037 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=80.529 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=126.153 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=172.842 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=217.666 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=1.375 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=1.339 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=4.440 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=2.059 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=8.316 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=64 time=1.566 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=64 time=1.372 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=64 time=6.908 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=64 time=12.790 ms
64 bytes from 192.168.1.2: icmp_seq=16 ttl=64 time=35.485 ms
64 bytes from 192.168.1.2: icmp_seq=17 ttl=64 time=78.795 ms
64 bytes from 192.168.1.2: icmp_seq=18 ttl=64 time=1.797 ms
64 bytes from 192.168.1.2: icmp_seq=19 ttl=64 time=1.557 ms
64 bytes from 192.168.1.2: icmp_seq=20 ttl=64 time=1.478 ms
64 bytes from 192.168.1.2: icmp_seq=21 ttl=64 time=1.646 ms
64 bytes from 192.168.1.2: icmp_seq=22 ttl=64 time=1.258 ms
64 bytes from 192.168.1.2: icmp_seq=23 ttl=64 time=1.922 ms
64 bytes from 192.168.1.2: icmp_seq=24 ttl=64 time=12.100 ms
64 bytes from 192.168.1.2: icmp_seq=25 ttl=64 time=59.210 ms
64 bytes from 192.168.1.2: icmp_seq=26 ttl=64 time=104.132 ms
64 bytes from 192.168.1.2: icmp_seq=27 ttl=64 time=148.409 ms
64 bytes from 192.168.1.2: icmp_seq=28 ttl=64 time=195.838 ms
64 bytes from 192.168.1.2: icmp_seq=29 ttl=64 time=23.460 ms
64 bytes from 192.168.1.2: icmp_seq=30 ttl=64 time=447.936 ms
Последствия: куча проблем во время видеоконференций и голосовых звонков, как минимум. У меня NanoHD едва тянет 2 Мбит в устойчивом режиме, чтобы хоть как-то работать с приложениями, где важна скорость и стабильность связи.
Лично у меня, как только я заменил этот AP на AP-AC-LR, все проблемы исчезли — всё работает просто отлично. Статистика с iperf3 греет душу:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 119 MBytes 99.8 Mbits/sec 0.000 ms 0/85832 (0%) sender
[ 5] 0.00-10.00 sec 119 MBytes 99.4 Mbits/sec 0.020 ms 0/85832 (0%) receiver
Хотелось бы просто заменить этот NanoHD на ещё один AC-LR и забыть об этой проблеме. Похоже, Ubiquiti уже признаёт эту проблему, она уходит, когда отключаешь MIMO, и мне бы хотелось хотя бы знать, когда её исправят и есть ли временное решение. AC-LR у меня работает, но хотелось бы, чтобы и NanoHD тоже работал нормально, пока Ubiquiti не починят этот баг.
Похоже, проблема уходит, если отключить MIMO, но для этого нужна какая-то закрытая версия прошивки.
Типичные симптомы — пинги на роутер выглядят так:
ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=1.862 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=1.454 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=32.037 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=80.529 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=126.153 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=172.842 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=217.666 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=1.375 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=1.339 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=4.440 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=2.059 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=8.316 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=64 time=1.566 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=64 time=1.372 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=64 time=6.908 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=64 time=12.790 ms
64 bytes from 192.168.1.2: icmp_seq=16 ttl=64 time=35.485 ms
64 bytes from 192.168.1.2: icmp_seq=17 ttl=64 time=78.795 ms
64 bytes from 192.168.1.2: icmp_seq=18 ttl=64 time=1.797 ms
64 bytes from 192.168.1.2: icmp_seq=19 ttl=64 time=1.557 ms
64 bytes from 192.168.1.2: icmp_seq=20 ttl=64 time=1.478 ms
64 bytes from 192.168.1.2: icmp_seq=21 ttl=64 time=1.646 ms
64 bytes from 192.168.1.2: icmp_seq=22 ttl=64 time=1.258 ms
64 bytes from 192.168.1.2: icmp_seq=23 ttl=64 time=1.922 ms
64 bytes from 192.168.1.2: icmp_seq=24 ttl=64 time=12.100 ms
64 bytes from 192.168.1.2: icmp_seq=25 ttl=64 time=59.210 ms
64 bytes from 192.168.1.2: icmp_seq=26 ttl=64 time=104.132 ms
64 bytes from 192.168.1.2: icmp_seq=27 ttl=64 time=148.409 ms
64 bytes from 192.168.1.2: icmp_seq=28 ttl=64 time=195.838 ms
64 bytes from 192.168.1.2: icmp_seq=29 ttl=64 time=23.460 ms
64 bytes from 192.168.1.2: icmp_seq=30 ttl=64 time=447.936 ms
Последствия: куча проблем во время видеоконференций и голосовых звонков, как минимум. У меня NanoHD едва тянет 2 Мбит в устойчивом режиме, чтобы хоть как-то работать с приложениями, где важна скорость и стабильность связи.
Лично у меня, как только я заменил этот AP на AP-AC-LR, все проблемы исчезли — всё работает просто отлично. Статистика с iperf3 греет душу:
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 119 MBytes 99.8 Mbits/sec 0.000 ms 0/85832 (0%) sender
[ 5] 0.00-10.00 sec 119 MBytes 99.4 Mbits/sec 0.020 ms 0/85832 (0%) receiver
Хотелось бы просто заменить этот NanoHD на ещё один AC-LR и забыть об этой проблеме. Похоже, Ubiquiti уже признаёт эту проблему, она уходит, когда отключаешь MIMO, и мне бы хотелось хотя бы знать, когда её исправят и есть ли временное решение. AC-LR у меня работает, но хотелось бы, чтобы и NanoHD тоже работал нормально, пока Ubiquiti не починят этот баг.
