Cloud gaming phụ thuộc vào gì? Hiểu ping, jitter, FPS và tốc độ mạng

Mạng 300 Mbps, ping chỉ hơn 20 ms nhưng xoay camera vẫn khựng. FPS trong game báo cao mà hình trên điện thoại không mượt. Tăng bitrate thì hình rõ hơn, nhưng thỉnh thoảng điều khiển lại nặng tay. Những tình huống này không mâu thuẫn: cloud gaming phụ thuộc vào cả đường truyền, máy chạy game, cách truyền video và thiết bị nhận hình.

Bài này giải thích từng chỉ số để bạn biết lúc nào cần hạ bitrate, lúc nào nên kiểm tra Wi-Fi, lúc nào lỗi nằm ở FPS game hoặc giải mã. Điểm cần phân biệt từ đầu: hình rõ, chuyển động đều và phản hồi nhanh là ba mục tiêu khác nhau. Một phiên chơi có thể làm tốt mục này nhưng chưa tốt mục khác.

1. Một nút bấm phải đi qua những gì?

Khi chơi trên Pyra, game chạy trong máy cloud. Thiết bị của bạn gửi thao tác lên, rồi nhận video và âm thanh để hiển thị. Đường đi có thể hình dung như sau:

1. Thiết bị nhận thao tác: tay cầm, chuột, bàn phím hoặc nút cảm ứng tạo tín hiệu.
2. Thao tác đi tới cloud: qua mạng nội bộ, nhà mạng và tuyến tới máy chơi.
3. Game xử lý và dựng hình: CPU/GPU xử lý lượt cập nhật tiếp theo, có thể phải chờ hàng đợi.
4. Khung hình được thu và mã hóa: encoder nén thành video để truyền.
5. Video đi về thiết bị: gói tin có thể đến không đều, đến muộn hoặc bị mất; bên nhận xử lý theo cơ chế của phiên.
6. Thiết bị giải mã và hiển thị: video được mở, căn nhịp và đưa ra màn hình.

Độ trễ từ lúc bấm đến lúc thấy phản ứng thường gọi là input-to-photon latency. Nó bao gồm nhiều phần hơn ping. Các giai đoạn có thể chồng lấp; không cộng tùy tiện mọi số trong bảng thông số vì có những phép đo đã bao hàm giai đoạn khác. NVIDIA giải thích các thành phần độ trễ hệ thống.

Với game online còn có một tuyến nữa: máy Pyra ↔ máy chủ của game. Ping hiện bên trong một trận online thường mô tả tuyến này, còn ping của phiên stream mô tả kết nối tới phía cloud. Hai số không thay thế cho nhau. Có thể hình truyền về rất mượt nhưng nhân vật vẫn bị kéo lại do kết nối với server game, hoặc ngược lại.

2. Đọc nhanh: mỗi thông số trả lời câu hỏi nào?

• Băng thông, Mbps: đường truyền chuyển được bao nhiêu dữ liệu trong một giây?
• Bitrate, Mb/s: luồng video đang dùng hoặc được cấu hình dùng bao nhiêu dữ liệu mỗi giây?
• Ping/RTT, ms: một lượt đi và về của phép đo mất bao lâu?
• Jitter, ms: độ trễ hoặc thời điểm gói tới biến động đến mức nào, theo cách tính của công cụ?
• Packet loss, %: có bao nhiêu gói không tới được hoặc không nhận được phản hồi trong phép đo?
• FPS và frametime: có bao nhiêu khung hình, và chúng được tạo ra đều hay không?
• Encode/decode, ms: mất bao lâu để nén và mở hình?
• Dropped frames: khung hình bị bỏ ở giai đoạn nào, trong khoảng thời gian nào?
• Hz, V-Sync và display latency: màn hình có thể trình bày hình mới ra sao?

Đừng tìm một con số “chấm điểm tất cả”. Muốn biết vì sao một pha xử lý bị khựng, cần xem các chỉ số cùng thời điểm triệu chứng xảy ra, thay vì chụp bảng thông số sau khi mọi thứ đã bình thường.

