是最近才发现的,起因是玩游戏总是高 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 time=10.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 1 天前
排除法:
1. 接有线 ping ,如果延迟稳定则下一步,否则跳转到步骤 4 2. 断掉所有只支持 ac 的设备 3. 切换到 20MHz 并选择一个空闲的信道 4. 扔垃圾桶 不过话又说回来,硬件坏了的概率很低,大概率还是干扰导致。 |
2
1423 1 天前
5. 20 包邮出给我
|
3
datocp 1 天前 via Android
游戏想玩得好,
那要求可是相当高, 做好 qos 的主路由,解决延迟和流量的对比关系,保证游戏以最高优先级插队上传 使用稳定的有线连接。 如果非得使用无线,那就让无线 ap 仅连一个无线终端,不然因为其它终端呑吐导致的延迟波动,这么多年了能把有线做到 95%的饱合流量依然可以保证延迟,无线无解。 |
![]() |
4
thinkever 23 小时 49 分钟前
小米路由器小问题很多……有时候还要设备不兼容的问题
|
![]() |
5
kokutou 22 小时 16 分钟前 via Android
你电脑的 WiFi 网卡太烂了。
打游戏请插网线,没有 WiFi 可以满足稳定 ping 小于 1ms |
![]() |
6
datiewang 22 小时 9 分钟前
我家是红米 AX6000 ,把主路由改到光猫上,红米只当 AP 来用网络波动能小一些,之前稳定过多少秒就掉一次包,怀疑是温度太高了。
|
![]() |
7
xdeng 21 小时 32 分钟前
用网线吧 WiFi 的无线干扰不可控
|
![]() |
8
Vesc 21 小时 30 分钟前
好像小米 AX6000 ,不如红米那个 AX6000 吧
|
![]() |
9
keyfunc 21 小时 8 分钟前
我把 ax6000 当 ap 用,蛮稳定的
|
10
mariolee 20 小时 0 分钟前 via iPhone
mesh 是无线回传还是有线,这个差很多
|
11
shihao9618 19 小时 52 分钟前
5. 20 包邮出给我
|
12
datocp 19 小时 41 分钟前
无线延迟问题多了
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 以下。 |