Ketika pemain mengeluh game streaming terasa lambat, tim teknis membutuhkan jawaban yang lebih jelas daripada “ping pengguna tinggi”.
Input lag sebenarnya tersusun dari banyak komponen, mulai dari perangkat input, perjalanan jaringan, simulasi game, rendering GPU, video encoding, jitter buffer, decoding, hingga layar pemain.
Karena itu, Cara Mengukur Input Lag pada layanan skala besar perlu memanfaatkan telemetry yang dapat memecah pipeline tersebut menjadi beberapa bagian.
Dengan pendekatan ini, developer bukan hanya mengetahui berapa besar delay, tetapi juga memahami bagian mana yang harus diperbaiki.
Pecah Input Lag Menjadi Beberapa Komponen
Bayangkan seorang pemain menekan tombol lompat pada controller.
Untuk cloud gaming, input tersebut melalui jalur kira-kira seperti ini:
Client Input → Network → Game Simulation → Rendering → Encoding → Network → Jitter Buffer → Decoding → Display
Setiap tahap memiliki latency sendiri.
Inilah alasan mengapa mengoptimalkan satu metrik belum tentu memperbaiki pengalaman secara signifikan.
Jika network RTT turun 10 ms tetapi encoder membutuhkan tambahan 20 ms karena perubahan konfigurasi kualitas, total latency justru bisa meningkat.
Langkah pertama adalah membuat latency budget untuk masing-masing tahap.
Catat Timestamp pada Titik Penting
Untuk layanan yang dikembangkan sendiri, telemetry dapat ditambahkan pada beberapa event utama.
Client dapat mencatat timestamp ketika input diterima aplikasi. Server kemudian mencatat kapan input sampai, kapan simulation update yang berkaitan selesai, kapan frame selesai dirender, dan kapan frame diberikan kepada encoder.
Client juga dapat mencatat kapan encoded frame diterima dan kapan frame selesai didecode atau dirender ke video element.
Namun ada satu masalah teknis: clock client dan server tidak selalu sinkron sempurna.
Karena itu, jangan langsung mengurangi timestamp dari dua mesin berbeda tanpa sistem sinkronisasi atau koreksi clock. Untuk pengukuran internal pada satu perangkat, gunakan monotonic/high-resolution clock agar perubahan jam sistem tidak merusak data.
Sementara komunikasi lintas perangkat dapat dibantu dengan RTT measurement dan teknik clock synchronization yang memang dirancang untuk sistem terdistribusi.
Gunakan WebRTC getStats untuk Membaca Kondisi Stream
Jika layanan menggunakan WebRTC, Statistics API merupakan salah satu sumber telemetry yang sangat berguna.
Spesifikasi W3C menyediakan berbagai metrik untuk memantau media pipeline dan kondisi network. Di antaranya ada packetsLost, jitter, roundTripTime, framesDecoded, framesRendered, dan statistik jitter buffer.
Metrik tersebut tidak secara otomatis memberikan satu angka bernama “input lag”.
Namun kombinasinya dapat menjelaskan kenapa latency meningkat.
Misalnya, RTT tetap 35 ms tetapi jitterBufferDelay naik drastis. Kondisi tersebut mengindikasikan tambahan delay lebih banyak terjadi pada buffering media dibanding perjalanan network dasar.
W3C mendefinisikan jitterBufferDelay sebagai akumulasi waktu yang dihabiskan sample atau video frame di jitter buffer. Rata-ratanya dapat dihitung dengan membagi nilai tersebut dengan jitterBufferEmittedCount.
Ini merupakan insight yang sulit didapat jika hanya melihat ping.
Pantau RTT, Jitter, dan Packet Loss Bersamaan
RTT rendah memang bagus, tetapi kestabilannya sama pentingnya.
Bayangkan dua koneksi.
Koneksi A memiliki RTT konstan sekitar 45 ms. Koneksi B rata-rata 30 ms tetapi sering melonjak menjadi 120 ms.
Dalam game streaming, koneksi A bisa terasa lebih konsisten karena pipeline tidak harus terus menyesuaikan buffer akibat perubahan jaringan.
WebRTC Statistics API mendefinisikan jitter sebagai variasi timing packet RTP dan menyediakan statistik packet loss serta RTT.
Karena itu, dashboard produksi sebaiknya menampilkan beberapa metrik bersamaan.
Latency tanpa konteks jitter dan loss dapat menghasilkan diagnosis yang keliru.
Ukur Encode dan Decode Time per Frame
Setelah network diperiksa, lihat video pipeline.
Encoding adalah proses mengubah frame hasil render menjadi data video terkompresi. Decoding melakukan kebalikannya di perangkat pemain.
Parsec menyediakan contoh praktis pendekatan ini melalui overlay yang menampilkan decode latency, encode latency, network latency, bitrate, codec, dan resolusi stream.
Jika network hanya membutuhkan 20 ms tetapi encode memakan 14 ms dan decode 18 ms, mengubah region server mungkin bukan prioritas pertama.
Client dengan software decoder juga dapat memiliki performa jauh lebih buruk dibanding hardware decoder. Dokumentasi Parsec secara khusus menyebut software decoding sebagai salah satu penyebab decode latency yang lebih tinggi.
Karena itu, simpan data decoder implementation, codec, resolusi, dan frame rate bersama setiap hasil pengukuran.
Hubungkan Telemetry dengan Resource Server
Input delay terkadang tidak berasal dari jaringan sama sekali.
GPU server mungkin terlalu sibuk.
CPU juga dapat mencapai utilisasi tinggi sehingga game simulation terlambat menyelesaikan sebuah frame.
Amazon GameLift Streams menyediakan performance stats yang mencakup utilisasi CPU, memory, GPU, dan VRAM. Statistik tersebut bisa dikombinasikan dengan WebRTC stats untuk melihat network stats, client frame rate, dan pemanfaatan resource secara bersamaan.
Pendekatan ini sangat berguna.
Misalnya, latency spike selalu muncul saat GPU utilization mendekati batas dan frame capture rate turun. Itu memberikan petunjuk bahwa masalah berada pada compute atau rendering server, bukan ISP pengguna.
Tanpa korelasi telemetry, tim mungkin justru menghabiskan waktu mengoptimalkan jaringan.
Ukur Frame Capture dan Frame Delivery
FPS game server dan FPS yang diterima pemain bisa berbeda.
Game mungkin merender 60 FPS, tetapi hanya 45 frame per detik yang berhasil masuk pipeline streaming secara konsisten.
Amazon GameLift Streams menyediakan FrameCaptureRate sebagai salah satu performance metric selain RTT dan utilisasi resource.
Di sisi WebRTC, metrik seperti framesDecoded, framesRendered, dan framesDropped dapat membantu melihat apa yang terjadi setelah stream mencapai client.
Bandingkan angka tersebut selama periode waktu tertentu.
Jika server menghasilkan frame stabil tetapi client menjatuhkan banyak frame, investigation sebaiknya bergeser ke decoding, browser, GPU client, atau kondisi network.
Pengukuan pipeline seperti ini jauh lebih informatif daripada FPS counter tunggal.
Buat Dashboard Berdasarkan Percentile
Untuk layanan dengan ribuan pemain, jangan berhenti pada average latency.
Gunakan distribusi.
Pantau median atau p50, lalu p95 dan p99.
Misalnya:
p50 input-to-display latency adalah 72 ms, p95 mencapai 125 ms, dan p99 mencapai 210 ms.
Angka tersebut menunjukkan sebagian besar pengguna memiliki pengalaman cukup baik, tetapi terdapat kelompok kecil dengan masalah serius.
Segmentasikan lagi berdasarkan negara, ISP, server region, perangkat, codec, resolusi, Wi-Fi versus Ethernet, dan versi aplikasi.
Sering kali akar masalah baru terlihat setelah data dipecah seperti ini.
Satu ISP mungkin memiliki p95 RTT dua kali lebih tinggi pada malam hari, sementara pengguna provider lain tetap normal.
Validasi Telemetry dengan Pengukuran Fisik
Telemetry sangat kuat, tetapi jangan mengandalkannya sendirian.
Selalu siapkan metode ground truth.
Kamera high-speed atau perangkat latency analyzer dapat digunakan untuk membandingkan total waktu input sampai piksel berubah.
NVIDIA Reflex Analyzer menggunakan pendekatan end-to-end dengan mendeteksi input mouse dan perubahan pixel pada monitor.
NVIDIA menjelaskan bahwa sistem latency mencakup keseluruhan perjalanan dari peripheral latency sampai akhir display latency ketika hardware yang sesuai digunakan.
Jika telemetry memperkirakan total pipeline 70 ms tetapi kamera menunjukkan 105 ms, berarti ada sekitar 35 ms yang belum tercatat.
Kemungkinan berasal dari peripheral, browser scheduling, video presentation, display buffering, monitor processing, atau aspek lain.
Selisih tersebut merupakan petunjuk berharga untuk meningkatkan sistem instrumentation.
Buat Test Matrix sebelum Menilai Hasil
Satu hasil latency tidak mewakili seluruh layanan.
Buat matriks pengujian berdasarkan variabel yang paling penting.
Coba beberapa server region, resolusi, codec, bitrate, device class, refresh rate, dan kondisi jaringan.
Uji juga setidaknya koneksi Ethernet serta Wi-Fi karena karakter jitter keduanya dapat berbeda.
AWS sendiri menyarankan penggunaan lokasi streaming yang dekat dengan pengguna untuk menekan network latency, sekaligus menyediakan RTT sebagai metrik monitoring GameLift Streams.
Dengan test matrix, developer dapat menjawab pertanyaan lebih spesifik: apakah 1440p menambah decoding delay? Apakah region tertentu mempunyai p95 lebih buruk? Apakah codec tertentu menambah encode time pada GPU tertentu?
Itulah data yang bisa langsung digunakan untuk optimisasi.
Tentukan Performance Budget dan Alarm
Setelah baseline tersedia, tentukan batas internal.
Misalnya, tim dapat menetapkan target tertentu untuk RTT, encoder time, decoder time, dropped frames, dan end-to-end latency.
Batasnya tidak harus sama untuk semua game.
Turn-based game lebih toleran terhadap delay dibanding fighting game atau competitive FPS.
Yang penting, ketika metrik melewati batas, sistem monitoring dapat memberikan alarm sebelum keluhan pemain meningkat.
Amazon GameLift Streams dapat mengirim metrik melalui CloudWatch dan memungkinkan penggunaan alarm berdasarkan threshold tertentu.
Dengan sistem seperti ini, pemantauan latency berubah dari aktivitas debugging menjadi bagian rutin operasi layanan.
Cara Mengukur Input Lag pada game streaming sebaiknya memecah latency menjadi jaringan, simulation, rendering, encoding, buffering, decoding, dan display.
Gunakan WebRTC stats, server telemetry, serta percentile untuk menemukan bottleneck, lalu validasi menggunakan click-to-photon test.
Mulailah membuat latency dashboard sejak tahap pengembagan agar masalah responsiveness dapat ditemukan sebelum berdampak luas pada pengalaman pemain.