Bảng tra nhanh: ping, jitter và mất gói

Xanh: thuận lợi; vàng: cần theo dõi; đỏ: dễ chậm hoặc khựng. Các mức mạng bên dưới bám mốc tham khảo của Test mạng Pyra tại ngày 19/10/2026, không phải ranh giới tuyệt đối cho mọi game. Dùng RTT p95, jitter và mất probe của cùng bài test; đừng áp thẳng sang công cụ có cách đo khác.

Mốc đọc nhanh: RTT p95 ≤40 ms thuận lợi, >40–90 ms cần theo dõi, >90 ms dễ chậm tay. Jitter ≤8 ms thuận lợi, >8–20 ms cần theo dõi, >20 ms dễ khựng. Mất probe nên hướng tới 0%; 0–0,5% là mức thấp, >0,5–2% cần theo dõi, >2% cần ưu tiên kiểm tra kết nối. Một chỉ số xanh không bảo đảm cả phiên mượt.

Bảng tra nhanh: FPS game và FPS stream

Mốc FPS game tham khảo: ≥60 FPS đều là điểm bắt đầu tốt; 30–59 FPS ít mượt hơn nhưng có thể hợp game chậm; <30 FPS hoặc tụt mạnh thường dễ cảm thấy giật. Với stream đặt 60 FPS, quan sát tốc độ thực tế có ổn định gần mục tiêu và có bỏ khung không. Chủ động chọn 30 FPS đều khác với đặt 60 nhưng liên tục tụt xuống 30.

Chỉnh đúng chỗ: FPS game thấp → giảm đồ họa trong game, xem CPU/GPU/frametime; game vẫn mượt nhưng stream khựng → xem mạng, bitrate, codec và giải mã. Trên Pyra Desktop, mở Cài đặt → Hình ảnh để đổi FPS/bitrate/codec nếu phiên bản và gói cho phép. Khi thử, chỉ đổi một mục; lưu tiến độ trước nếu cần kết nối lại. Hạ bitrate có thể giảm nghẽn nhưng không xóa độ trễ do khoảng cách hay tuyến mạng.

3. Tốc độ mạng và bitrate: đủ lượng dữ liệu chưa chắc đủ ổn định

Mbps của gói Internet khác bitrate của phiên chơi

Gói Internet nói về khả năng đường truyền trong điều kiện nhất định. Speed test đo thông lượng tới máy chủ test. Bitrate là mức dữ liệu video của phiên chơi, hoặc mức đặt trong ứng dụng; số thực đo và số cấu hình không nhất thiết giống hệt nhau.

Ví dụ một phiên đặt 25 Mb/s không có nghĩa dùng mạng quảng cáo 25 Mbps là chắc chắn vừa đủ. Còn âm thanh, điều khiển, phần đóng gói mạng, cơ chế bảo vệ dữ liệu nếu có, tải của thiết bị khác và các khoảng băng thông bị hụt. Ngược lại, đường truyền 500 Mbps cũng không chữa được một thiết bị giải mã chậm.

Mb/s và MB/s khác nhau: 1 byte = 8 bit, nên 25 Mb/s tương đương khoảng 3,125 MB/s trước khi tính các phần dữ liệu khác. Khi so với tốc độ tải file trong trình duyệt, hãy kiểm tra chữ b và B.

Vì sao cần chừa băng thông?

Giả sử tại chỗ ngồi của bạn, thông lượng ổn định tới tuyến liên quan chỉ khoảng 35 Mbps. Đặt video 30 Mb/s sẽ chừa ít khoảng trống hơn đặt 20 Mb/s. Một tải nền hoặc dao động Wi-Fi có thể khiến gói phải xếp hàng, tới muộn hoặc bị bỏ.

Có thể dùng mức đặt video thấp hơn thông lượng đo được để bắt đầu thử, chẳng hạn khoảng 60–70% nếu công cụ cho chỉnh. Đây là điểm bắt đầu thử nghiệm, không phải công thức đảm bảo mượt: một kết quả speed test ngắn vẫn có thể không đại diện cho đường truyền trong trận.

