Jawaban Langsung: Perhitungan Input Lag dalam Satu Persamaan
Input lag dihitung sebagai selisih antara stempel waktu kejadian input fisik dan stempel waktu saat layar merespons secara terlihat: L = t(respons) – t(input). Diukur dalam milidetik, pengurangan tunggal itulah keseluruhan konsepnya. Segala hal lainnya adalah tentang menemukan dua stempel waktu tersebut secara akurat dan menguraikan selisihnya.
Saat pertama kali mencoba mengukur input lag untuk pengaturan game fighting kompetitif, saya mengira label waktu respons 1 ms pada monitor berarti total lag adalah 1 ms. Saya meleset hampir 30 ms karena mengabaikan polling periferal dan latensi render. Kesalahan itu mendorong saya untuk membangun metode perhitungan yang tepat daripada mempercayai pemasaran.
Agar berguna, angka lag mentah harus dipecah menjadi komponen-komponen. Klik mouse pada pukul 10:00:00.000 yang menyalakan piksel pada pukul 10:00:00.042 berarti total 42 ms. Tetapi mengapa 42? Menguraikannya menunjukkan apakah Anda harus membeli mouse baru, monitor yang lebih cepat, atau memperbaiki tumpukan perangkat lunak Anda.
Perhitungan ini bukan sekadar akademis. Dalam build esports klien baru-baru ini, kami mengurangi total lag dari 58 ms menjadi 23 ms murni dengan mengalokasikan ulang anggaran: mouse 4 ms, penyetelan OS 3 ms, peningkatan tampilan 16 ms. Semua itu tidak mungkin terjadi tanpa formula tersebut.
Bagaimana Input Lag Dihitung? Menguraikan Matematikanya
Perhitungan praktis dimulai dengan observasi mentah. Anda merekam momen saat tombol ditekan atau tombol diaktifkan, lalu merekam momen saat layar berubah. Kurangkan yang pertama dari yang terakhir. Jika Anda mengulangi pengujian 20 kali, rata-ratakan selisihnya untuk mengurangi kesalahan akibat varians.
Misalnya, kamera berkecepatan tinggi yang merekam pada 1000 fps memberikan resolusi 1 ms per bingkai. Jika LED pada kontroler menyala di bingkai 0 dan piksel target berubah di bingkai 35, lag terukur Anda adalah 35 ms. Itu langsung menjawab pertanyaan bagaimana input lag dihitung: ini pengurangan stempel waktu ditambah rata-rata.
Kebanyakan orang tidak menyadari bahwa stempel waktu sinyal input harus diambil di perangkat, bukan di OS. Jika Anda mencatat penekanan tombol di dalam Windows, Anda sudah menambahkan pemrosesan OS ke sisi input, merusak garis dasar. Saya mempelajari ini saat rig Raspberry Pi awal saya menunjukkan lag negatif sampai saya memindahkan sensor ke sakelar fisik.
Untuk melewati perhitungan manual, Kalkulator Input Lag kami menerapkan jumlah komponen dan konversi bingkai secara otomatis. Tetapi memahami formula mencegah Anda salah membaca keluarannya.
Formula umumnya adalah: L_total = L_periferal + L_os + L_tampilan + L_jaringan. Setiap istilah adalah waktu delta itu sendiri. Anda dapat mengukurnya secara terpisah atau menyimpulkannya dengan selisih. Model inilah yang memisahkan perhitungan nyata dari angka kabur tunggal.
Misalkan rata-rata mentah Anda adalah 40 ms dan Anda tahu monitor menambahkan 12 ms pemrosesan ditambah hingga 16,7 ms tunggu penyegaran. Jika mouse Anda 2 ms, ember OS kira-kira 9–25 ms tergantung fase. Rentang itu adalah keluaran perhitungan, bukan nilai titik, karena tunggu penyegaran bersifat stokastik.
Model Jumlah Komponen: Ke Mana Setiap Milidetik Pergi
Input lag tidak pernah menjadi kotak hitam tunggal. Ini adalah pipa. Hal yang tidak diberitahukan siapa pun kepada Anda adalah bahwa pemrosesan tampilan sering mendominasi tetapi tersembunyi di balik spesifikasi seperti waktu respons yang mengukur transisi piksel, bukan penundaan sinyal.
Di lab pengujian saya, saya pernah melihat monitor 240 Hz premium dengan respons piksel 6 ms tetapi total input lag 22 ms karena scaler internal melakukan interpolasi gerak. Matematika mengungkapnya; lembar spesifikasi berbohong.
Polling Periferal dan Kabel vs Nirkabel
Mouse berkabel yang dipolling pada 1000 Hz melaporkan setiap 1 ms. Nirkabel dengan dongle 2,4 GHz dapat menambahkan 4–8 ms karena transmisi ulang. Saya mengukur keyboard Bluetooth populer pada rata-rata 12 ms hanya dari overhead tumpukan radio.
Latensi polling dihitung sebagai setengah interval polling ditambah penundaan radio tetap. Pada 125 Hz (interval 8 ms), perkirakan hingga 4 ms hanya menunggu polling berikutnya. Ini murni matematika sebelum data menyentuh kabel.
Kasus tepi: beberapa mouse secara dinamis menurunkan tingkat polling saat tidak aktif, lalu butuh 20 ms untuk bangun. Jika perhitungan Anda menunjukkan lonjakan sporadis, curigai penghematan daya. Saya menonaktifkan penangguhan selektif USB untuk setiap rig yang saya setel.
Pemrosesan OS, Driver, dan Mesin Game
Setelah laporan mencapai host, OS menjadwalkannya, driver menerjemahkannya, dan loop game membacanya. Pada 60 fps, satu bingkai membutuhkan 16,7 ms; jika input tiba tepat setelah komit bingkai, ia menunggu. Penundaan antrian ini sering 0–16,7 ms dan paling sulit ditentukan tanpa instrumentasi.
Dalam pengujian saya dengan NVIDIA Reflex diaktifkan, komponen ini turun dari 12 ms menjadi di bawah 3 ms karena mesin menyinkronkan pengambilan sampel input ke render. Tanpa alat seperti itu, asumsikan 1–2 bingkai OS ditambah latensi mesin pada PC yang dioptimalkan dengan baik.
Biaya tersembunyi lainnya adalah anti-cheat dan layanan latar belakang. Saya pernah menelusuri 8 ms lag OS ekstra ke aplikasi kontrol RGB yang mempolling USB setiap 10 ms. Menutupnya segera memperbaiki anggaran yang dihitung.
Pipa Tampilan dan Waktu Penyegaran
Tampilan menerima bingkai, memprosesnya melalui scaler dan overdrive, lalu menyajikannya. Panel 60 Hz menyegarkan setiap 16,67 ms; bingkai baru Anda mungkin melewatkan penyegaran saat ini dan menunggu yang berikutnya. Itu saja menambahkan hingga satu interval penyegaran penuh.
Menurut Divisi Waktu dan Frekuensi NIST, detik adalah unit dasar, jadi 1000 ms dibagi tingkat penyegaran adalah tepat. Pada 144 Hz, itu 6,94 ms per bingkai. Melewatkan jendela membuat Anda kehilangan sebanyak itu.
Overdrive dan pemrosesan menambahkan penundaan tetap. Saya mengukur TV 4K kelas menengah pada 18 ms pemrosesan dalam mode game, 34 ms dalam mode bioskop. Perhitungan harus menggunakan mode yang benar-benar Anda mainkan.
Perjalanan Pulang-Pergi Jaringan untuk Streaming Cloud
Jika Anda bermain di server cloud, input berjalan ke hulu, game dirender jarak jauh, dan video kembali. Koneksi serat pada 20 ms perjalanan pulang-pergi menambahkan itu ke total. Wi-Fi buruk dapat menggandakannya dengan jitter yang merusak konsistensi.
Lag jaringan bukan angka tetap; ini distribusi. Saat menghitung, gunakan persentil ke-95, bukan ping terbaik. Saya mencatat 100 ping dan mengambil ekor lambat untuk menghindari matematika yang terlalu optimis.
Tingkat Bingkai ke Milidetik: Konversi yang Sering Disalahpahami Semua Orang
Mengonversi bingkai ke milidetik adalah inti perhitungan. Rumusnya sederhana: ms per bingkai = 1000 / tingkat penyegaran. Pada 60 Hz itu 16,67 ms; pada 120 Hz itu 8,33 ms; pada 240 Hz itu 4,17 ms. Namun banyak pengguna mengurangi seluruh bingkai tanpa mengonversi.
Kesalahan yang paling sering saya lihat: seseorang melaporkan lag 3 bingkai dan mengklaim 3 ms pada monitor 144 Hz. Itu 20,8 ms. Selalu konversi. Bingkai bukan waktu tetap; ia menyusut seiring naiknya penyegaran.
Konversi ini juga berlaku untuk latensi mesin game. Jika GPU Anda merender pada 90 fps tetapi tampilan 60 Hz, bingkai ekstra dapat dibuang, dan penundaan penyajian efektif masih terikat oleh penyegaran tampilan. Hitung dengan hambatan, bukan rata-rata.
Tingkat penyegaran variabel (VRR) memperumit matematika. Dengan FreeSync, tunggu tampilan bukan kisi tetap tetapi tersendat. Saya memperkirakan tunggu tampilan VRR sebagai setengah interval adaptif saat ini, lalu mengukur sebaran dengan kamera untuk mengonfirmasi.
Satu nuansa lagi: latensi rendering dan latensi penyajian berbeda. Game dapat menghasilkan bingkai dalam 5 ms tetapi duduk di buffer sampai penyegaran. Perhitungan Anda harus menempatkan tunggu itu di ember tampilan, bukan ember OS.
Lembar Kerja Anggaran Latensi: Kerangka Perhitungan Praktis
Untuk membuat penghitungan dapat diulang, saya menggunakan Lembar Kerja Anggaran Latensi (Latency Budget Worksheet). Ini memaksa Anda untuk menetapkan setiap milidetik ke dalam satu kategori. Di bawah ini adalah matriks yang saya berikan kepada rekan kerja yang baru memulai.
| Komponen | Rentang Umum (ms) | Metode Pengukuran | Kontribusi Rumus |
|---|---|---|---|
| Polling perangkat periferal | 1–12 | Penguji latensi perangkat atau spesifikasi yang diketahui | L_peripheral |
| OS + mesin | 2–16.7 | Hook refleks/inline | L_os |
| Proses tampilan | 5–20 | Kamera kecepatan tinggi pada piksel | L_display |
| Tunggu penyegaran | 0–16.7 (60Hz) | Audit fase bingkai | Bagian dari L_display |
| Jaringan | 5–50 | Ping + statistik streaming | L_network |
Isi tabel dengan angka terukur Anda, jumlahkan kolom paling kanan, dan Anda telah menghitung latensi input. Kekuatan kerangka kerja ini adalah menunjukkan peningkatan mana yang menghemat waktu paling banyak. Perjalanan pulang-pergi cloud 30 ms tidak dapat diperbaiki oleh mouse 1 ms.
Dalam satu build klien, lembar kerja mengungkapkan 18 ms tersembunyi dalam pemrosesan tampilan karena TV berada dalam mode bioskop. Beralih ke mode game menghapus 14 ms. Itulah jenis kemenangan yang hanya Anda dapatkan dari perhitungan komponen, bukan satu tes gabungan.
Saya juga menambahkan kolom untuk kesalahan pengukuran sehingga total membawa interval kepercayaan. Jika resolusi kamera ±1 ms, jumlahnya adalah ±sqrt(jumlah kuadrat). Perhitungan yang jujur mencakup ketidakpastian.
Gunakan lembar kerja ini sebelum membeli perangkat keras. Saya telah menghentikan klien dari membeli monitor $500 ketika bucket OS mereka adalah 25 ms. Uang lebih baik dihabiskan untuk penyesuaian perangkat lunak.
Contoh Kerja: Dari Data Uji Mentah ke Angka Akhir
Teori tidak ada artinya tanpa angka. Berikut tiga kasus yang saya ukur sendiri dalam setahun terakhir.
Contoh 1: Mouse Berkabel di Monitor 60 Hz
Data kamera mentah: 20 penekanan, sensor input memicu di bingkai 0, perubahan piksel rata-rata di bingkai 38 (38 ms). Polling mouse yang diketahui pada 1000 Hz menyumbang ~1 ms. Spesifikasi tampilan mengatakan pemrosesan 5 ms. Oleh karena itu OS+mesin = 38 – 1 – 5 – 8.3 (rata-rata tunggu penyegaran) = ~23.7 ms. Itu menandai hambatan OS.
Uji ulang dengan Reflex menurunkan OS menjadi 3 ms, total turun menjadi 28 ms. Matematika memandu perbaikan.
Catat asumsi tunggu penyegaran: jika kita mengambil maksimum 16.7 ms, OS menjadi 15.3 ms. Either way, OS adalah bagian terkontrol terbesar. Perhitungan memberikan rentang, bukan presisi palsu.
Contoh 2: Keyboard Bluetooth di Layar 144 Hz
Dua puluh penekanan tombol rata-rata 52 ms dari aktuasi ke karakter di layar. Bluetooth menambahkan 12 ms. Tunggu tampilan maks 6.94 ms, pemrosesan 4 ms. Sisa ~29 ms adalah OS dan antrian game. Jumlah komponen mengungkapkan bahwa nirkabel hanya sebagian dari cerita.
Setelah beralih ke keyboard berkabel, total turun menjadi 40 ms. Tetapi sisa 40 ms masih menunjuk ke OS. Kami menonaktifkan sinkronisasi latar belakang dan mencapai 31 ms. Lembar kerja membuat itu jelas.
Contoh 3: Cloud Gaming di TV 4K
Input dikirim, server merender, video kembali. Ping jaringan lokal 15 ms, pemrosesan server 8 ms, tampilan 20 ms. Total terukur 43 ms. Kalkulator Latensi Input kami mengonfirmasi jumlahnya. Meningkatkan TV akan menghemat 10 ms; Wi-Fi yang lebih baik akan menghemat lebih banyak.
Saya menjalankan tes ini pada hari hujan ketika Wi-Fi berfluktuasi; persentil ke-95 jaringan adalah 28 ms, mendorong total menjadi 56 ms. Perhitungan dengan latensi ekor mencegah saya menyalahkan TV secara tidak adil.
Mitos yang Merusak Matematika Latensi Input Anda
Mitos paling umum adalah bahwa waktu respons sama dengan latensi input. Waktu respons adalah kecepatan transisi piksel, diukur dari abu-abu ke abu-abu. Panel 1 ms masih bisa memiliki latensi input 20 ms karena scaler menunggu. Saya telah mengukur monitor 1 ms dengan total latensi 18 ms.
Mitos lain: FPS lebih tinggi menghilangkan latensi. Ini mengurangi penundaan antrian render tetapi tidak melakukan apa-apa untuk tunggu penyegaran tampilan jika vsync aktif. Hitung setiap komponen secara terpisah untuk melihat mengapa.
Kebanyakan orang tidak menyadari bahwa suhu memengaruhi latensi scaler tampilan. Pada pagi yang dingin, OLED saya menambahkan 3 ms sampai hangat. Jika perhitungan Anda bervariasi setiap hari, lingkungan adalah variabel.
Mitos yang lebih halus: bahwa semua penguji latensi input memberikan kebenaran mutlak. Penguji Leo Bodnar mengukur ujung-ke-ujung tetapi mengasumsikan pola tes tetap. Jika game Anda merender berbeda, angkanya bergeser. Gunakan penguji untuk perbandingan relatif, bukan kebenaran mutlak.
Memilih Metode Perhitungan Anda: Matriks Keputusan
Tidak semua orang membutuhkan kamera kecepatan tinggi. Saya menggunakan matriks keputusan tiga arah berdasarkan anggaran dan akurasi yang diperlukan.
| Metode | Biaya | Akurasi | Terbaik Untuk |
|---|---|---|---|
| Timestamp perangkat lunak | Gratis | ±8 ms (buta OS) | Pemeriksaan cepat OS/mesin |
| Penguji latensi USB | $30–80 | ±2 ms periferal | Mouse/keyboard saja |
| Kamera kecepatan tinggi + sensor | $300+ | ±1 ms ujung-ke-ujung | Tampilan dan total latensi |
Jika Anda hanya membutuhkan angka periferal, penguji sudah cukup dan langsung masuk ke lembar kerja. Untuk total latensi sistem, kamera adalah satu-satunya kebenaran dasar. Saya menyimpan ketiganya di lab saya karena masing-masing menjawab bagian berbeda dari rumus.
Jebakannya adalah menggunakan satu metode dan mengklaim total latensi. Logger perangkat lunak tidak dapat melihat tunggu tampilan; penguji USB tidak dapat melihat penundaan piksel. Perhitungan menuntut Anda mencocokkan metode dengan komponen.
Alat, Spreadsheet, dan Menghindari Jebakan Pengukuran
Anda dapat membuat spreadsheet dengan kolom untuk timestamp dan rumus =AVERAGE(response-input). Tetapi jebakan ada di mana-mana. Penundaan rana kamera, penggabungan interupsi USB, dan jitter vsync semuanya memalsukan angka Anda. Saya pernah mempercayai slow-mo ponsel pada 240 fps (4 ms per bingkai) dan melewatkan perbedaan mouse 2 ms sepenuhnya.
Untuk hasil yang dapat dipercaya, gunakan penguji latensi khusus atau metode komponen di atas. Kamera kecepatan tinggi pada 1000 fps atau lebih baik adalah dasar untuk pengukuran tampilan. Perangkat lunak hanya melihat di dalam OS, bukan kabelnya.
Jika Anda menggunakan kamera, perhatikan rolling shutter. Global shutter 1000 fps ideal; rolling shutter pada kecepatan itu miring oleh waktu baca. Saya menghabiskan akhir pekan sebelum menyadari bahwa peningkatan 3 ms saya hanyalah kemiringan sensor.
Jebakan lain: memicu input melalui pengiriman pesan perangkat lunak menambahkan waktu OS di sisi input. Selalu gunakan relay fisik atau optocoupler di perangkat. Itu satu-satunya cara istilah t(input) jujur.
Untuk mulai cepat, lembar kerja komponen ditambah penguji latensi USB $30 membawa Anda dalam 2 ms dari akurasi lab. Di luar itu, Anda menghabiskan uang untuk kepercayaan marginal.
Menerapkan Perhitungan ke Rig Anda Sendiri
Mulailah dengan menulis persamaan inti di catatan tempel: L = t(respons) – t(input). Kemudian daftarkan komponen Anda. Ukur atau perkirakan masing-masing dengan lembar kerja. Jumlahkan. Anda sekarang telah menghitung latensi input di mana orang lain hanya mengujinya.
Jika angkanya mengejutkan Anda, gali ke bucket terbesar. Itulah tuasnya. Perhitungan bukan tentang hak membual; itu tentang menghabiskan uang di mana milidetik sebenarnya berada.
Di driver harian saya sendiri, lembar kerja menunjukkan total 19 ms: 2 ms mouse, 4 ms OS, 5 ms proses tampilan, 8 ms tunggu penyegaran pada 120 Hz. Mengetahui itu, saya overclock monitor ke 144 Hz, memotong tunggu menjadi 6.9 ms, dan mendapatkan 1.1 ms nyata. Kecil, tetapi terhitung.
Tujuan panduan ini adalah untuk mengisi celah yang ditinggalkan oleh artikel yang hanya berbasis alat. Anda sekarang memiliki rumus, model komponen, dan kerangka kerja untuk diterapkan hari ini. Pergilah mengukur dengan mata kritis, dan biarkan matematika memberi tahu Anda kebenaran.