这是一个创建于 35 天前的主题，其中的信息可能已经有所发展或是发生改变。
是最近才发现的，起因是玩游戏总是高 ping 掉线断联我还以为是网络问题，结果今天排查发现，本地到路由器 ping 都很高
64 bytes from 192.168.31.1: icmp_seq=0 ttl=64 time=15.236 ms 64 bytes from 192.168.31.1: icmp_seq=1 ttl=64 time10.819 ms 64 bytes from 192.168.31.1: icmp_seq=2 ttl=64 time=11.668 ms 64 bytes from 192.168.31.1: icmp_seq=3 ttl=64 time=12.141 ms 64 bytes from 192.168.31.1: icmp_seq=4 ttl=64 time=6.485 ms 64 bytes from 192.168.31.1: icmp_seq=5 ttl=64 time=10.856 ms 64 bytes from 192.168.31.1: icmp_seq=6 ttl=64 time=8.989 ms 64 bytes from 192.168.31.1: icmp_seq=7 ttl=64 time=11.736 ms 64 bytes from 192.168.31.1: icmp_seq=8 ttl=64 time=12.545 ms 64 bytes from 192.168.31.1: icmp_seq=9 ttl=64 time=10.390 ms 64 bytes from 192.168.31.1: icmp_seq=10 ttl=64 time=12.788 ms 64 bytes from 192.168.31.1: icmp_seq=11 ttl=64 time=11.264 ms 64 bytes from 192.168.31.1: icmp_seq=12 ttl=64 time=9.515 ms 64 bytes from 192.168.31.1: icmp_seq=13 ttl=64 time=11.421 ms 64 bytes from 192.168.31.1: icmp_seq=14 ttl=64 time=13.224 ms 64 bytes from 192.168.31.1: icmp_seq=15 ttl=64 time=6.221 ms 64 bytes from 192.168.31.1: icmp_seq=16 ttl=64 time=276.621 ms 64 bytes from 192.168.31.1: icmp_seq=17 ttl=64 time=98.717 ms 64 bytes from 192.168.31.1: icmp_seq=18 ttl=64 time=520.851 ms 64 bytes from 192.168.31.1: icmp_seq=19 ttl=64 time=35.755 ms 64 bytes from 192.168.31.1: icmp_seq=20 ttl=64 time=253.896 ms 64 bytes from 192.168.31.1: icmp_seq=21 ttl=64 time=90.308 ms 64 bytes from 192.168.31.1: icmp_seq=22 ttl=64 time=11.186 ms 64 bytes from 192.168.31.1: icmp_seq=23 ttl=64 time=224.148 ms 64 bytes from 192.168.31.1: icmp_seq=24 ttl=64 time=36.539 ms 64 bytes from 192.168.31.1: icmp_seq=25 ttl=64 time=56.401 ms 大约链接了 31 台设备，ping 的时候负载很低，是连接的设备太多了吗？有 10 多台设备都是虚拟机，有线连接的另外一个红米路由器，然后红米路由器作为 Mesh 节点使用的
ping 的这台设备是直接连接的主路由器 5G WIFI ，用 Mesh 连接的虚拟机也 ping 过，一样的结果，很奇怪
 | 1 FabricPath 35 天前 排除法： 1. 接有线 ping ，如果延迟稳定则下一步，否则跳转到步骤 4 2. 断掉所有只支持 ac 的设备 3. 切换到 20MHz 并选择一个空闲的信道 4. 扔垃圾桶 不过话又说回来，硬件坏了的概率很低，大概率还是干扰导致。 |
 | 2 slowman 35 天前 5. 20 包邮出给我 |
 | 3 datocp 35 天前 via Android 游戏想玩得好， 那要求可是相当高， 做好 qos 的主路由，解决延迟和流量的对比关系，保证游戏以最高优先级插队上传 使用稳定的有线连接。 如果非得使用无线，那就让无线 ap 仅连一个无线终端，不然因为其它终端吐导致的延迟波动，这么多年了能把有线做到 95%的饱合流量依然可以保证延迟，无线无解。 |
 | 4 thinkever 35 天前 小米路由器小问题很多……有时候还要设备不兼容的问题 |
 | 5 kokutou 35 天前 via Android 你电脑的 WiFi 网卡太烂了。 打游戏请插网线，没有 WiFi 可以满足稳定 ping 小于 1ms |
 | 6 datiewang 35 天前 我家是红米 AX6000 ，把主路由改到光猫上，红米只当 AP 来用网络波动能小一些，之前稳定过多少秒就掉一次包，怀疑是温度太高了。 |
 | 7 xdeng 35 天前 用网线吧 WiFi 的无线干扰不可控 |
 | 8 Vesc 35 天前 好像小米 AX6000 ，不如红米那个 AX6000 吧 |
 | 9 keyfunc 35 天前 我把 ax6000 当 ap 用，蛮稳定的 |
 | 10 mariolee 35 天前 via iPhone mesh 是无线回传还是有线，这个差很多 |
 | 11 shihao9618 35 天前 5. 20 包邮出给我 |
| 12 datocp 35 天前 无线延迟问题多了 1.2.4G 的 1/6/11 信道错开要求，把 2 个同样信道的无线设备摆在一起，丢包丢得不敢相信。嗯门口的公安那个什么设备似乎也会干扰。在一些办公楼附近 63 个 SSID ，怎么都无法避免干扰。 2.至于 5G 一直使用 149 ，有些信道会引起流量变化 3.wifi5 时代，常见的多终端接在 1 个 AP 上，因为终端的信号强度问题，导致的 1 个 100mbps 吐的 AP 只剩下 50kb/s 的能力。那些有线上时刻保证 100mbps 的 QOS 规则，到了无线它的保证带宽就变成 50kb-1.25MB 的波动，延迟当然无法保障。看起来无线的延迟，和终端距离 AP 的距离无关，并不是 1 米之内的终端就有好的延迟。个人觉得弱信号踢除就是最好的优化方式，但它的前提是多 AP 覆盖，不能在最边缘的 AP 上不然踢了连，连了踢。过多的终端负载，像 88 个终端在线，一道非常简单的除法题，带宽变窄引起的延迟变大。甚至会出现 128MB 的 AP 内存过度消耗而引起死机。 测试周围信道，避开信道干扰，1 个 AP 只连 1 个终端就是玩游戏的最优解。当然主路由能更针对性的做 QOS ，更是能让延迟低到 19ms 以下，而且是一个稳定的 19ms 以下。 |
Select Language