Nếu hạ bitrate làm hết khựng, đó là dấu hiệu đường truyền hoặc khả năng xử lý luồng đang thiếu khoảng trống; chưa đủ để kết luận chính xác lỗi ở nhà mạng. Hãy so sánh tiếp bằng Ethernet hoặc Wi-Fi khác.

Tăng bitrate giúp hình rõ đến đâu?

Với cùng điều kiện nén, bitrate cao hơn thường cho phép giữ nhiều chi tiết hơn. Cây cỏ, mưa, khói, film grain và cảnh xoay nhanh khó nén hơn một menu đứng yên. Nhưng nâng bitrate chỉ hữu ích khi mạng và thiết bị nhận theo kịp.

Độ phân giải, FPS, nội dung cảnh và codec đều ảnh hưởng lượng dữ liệu cần thiết. Vì vậy không có một bitrate duy nhất đúng cho mọi game. Nếu vấn đề chính là hình bệt khi di chuyển, xem thêm hướng dẫn chỉnh độ rõ hình ảnh; nếu đang giật, ưu tiên tìm chỗ nghẽn trước khi tăng chất lượng.

4. Ping/RTT: đo khoảng cách thời gian, không đo toàn bộ cảm giác tay

RTT (round-trip time) là thời gian một lượt đi và về. Nó chịu ảnh hưởng của khoảng cách, tuyến mạng, hàng đợi, thiết bị mạng và cách công cụ gửi/nhận phản hồi. Ping tới một máy chủ speed test gần bạn không nhất thiết phản ánh ping tới Pyra.

Không lấy RTT chia hai rồi coi đó là độ trễ một chiều chính xác: đường đi và đường về có thể không đối xứng. Cũng không cộng thêm một RTT nữa chỉ vì video có chiều về; cần biết phép đo đang mô tả phần nào.

Ví dụ mô hình: giả sử phần đi-về tương ứng của thao tác và video mất khoảng 30 ms, tổng chờ xử lý/dựng hình là 14 ms, thu và mã hóa 5 ms, bộ đệm/giải mã/hiển thị thêm 20 ms. Độ trễ cảm nhận trong mô hình có thể quanh 69 ms, dù mạng chỉ hiện 30 ms. Đây là phép cộng minh họa các thành phần không chồng lấp, không phải kết quả đo Pyra.

Nhìn trung vị, p95 và cú vọt

Một giá trị thường gặp thấp có thể che các thời điểm tệ. p50 là trung vị. p95 là mức mà khoảng 95% mẫu trong tập không vượt quá; nó không phải giá trị lớn nhất và vẫn bỏ qua khoảng 5% mẫu cao hơn.

Hai kết nối cùng trung vị 25 ms có thể cho cảm giác khác nhau: một đường giữ quanh 24–28 ms, đường kia thường là 25 ms nhưng thỉnh thoảng vọt lên 150 ms. Khi ngắm bắn hoặc căn thời điểm, các cú vọt ngắn đó quan trọng hơn một con số trung bình đẹp.

Ping thấp hơn nhìn chung thuận lợi hơn cho phản hồi, nhưng ngưỡng “chấp nhận được” phụ thuộc thể loại, độ nhạy của người chơi và phần trễ còn lại. Không lấy yêu cầu ping của một dịch vụ cloud khác làm cam kết cho Pyra.

5. Jitter: đến không đều khiến bạn giật dù ping thấp

Jitter là mức biến động về thời gian tới hoặc độ trễ. Hình dung các gói được gửi đều, nhưng tới thiết bị thành từng cụm: lúc nhanh, lúc phải chờ. Nếu khung hình chưa có đủ dữ liệu vào thời điểm cần hiển thị, người chơi có thể thấy khựng hoặc phải nhìn lại hình cũ.

Ví dụ chuỗi độ trễ 20, 21, 20, 22 ms đều hơn chuỗi 12, 38, 15, 55 ms. Không chỉ nhìn số trung bình; thứ tự và mức biến động có ý nghĩa.

