可接受延迟计算器
VoIP的最大RTT和Jitter,游戏,流线,视频会议等等.
申请和延迟( 可选)
目录
综合可接受延迟指南
无论是在VoIP的电话,在线播放,流传,还是在视频会话中,你连接的响应性取决于两个关键度量:延迟(通常被测量为RTT)和紧张. 本指南解释它们是什么,每种用途可接受哪些价值,如何衡量,以及在它们太高时如何改进经验.
为什么用这个计算器?
计算器为您推荐了每个应用程序类型的最大RTT和快活度。 您可以只查看引用值, 或者输入当前 RTT 和 jitter( 从速度测试、 游戏或 VoIP 诊断), 以查看您的连接是否在 VoIP 、 游戏、 流媒体、 视频会议、 远程桌面 或 普通网络 使用的可接受限度内 。
计算器是如何工作的
选择一个应用程序类型(例如:VoIP,竞争性游戏,视频会议). 计算器以毫秒显示推荐的最大RTT和焦急值。 如果您输入了所测量的RTT 和 jitter, 它会将它们与这些限制进行比较, 并表明您的数值是否可接受或高于推荐值 。
- RTT( 路由时间): 时间以毫秒计,一个包可以去服务器和返回。 游戏中常被称作"平". 下调更适合实时应用.
- 抖动: 包之间延迟变化 。 高度焦躁会导致口吃,语音中失学,或不稳定的游戏游戏,即使平均RTT是确定的.
- 包丢失: 从未到来的包裹 质量受损;目标在1岁以下%. 这个计算器侧重于 RTT 和 jitter 。
- 实时对缓冲: 声音,视频通话和竞技游戏需要低调的RTT和焦躁. 由于缓冲,点播流能容忍更长时间.
实时对缓冲应用程序
实时(对延迟敏感)
- VoIP 电视会议 竞技游戏 直播
- 需要低RTT( < 50–150 ms 取决于使用量)和低活泼( < 20–40 ms) 。
- 每多出一毫分,影响感知质量和反应时间.
缓冲( 不太敏感 )
- 点播视频,下载,一般网络浏览.
- RTT & lt; 200 ms 通常都很好; 初始负载和控制从更低的延迟度中获益.
- Bandwidth一旦开始缓冲,往往比RTT更重要.
检查延迟的好处
- 诊断问题: 了解您的RTT 或 jitter 是否高于推荐的使用限制 。
- 设定预期: 了解"好"对VoIP,游戏或视频通话意味着什么.
- 选择服务器/ 区域: 选择最接近的游戏或VoIP服务器以停留在限制范围内.
- 计划升级: 决定是否需要不同的连接或QoS来满足实时要求.
限制和考虑
- 建议的数值是准则;一些用户容忍稍高的耐久性,而竞争性使用可能要求较低.
- 延迟到速度测试服务器可能从延迟到实际的游戏或VoIP提供者——衡量到您使用的服务不同.
- 包丢失不包含在这个计算器中;高损失即使使用可接受的RTT和jitter也会降低质量.
- Wi-Fi,拥堵,以及白天的时间都会影响结果;在与您实际使用相似的条件下进行测试.
测量 RTT 和 抖动到您使用的实际服务( game 服务器, VoIP 提供者, 视频平台), 不仅仅是对通用速度测试主机 。 可能时使用有线以太网;Wi-Fi会增加耐久和紧张. 如果数据包丢失率高, 则该计算器也会以RTT 和 jitter 为重点。
快速引用( 最大 RTT / 抖动)
VoIP:RTT < 150 ms, jitter < 30 ms. 竞技游戏:RTT < 50 ms, jitter < 20 ms. 电视会议:RTT < 150 ms, jitter < 30 ms. 点播流:RTT < 200 ms. 完整清单见以下参考表和建议各节。
RTT和焦躁决定你对语音、视频和游戏的感受 使用此计算器为您的应用程序获取推荐限制, 用下面的工具测量您的实际值, 如果您高于推荐范围, 则应用排除故障的步骤 。 把有线以太网和最接近的服务器列为最佳体验.
RTT 和 Jitter 解释
RTT和jitter是决定你如何反应和稳定的连接感的两个主要衡量标准. 下面我们精确地定义它们,以及它们与包丢失和应用类型的关系。
什么是RTT(Rund-Trip时间)?
RTT 是一个包从设备到服务器( 或对等端) 和返回的时间, 以毫秒计 。 它直接影响应用程序的应答感受:语音呼叫,游戏,和视频通话都需要低RTT才能有良好的体验. 高RTT会导致明显的延迟(例如在VoIP)或滞后(例如在游戏中).
在游戏和网络工具中,RTT常被称作"平". 单向延迟大约是RTT的一半(假设对称路径);对于实时应用来说,回回转的事务,因为您的动作必须到达服务器,而响应必须在看到结果之前返回.
什么是吉特吗?
慢速是数据包之间的延迟变化 。 即使平均耐久性是可以接受的,高活性也会造成送货不均匀:一些包裹来得晚,导致口吃,语音失传,或者游戏游戏不稳定. 应用程序使用焦急缓冲来平滑,但太多焦急仍然会降低质量.
焦特一般以毫秒(ms)表示. 它可以被计算为连续的RTT测量之间的相差,也可以被计算为单向延迟的标准偏差. VoIP和视频应用经常在统计或诊断中报告紧张.
包装损失和延迟
包丢失(从未到来的包)也伤害了实时质量. 高损失导致语音漏洞,被冷冻的视频,或被再传送,从而会增加有效的延迟. 良好的连接有低RTT、低快感和最小的包损失(例如低于1)%). (中文(简体) ). 此计算器侧重于RTT 和 jitter; 如果您的应用程序显示高数据包丢失, 请考虑检查您的链接和路由器 。
为什么它很重要 通过应用
实时应用(VoIP,游戏,视频会议)对RTT和jitter都敏感. 点播视频流能因缓冲而容忍更长时间;有竞争力的游戏和活生生的互动需要最低值.
是什么影响延缓和紧张?
几个因素影响RTT和焦躁. 理解它们可以帮助你选择正确的改进——从切换到以太网到选择更接近的服务器或启用QoS.
- 距离和路线: 数据传输速度有限。 您和服务器之间的物理距离,以及网络 hop的数量,直接影响到RTT. 选择更接近您的服务器或区域会降低延迟度.
- Wi-Fi vs以太网: Wi-Fi增加了可变的延迟和与其他设备的争论,这既会增加耐用性,也会增加焦急性. 有线以太网通常给出更低更稳定的RTT和快活.
- 摄取: 当链接或路由器繁忙时,包会排队等待,会增加延迟和变异. 在同一条连接上大量下载或流出,可以提高空闲和紧张度,用于实时交通.
- 路由器和调制解调器: 旧的或超载的设备可以添加处理延迟和缓冲bloat(大队列会给耐久性造成突起). 升级或调试路由器(如QoS,缓冲限制)可以有所帮助.
- ISP和骨干: 您的互联网提供者与服务路径( game 服务器, VoIP 提供者等) 确定基线 RTT. 一些ISP或计划优化以达到低延迟;而另一些则可能有更拥挤或间接的路线.
- 无线和移动: 与固定宽带相比,手机和远程Wi-Fi的延迟性通常更高,更可变. 4G/5G可被临时使用所接受,但对于竞技游戏或专业VoIP来说往往并不理想.
按用法提出建议
使用这些限制作为您测量的RTT 和 jitter 的目标 。 停留在或低于它们通常为每种应用类型提供了良好的经验。
- 维普: RTT < 150 ms and jitter < 30 ms 用于清晰,自然的对话. 此外,拖延和砍伤也变得明显。
- 竞争性游戏: RTT < 50 ms and low jitter (< 20 ms). 每毫秒数反应时间。
- 临时游戏: RTT < 100 ms 通常为细; jitter < 50 ms 为避免结巴.
- 视频流(按需): 缓冲性事项较少;初始负载和控制(例如寻求)受益于RTT < 200 ms.
- 实时流/ 交互式: 与VoIP/video会议类似:RTT < 150 ms, jitter < 40 ms.
- 电视会议: RTT < 150 ms, jitter < 30 ms 用于平滑音频和视频同步.
- 远程桌面: RTT < 100 ms和低焦距用于响应光标和输入.
- 一般网页: RTT < 200 ms是舒适的; 更高的值使页面感觉缓慢.
参考表(最大RTT和抖动(以毫秒计))
这些是计算器使用的同值. 将您测量的RTT 和 jitter 比较到匹配您的应用程序的行 。
| 应用 | 最大RTT( 毫秒) | 最大焦点( 毫秒) |
|---|---|---|
| VoIP | 150 | 30 |
| Gaming (competitive) | 50 | 20 |
| Gaming (casual) | 100 | 50 |
| Video streaming (on-demand) | 200 | 50 |
| Live streaming / interactive | 150 | 40 |
| Video conferencing | 150 | 30 |
| Remote desktop | 100 | 30 |
| General web browsing | 200 | 50 |
如何测量RTT和抖动
测量 RTT 和 对您使用的相同服务( game 服务器、 VoIP 提供者等) 。 泛指随机主机可能无法反映您的应用程序路径 。
在游戏或网络工具中,RTT经常被报告为"平". 使用 ping( ICMP) 或针对您使用的服务( 如游戏服务器, VoIP 提供者) 的专用速度/纬度测试 。 注意: ping to a 随机主机并不总是反映您实际应用程序服务器的路径.
工具和方法
- 平 (命令行): 在 Windows 打开命令提示并运行: ping -n 20 例.com. 在Mac/Linux上: ping-c 20 example.com (中文(简体) ). 结果以ms表示分/avg/最大RTT. 从分数到分数的相差可以估计出慢跑。
- 速度测试网站: Speedtest.net或Fast.com等网站经常会报道"潜伏"(平),有时会发抖. 在不同时间运行多个测试;对测试服务器的延迟性可能因游戏或VoIP服务的不同而不同.
- 游戏中播放: 许多游戏向游戏服务器显示ping或latency. 这是与该应用程序最相关的RTT. 通过选择适当的用法(如竞技或随意游戏)与这个计算器一起使用.
- VoIP和视频应用统计: 诸如Zoom,Teams,Discord,或VoIP手机等Apps经常在设置或呼叫时显示RTT,jitter和包丢失. 这些值反映了服务服务器的路径,是检查VoIP或视像会议限制的理想.
- 追踪路由: Traceroute (tracert on Windows) 显示每个跳到目的地和每个跳的延迟. 它有助于确定引入延缓性的地方(例如,在你的ISP或遥远的骨干上)。
对于最准确的图片,在白天和条件与您实际使用时同时运行测试(例如其他人使用网络).
解决高纬度和紧张的问题
如果您的RTT 或 jitter 值高于推荐值, 请按顺序尝试这些步骤 。 从以太网开始并减少并行流量;然后调整服务器的选择和路由器设置.
- 在Wi-Fi上切换到有线以太网. 仅此而已,往往会大大地减少延迟和紧张。
- 停止或暂停重下载,流,或云备份在同一连接上,同时需要低潜.
- 重新启动您的调制解调器和路由器 。 清除队列和可能引发突起的临时问题.
- 在游戏或应用程序中选择最接近的服务器或区域(例如同一个国家或大陆).
- 在可用路由器上启用 QoS( 服务质量) 。 将游戏、VoIP或电视会议列为优先,
- 更新路由器固件并检查缓冲器。 一些路由器有"Smart Que"或类似的功能来限制队列的积分并减少快克.
- 如果您在 DSL 或 有线电视上, 请确保不出现行问题( 噪音, 错误的过滤器) 。 联系您的ISP 进行行检, 如果延迟度一直很高 。
- 对于游戏或VoIP,考虑与低纬度特征(如纤维,或以游戏/VoIP性能而出名的ISP)相接. 并非所有的计划在延迟方面都是平等的。
如果问题持续存在,则运行追踪和追踪您的应用程序使用的确切主机,并与您的ISP或支持共享结果;它们往往可以识别出有问题的部分。
延迟对带宽
延迟和带宽不同:一是延迟,一是吞吐量. 对于实时应用来说,低延迟通常比原始速度更重要.
Bandwidth(如Mbps)是指您每秒可以发送或接收多少数据. Lattency(RTT)是单包往返需要多长时间. 它们是独立的:你可以拥有高带宽和高耐用,或者低带宽和低耐用.
对于实时应用(VoIP,游戏,视频通话),低延迟比原始带宽更重要. 与30 ms RTT的20 Mbps连接,比起与150 ms RTT的100 Mbps连接,对于呼叫和游戏,感觉要好得多. 就下载和缓冲流而言,一旦延迟是合理的,带宽就更加重要。
当为VoIP/gaming选择互联网计划或优化时,优先排序低而稳定的潜伏;使用这个计算器的极限作为目标,并检查您实际的RTT和抖动到您使用的服务.
最佳做法
这些做法有助于使RTT和焦躁情绪保持在语音、视频和游戏的可接受限度内。
- 可能时使用有线以太网;Wi-Fi会增加耐久和紧张.
- 游戏时或在VoIP上关闭带宽重的应用程序(流线,下载).
- 为游戏和VoIP选择一个接近您的服务器或区域来减少RTT.
- 您的路由器上的服务质量(QoS)可以优先处理实时流量并减少紧张.
- 此计算器中的值是准则;一些用户可能容忍稍高的延迟,而竞争性使用则可能需要更低.
- 测量您使用的实际服务( game 服务器, VoIP 提供者) 的延迟度, 而不仅仅是通用速度测试服务器 。
- 测试时间和负载与实际使用相同,以获得具有代表性的RTT和jitter.
- 对于视频通话,使用有线连接并关闭其他视频流;如果可用的话,可以在应用程序中启用"硬件加速"来减少处理延迟.