Bắt đầu từ đích đến, không đặt ngưỡng chung
Với game nhanh, thời gian khứ hồi thấp và ổn định tới máy chủ game thực tế thường có lợi. Các khoảng dưới đây là hướng dẫn biên tập để so sánh, không phải tiêu chuẩn chính thức hay bảo đảm cho từng game.
| Thời gian khứ hồi | Diễn giải tham khảo |
|---|---|
| Dưới 50 ms | Mục tiêu trễ thấp cho tương tác nhanh. |
| 50–100 ms | Có thể chơi được; kiểm tra game và độ ổn định. |
| 100–150 ms | Trễ có thể rõ hơn trong game nhanh. |
| Trên 150 ms | Thường kém nhạy hơn nhưng không chứng minh kết nối hỏng. |
Không dùng bảng làm yêu cầu chung cho cuộc gọi hay xem video. Cuộc gọi còn phụ thuộc dao động, mất gói và bộ đệm; video tải đệm trước phụ thuộc lớn vào thông lượng và ổn định. Một kết quả trình duyệt không bảo đảm trải nghiệm.
Ping, độ trễ và ổn định
Lệnh ping thông thường dùng echo ICMP. RTT gồm chiều đi và về. Chia đôi không xác định đáng tin cậy trễ một chiều vì tuyến đường và hàng đợi có thể khác nhau. Mbps là dung lượng truyền, không phải độ trễ tính bằng ms.
Dao động thường gọi là jitter; mất gói là chỉ số khác. Ghi cả đích và phương pháp vì công cụ có thể tính thống kê khác nhau.
IPdidi thực sự đo gì
Bài kiểm tra ping gửi 2 yêu cầu khởi động rồi thực hiện 40 phép đo HTTP đến /ping.txt tại nút Cloudflare phục vụ trang. Nó không gửi ICMP và không đo máy chủ game.
Thông thường dùng khoảng requestStart đến responseStart, có thể gồm xử lý máy chủ. Khi không có dữ liệu này, dùng thời gian fetch gồm cả đọc phản hồi. Không bảo đảm RTT mạng thuần túy.
Jitter hiển thị là trung bình độ thay đổi tuyệt đối giữa các mẫu thành công liền kề. Hết thời gian hoặc lỗi HTTP là mẫu thất bại, không phải tỷ lệ mất gói IP. Đánh giá theo mục đích là quy tắc kinh nghiệm của trang. Mô tả dựa trên kiểm tra mã nguồn, không phải thử nghiệm đường truyền hay thiết bị của bạn.
So sánh cùng điều kiện
- Ghi đích, công cụ, giờ, Wi-Fi hoặc dây, VPN, trung bình, dao động và lỗi.
- Lặp lại khi nhàn rỗi và lúc tải lên hoặc xuống thông thường, giữ nguyên đích và phương pháp.
- Nếu được, so sánh Ethernet và Wi-Fi để tách ảnh hưởng vô tuyến, không bảo đảm số thấp hơn.
- Xem chẩn đoán trong game hoặc ứng dụng gọi. Kết quả tốt tới một nút không loại trừ lỗi cục bộ, tuyến, máy chủ hay ứng dụng trong tình huống khác.
Để so ICMP, chạy ping example.com trong terminal và dừng bằng Ctrl+C nếu tiếp tục. Đích có thể lọc echo; không trả lời không chứng minh dịch vụ ngừng.
Thay một yếu tố rồi đo lại
- Tạm dừng truyền tệp lớn và sao lưu để kiểm tra hàng đợi khi có tải.
- So vị trí Wi-Fi, băng tần hoặc kênh ít bận hơn; 5 GHz không luôn tốt hơn khi xuyên tường hay ở xa.
- So vùng game phù hợp và VPN bật/tắt trong cùng hoạt động. VPN hoặc gói cước nhanh hơn không bảo đảm trễ thấp.
- Nếu bộ định tuyến có quản lý hàng đợi, làm theo tài liệu chính thức. Nó có thể giảm chờ, không xóa khoảng cách truyền.
- Nếu vẫn lỗi, gửi hỗ trợ đích, giờ và kết quả nhàn rỗi/có tải, không chỉ số thấp nhất.
Dùng cùng bài kiểm tra trước và sau. Không kết luận nguyên nhân chỉ từ chênh lệch hai đích khác nhau.
Câu hỏi thường gặp
100 ms luôn là xấu?
Tùy hoạt động, đích, giao thức và độ ổn định. Đây là số đo để phân tích, không phải ngưỡng đạt chung.
Lỗi HTTP có phải mất gói?
Không. Có nhiều nguyên nhân và bài kiểm tra không xác định tỷ lệ mất gói mạng.
Vì sao game hiện số khác?
Đích, lưu lượng và xử lý khác nhau. So chẩn đoán của ứng dụng thay vì trừ các số không liên quan.
Nguồn và phạm vi
Bài viết giải thích chỉ số và quy trình so sánh, không khẳng định đã tìm ra lỗi đường truyền hay thử thiết bị cụ thể.
Ngày kiểm tra nguồn: 2026-11-05.