Quan trọng: không phải mọi số mang tên jitter đều cùng một phép đo. Jitter giữa các gói video theo RTP khác với độ chênh của các mẫu ping liên tiếp, và cũng khác độ dao động RTT do thư viện mạng báo. RFC 3550 định nghĩa jitter của RTP. Khi so trước/sau, giữ cùng công cụ, tuyến đo và khoảng quan sát.

Bộ đệm giúp đều hình nhưng có thể tăng độ trễ

Bên nhận có thể chờ thêm để các gói đến lệch nhau vẫn ghép thành hình. Chờ đủ giúp phát đều hơn, nhưng làm hình bạn nhìn thấy cũ hơn so với hiện tại ở cloud. Giảm thời gian chờ có thể cải thiện phản hồi trên mạng ổn định, nhưng cũng có thể làm lộ rõ gói đến trễ trên mạng xấu.

Vì vậy, “video mượt” chưa đồng nghĩa “input nhanh”. Một bộ đệm lớn có thể che dao động bằng cách thêm độ trễ. Ngược lại, hình khựng chưa chứng minh FPS game thấp. Không tự tìm một nút chỉnh buffer nếu phiên bản Pyra của bạn không cung cấp.

6. Mất gói và gói đến trễ: vì sao hình có thể đứng hoặc vỡ?

Video được chia thành nhiều gói. Mất dữ liệu có thể làm thiếu một phần khung hình hoặc ảnh hưởng những khung hình tham chiếu nó. Tùy cơ chế truyền và khôi phục, bạn có thể thấy hình lỗi, bỏ khung, đứng ngắn hoặc chờ khung hình phục hồi.

Cùng 1% mất gói chưa chắc cùng trải nghiệm. Mất rải rác khác với mất liên tiếp trong một khoảng ngắn. Việc mất ở gói chứa phần quan trọng, thời điểm tới và khả năng sửa lỗi cũng ảnh hưởng kết quả. Không suy rằng 1% mất gói đồng nghĩa 1% khung hình hỏng.

Cơ chế gửi lại hoặc dữ liệu sửa lỗi (FEC), nếu được dùng, có thể giúp khôi phục nhưng có đánh đổi: cần thêm dữ liệu hoặc thời gian. Gói được khôi phục sau hạn hiển thị vẫn có thể không còn hữu ích cho thời gian thực.

0,0% không phải chứng minh tuyệt đối không có lỗi: số có thể được làm tròn, chỉ bao phủ một khoảng đo, hoặc đo mất phản hồi của probe thay vì gói video. Gói tới đầy đủ nhưng quá trễ vẫn có thể khiến bỏ hình. Cần biết phạm vi phép đo.

Mất gói có thể đến từ Wi-Fi, dây/cổng mạng, thiết bị quá tải, nhà mạng hoặc tuyến tới cloud. Thử Ethernet giúp loại bớt một biến, nhưng không được kết luận cứ vượt một tỷ lệ là chắc chắn Wi-Fi có lỗi.

7. FPS game, FPS stream và Hz màn hình: ba con số riêng biệt

FPS game: máy cloud đang tạo hình nhanh đến đâu?

FPS trong game do trò chơi và máy cloud quyết định: CPU, GPU, VRAM, cảnh đang chơi, độ phân giải, hiệu ứng và giới hạn FPS. Khi nó tụt, nâng gói Internet không làm CPU/GPU dựng hình nhanh hơn. Đọc thêm vì sao cùng cấu hình nhưng các game cho FPS khác nhau.

FPS stream: bạn nhận được bao nhiêu khung hình?

FPS đặt trong ứng dụng là mục tiêu. Tốc độ thu/mã hóa, nhận, giải mã và trình bày thực tế có thể khác nhau. Một bảng thông số ghi FPS có thể đang đếm khung giải mã hoặc khung trình bày, không phải FPS bên trong game.

Ví dụ game dựng 120 FPS nhưng stream chỉ truyền 60 FPS thì người xem không nhận đủ 120 khung mới mỗi giây. Nếu game chỉ tạo 40 FPS trong một stream 60 FPS, luồng có thể lặp lại hình; số stream 60 không biến nguồn thành 60 hình game độc lập.

FPS game cao hơn mức stream đôi khi vẫn ảnh hưởng độ mới của khung được thu và phản hồi, nhưng không suy ra rằng tăng không giới hạn luôn tốt. GPU quá tải hoặc hàng đợi dài có thể làm tăng trễ. Hãy xem cả frametime và độ ổn định.

Frametime và 1% low: đều nhịp quan trọng thế nào?

Khoảng thời gian trung bình tương ứng một khung hình được tính bằng 1000 ÷ FPS:

• 30 FPS: khoảng 33,3 ms mỗi khung.
• 60 FPS: khoảng 16,7 ms mỗi khung.
• 90 FPS: khoảng 11,1 ms mỗi khung.
• 120 FPS: khoảng 8,3 ms mỗi khung.

Một game trung bình 60 FPS nhưng xen các khung 70–100 ms vẫn có thể khựng. Biểu đồ frametime giúp thấy vấn đề đó. Chỉ số 1% low mô tả phía chậm của phân bố khung hình, nhưng cách tính khác nhau theo công cụ; so sánh trong cùng phương pháp.

Các khoảng 16,7 hay 8,3 ms là nhịp khung hình, không phải tổng input lag. Không lấy 120 FPS rồi kết luận độ trễ toàn phiên chỉ 8,3 ms.

Hz màn hình: có trình bày được từng khung mới không?

Màn 60 Hz không thể hiển thị 120 lần làm tươi hoàn chỉnh mỗi giây. Màn 120 Hz lại không tự tạo đủ 120 khung mới nếu game hoặc stream chỉ có 60. Để hưởng lợi từ chế độ FPS cao, phải kiểm tra cả game, stream, khả năng thiết bị và tần số quét đang thực sự bật.

Chế độ tiết kiệm pin, nhiệt độ, màn hình ngoài/cáp hoặc cài đặt hệ điều hành có thể giới hạn tần số đang dùng. Với TV, chế độ Game Mode giúp giảm một số xử lý hình ảnh; tính năng làm mượt chuyển động không thay thế cho nguồn FPS cao.

8. Encode, decode và dropped frames: máy cá nhân vẫn có việc phải làm

Mã hóa ở cloud, giải mã ở thiết bị

Encoder nén khung hình ở cloud; decoder mở video trên laptop, điện thoại hoặc TV. Cloud gaming giảm yêu cầu tự chạy game, nhưng thiết bị vẫn phải giải mã và hiển thị luồng ở độ phân giải/FPS đã chọn.

H.264, HEVC và AV1 là các lựa chọn codec có thể gặp. Hiệu quả nén, khả năng tương thích và hỗ trợ phần cứng khác nhau theo thiết bị. Codec nén hiệu quả hơn có thể giữ chất lượng ở bitrate thấp hơn trong những điều kiện phù hợp; nhưng nếu thiết bị phải giải mã bằng CPU chậm, kết quả có thể kém hơn codec được tăng tốc phần cứng. Tài liệu codec của MDN.

Dấu hiệu nên xem thiết bị nhận: cùng mạng và cùng phiên, laptop A mượt nhưng điện thoại B khựng; hoặc giảm độ phân giải/FPS làm hình đều hơn trong khi ping không đổi. Khi đó kiểm tra codec, nhiệt, chế độ pin và ứng dụng, thay vì chỉ tăng tốc độ Internet.

Decode 12 ms có tốt không?

Cần đặt cạnh mục tiêu FPS và cách thống kê. Trung bình giải mã 12 ms/khung có thể là phần tải đáng kể ở 60 FPS (nhịp 16,7 ms), và càng đáng kiểm tra ở 120 FPS (nhịp 8,3 ms). Tuy vậy không lấy hai số đó làm phép kiểm tra đạt/trượt tuyệt đối: hàng đợi, song song hóa, phần cứng và việc khung có kịp trình bày đều quan trọng.

Chỉ số trung bình tích lũy cũng có thể che các cú giải mã chậm. Nếu công cụ hiển thị tổng thời gian giải mã từ đầu phiên, nó không phải độ trễ hiện tại của một khung. W3C phân biệt các bộ đếm giải mã, bỏ khung và bộ đệm.

Dropped frames không đồng nghĩa packet loss

Khung hình có thể bị bỏ vì dữ liệu không hoàn chỉnh, tới muộn, giải mã không kịp hoặc lỡ hạn hiển thị. Vì vậy mạng báo 0% mất gói vẫn có thể có dropped frames. Cần xem tên bộ đếm, nó nằm ở giai đoạn nào và đang là số tích lũy hay tỷ lệ trong vài giây gần nhất.

Với V-Sync hoặc căn nhịp hiển thị, mục tiêu là trình bày đều và giảm xé hình; đánh đổi có thể là thêm thời gian chờ tùy cách triển khai. Đừng mặc định bật hoặc tắt luôn tốt nhất: thử một thay đổi trong cùng cảnh và quan sát cả độ đều lẫn cảm giác tay.

9. Bufferbloat: vì sao đang yên lại lag khi có người tải file?

Đường truyền có thể ping thấp lúc rảnh, nhưng hàng đợi đầy lên khi có tải nặng. Gói điều khiển và video phải chờ phía sau các dữ liệu khác, làm độ trễ tăng. Hiện tượng hàng đợi quá mức này thường được gọi là bufferbloat.

Ví dụ mô phỏng: lúc rảnh ping khoảng 20 ms; khi một thiết bị sao lưu hoặc tải lớn, độ trễ lên 140 ms. Đường truyền vẫn có thể đang tải nhanh, nhưng việc tương tác đã chậm đi. Tải lên cũng đáng kiểm tra: thao tác game dùng ít dữ liệu, song vẫn có thể bị chậm khi uplink bị chiếm kín.

So idle latency với loaded latency mới thấy chênh lệch này. Thử dừng tải nền hoặc giới hạn tốc độ tải để chừa khoảng trống. Router hỗ trợ quản lý hàng đợi như SQM/AQM có thể giúp khi cấu hình phù hợp; một nút QoS bất kỳ không bảo đảm giải quyết được mọi trường hợp. RFC 8290 mô tả quản lý hàng đợi để giảm trễ.

Không chạy bài đo cố tình tải đầy đường truyền giữa một trận quan trọng rồi lấy sự giật do phép thử tạo ra làm kết luận về trạng thái bình thường.

10. Đọc công cụ Test mạng của Pyra cho đúng

Trên Pyra Desktop đã kiểm tra ngày 19/10/2026, vào Cài đặt → Test mạng → Bắt đầu test. Công cụ đo lúc mạng rảnh rồi tạo tải để xem độ trễ khi đường truyền bận. Chạy tại đúng chỗ ngồi và loại kết nối bạn thường chơi.

Ảnh trên là một lượt đo thực tế, dùng để minh họa cách đọc. Nó không đại diện cho mọi nhà mạng, thiết bị, thời điểm hoặc phiên chơi. Trong lượt này, ping hiển thị 27/28 ms, độ dao động 0,6 ms, mất gói 0,0%, nghẽn khi tải +9 ms, nhưng tải xuống đo được chỉ 15,7 Mb/s. Công cụ gợi ý 720p30 ở 9 Mbps. Điều đáng học là ping đều không tự cho phép đẩy chất lượng lên cao.

Các nhãn không nên đọc quá nghĩa

• Ping “thường / lúc tệ nhất”: với cách tính được đối chiếu trong mã nguồn hiện tại, hai số tương ứng p50/p95. “Lúc tệ nhất” ở đây không phải mẫu cao nhất tuyệt đối; vẫn cần xem các cú vọt.
• Độ dao động: bài test tính độ chênh tuyệt đối trung bình giữa các mẫu RTT liên tiếp hợp lệ. Nó hữu ích để so cùng bài test trước/sau, không đồng nhất với jitter gói video RTP.
• Nghẽn khi tải: được ước tính từ p95 lúc tải so với trung vị lúc rảnh, không phải phép đo một chiều của video.
• Mất gói: là tỷ lệ probe không nhận được phản hồi trong bài đo; không tự bằng tỷ lệ gói hình bị mất trong mọi phiên game.
• Đích đo: xem dòng tuyến/đích thực tế. Đo tới Edge là tín hiệu hữu ích về tuyến liên quan; nếu dùng đường đo dự phòng hoặc khác đích, không coi mọi kết quả là cùng đường đi tới đúng máy chơi.
• Mức đề xuất: là gợi ý bắt đầu. Nút chọn preset, giới hạn gói, khả năng thiết bị và FPS game thực tế vẫn cần được kiểm tra trong phiên.

Một số đường đo native còn có thể dùng độ dao động RTT thay cho số jitter video riêng. Do đó nên gửi cả ảnh, tên ứng dụng và phiên bản khi cần hỗ trợ, thay vì chỉ báo “jitter 10” mà không biết đang đọc từ đâu.

Đừng coi màu xanh là lời hứa cho mọi game

Các mốc phân loại của công cụ là quy tắc gợi ý, không phải ngưỡng vật lý tuyệt đối. Chẳng hạn ở logic hiện tại, nhóm tốt yêu cầu đồng thời p95 không quá 40 ms, độ dao động không quá 8 ms, mất probe không quá 0,5%, tải xuống ít nhất 25 Mb/s và mức tăng trễ khi tải dưới 60 ms. Thiếu một phần có thể làm mức gợi ý thay đổi. Các mốc có thể đổi theo phiên bản.

Đạt những mốc đó vẫn chưa kiểm tra được toàn bộ FPS game, decoder hay TV của bạn. Ngược lại, nhãn trung bình không có nghĩa mọi game đều không chơi được; hãy bắt đầu ở mức phù hợp và thử trải nghiệm thật.

11. Quy trình kiểm tra khi chơi giật hoặc phản hồi chậm

1. Ghi đúng triệu chứng: hình khựng, chữ mờ, tiếng đứt, toàn bộ thao tác chậm, hay chỉ nhân vật online bị kéo lại? Ghi game, giờ xảy ra, thiết bị và loại mạng.
2. Chụp thiết lập hiện tại: độ phân giải, FPS mục tiêu, bitrate, codec. Trên Pyra Desktop đã đối chiếu, có mục Hiện thông số và phím mặc định Ctrl + Alt + Shift + S. Chỉ đọc số thực sự có trên bản đang dùng; dấu “—” không phải số 0.
3. Test mạng ngoài trận: xem đích đo, ping, dao động, mất probe và mức nghẽn khi tải. Không đồng thời chạy nhiều speed test.
4. Thử giảm bitrate trước khi kết luận: giữ độ phân giải/FPS, giảm một nấc rồi thử lại cùng cảnh. Hết khựng nhưng hình giảm chi tiết là thông tin về đánh đổi cần thiết.
5. Loại bớt biến không dây: thử Ethernet nếu có, hoặc ngồi gần router trên Wi-Fi 5 GHz; tạm dừng tải nền. Nhiều vạch sóng không chứng minh ít nhiễu hay ít tranh chấp thời gian phát.
6. Kiểm tra game và thiết bị: nếu mạng không đổi, thử giảm đồ họa trong game để xem frametime; thử giảm độ phân giải/FPS stream hoặc codec phù hợp để xem giải mã.
7. So A/B có ghi chép: mỗi lần một thay đổi, cùng cảnh và khoảng thử. Có thể dùng 1–2 phút cho mỗi lần so ban đầu, nhưng lỗi hiếm cần theo dõi lâu hơn. Lưu tiến độ nếu cần kết nối lại để áp dụng cài đặt.

Ghi mẫu đơn giản: giờ → mạng → độ phân giải/FPS/bitrate/codec → chỉ số lúc lỗi → thay đổi đã thử → kết quả. Tốt hơn việc đổi cả codec, bitrate và router rồi không biết yếu tố nào có tác dụng.

12. Nhìn triệu chứng để chọn thứ kiểm tra trước

• Hình khựng từng nhịp, ping thường thấp: xem cú vọt, jitter, mất gói/đến trễ, dropped frames và frametime; không chỉ xem trung bình.
• Hình mượt nhưng điều khiển nặng: xem tổng trễ, hàng đợi/buffer, V-Sync, xử lý TV và thiết bị nhập.
• Đứng yên rõ, xoay camera thì bệt: xem bitrate, codec, độ phân giải và độ phức tạp cảnh; không mặc định GPU đang yếu.
• FPS game tụt nhưng mạng giữ ổn: xem CPU/GPU, đồ họa, VRAM và frametime trong cloud.
• Chỉ một điện thoại/TV bị giật: xem khả năng giải mã, nhiệt, pin, phiên bản ứng dụng và hiển thị.
• Chỉ lag lúc người khác tải/sao lưu: xem loaded latency và nghẽn uplink/downlink.
• Nhân vật online bị kéo lại, giao diện stream vẫn đều: kiểm tra ping và trạng thái server game từ máy cloud, không gộp với ping stream.
• Âm thanh cũng đứt cùng lúc hình: xem sự cố truyền, bộ đệm và tải thiết bị ở cùng thời điểm; riêng triệu chứng này chưa xác định được nguyên nhân.

Đây là hướng khoanh vùng, không phải phép chẩn đoán chắc chắn. Nếu cần hỗ trợ Pyra, gửi mã phiên, thời điểm, ảnh thông số lúc lỗi và các so sánh đã thử. Có thể dùng quay màn hình trên thiết bị cá nhân để giữ đúng lỗi mình nhìn thấy.

Câu hỏi thường gặp

Mạng 100 Mbps có đủ chơi cloud gaming không?

Con số đó chưa đủ để kết luận. Cần biết thông lượng thực tới tuyến liên quan, bitrate định dùng, độ trễ lúc rảnh/lúc tải, jitter, mất gói và khả năng thiết bị. Một đường có tốc độ vừa đủ nhưng đều có thể cho trải nghiệm ổn định hơn đường nhanh trên speed test nhưng dao động mạnh.

Ping thấp rồi thì có cần quan tâm upload không?

Có. Thao tác thường cần ít băng thông hơn video chiều về, nhưng uplink bị chiếm kín vẫn có thể làm tăng trễ. Cũng cần phân biệt tải lên của thiết bị cá nhân với kết nối từ máy cloud tới server game.

120 FPS có luôn tốt hơn 60 FPS không?

120 FPS có thể cung cấp nhịp khung ngắn hơn khi toàn chuỗi đáp ứng. Nhưng chọn 120 trong ứng dụng không bảo đảm game tạo đủ hình, decoder theo kịp hoặc màn hình hiển thị 120 Hz. Nếu chế độ cao khiến bỏ khung hoặc thiếu băng thông, mức thấp hơn mà đều có thể dễ chơi hơn.

Đổi DNS hoặc nâng gói Internet có chữa được mọi loại lag không?

Không. DNS chủ yếu phục vụ tìm địa chỉ khi kết nối, không phải thuốc chữa cho jitter của luồng đã chạy. Nâng băng thông hữu ích khi thiếu thông lượng, nhưng không tự sửa nghẽn hàng đợi, tuyến xa, Wi-Fi nhiễu hay decoder chậm.

Khi tối ưu Pyra, hãy tìm giai đoạn đang làm trải nghiệm xấu đi: thiếu dữ liệu, dữ liệu tới không đều, game dựng chậm, thiết bị mở hình chậm hay màn hình trình bày trễ. Chỉnh đúng giai đoạn đó thường có ích hơn kéo mọi con số lên tối đa. Các nguồn và thông tin sản phẩm được đối chiếu ngày 19/10/2026.