Versi interaktif: https://jungrok5.github.io/mmo-lag-anatomy/id/ Halaman penyebab: https://jungrok5.github.io/mmo-lag-anatomy/id/c/[ID penyebab].html # Data pengetahuan Buku Putih Lag Game Dibuat otomatis (2026-10-03, `node tools/export.cjs`). Jangan diedit manual; untuk mengubah isinya, edit src/js/ lalu jalankan ulang ekspor. 228 penyebab, 135 istilah. Penyebab dirujuk dengan **ID**. Tambahkan `#c-ID` di belakang alamat situs untuk membuka kartu penyebab tersebut. ## Kode penanggung jawab | Kode | Tim | Penanggung jawab | Cakupan | |---|---|---|---| | cli | Tim Pengembang Game | Pengembangan klien | Kode klien game: frame, GC, dan loading; interpolasi, ekstrapolasi, dan prediksi; pemrosesan jaringan di klien (termasuk pengiriman heartbeat dan reconnect otomatis) | | srv | Tim Pengembang Game | Pengembangan server | Kode server game: tick, thread, dan lock; desain sinkronisasi; penanganan koneksi (loop accept, argumen listen); respons heartbeat dan pembersihan koneksi yang terputus; opsi socket; desain query dan transaksi | | net | Tim Infrastruktur | Infrastruktur jaringan | Jalur dan perangkat jaringan data center (switch, router, firewall, load balancer, proteksi DDoS); network ACL, routing VPC, dan load balancer di cloud; ISP dan peering | | sys | Tim Infrastruktur | Infrastruktur server | Server fisik dan instance cloud (termasuk security group dan connection tracking), konfigurasi OS dan kernel, NIC, lingkungan deploy dan monitoring | | dba | Tim Infrastruktur | Infrastruktur DB | Server DB dan storage; konfigurasi, replikasi, dan backup DB; server cache | | ext | Pihak Eksternal | Pihak Eksternal | PC dan jaringan rumah pemain, jalur ISP (di luar kontrak kami), penyedia cloud. Tidak bisa diperbaiki langsung, jadi ditangani lewat panduan untuk pemain, permintaan ke penyedia, dan solusi sementara (workaround) | “Penanggung jawab utama” pada setiap penyebab adalah pihak yang menghilangkan akar penyebabnya; “Turut terlibat” adalah pihak yang juga punya tugas nyata. ## Gejala - **Patah-patah** (`stutter`, disebut juga: tersendat-sendat, putus-putus, terasa seperti FPS drop): Gerakan tidak mulus: berhenti sebentar, bergerak lagi, dan begitu terus berulang. Jika angka ping normal, kemungkinan besar masalahnya ada di frame PC Anda (klien atau OS). Jika ping naik turun, kemungkinan besar penyebabnya jitter dari Wi-Fi atau koneksi internet. Namun, ping di dalam game biasanya diukur di dalam game loop yang berjalan setiap frame, sehingga saat frame melonjak, angka ping juga bisa ikut melonjak. - **Teleport** (`teleport`, disebut juga: warp, teleportasi, berhenti lalu tiba-tiba melompat): Karakter langsung berpindah ke posisi yang jauh tanpa terlihat bergerak ke sana. Biasanya ini berarti paket sempat tidak datang selama beberapa saat. Periksa packet loss, koneksi yang putus sesaat, server yang berhenti, dan ekstrapolasi yang meleset. Jika pemain lain normal dan hanya satu orang yang teleport, koneksi orang itulah yang pertama dicurigai. - **Rubber banding** (`rubber`, disebut juga: tertarik ke belakang, ketarik balik, rollback posisi): Karakter Anda sedang maju, lalu tertarik kembali ke posisi yang baru saja dilewati. Layar Anda (prediksi) tidak cocok dengan keputusan server. Bisa jadi input Anda tidak sampai ke server (packet loss), validasi gerakan di server memotongnya, atau perhitungan gerakan di klien dan server berbeda. - **Fast forward** (`burst`, disebut juga: bertubi-tubi, seperti dipercepat, semua diproses sekaligus): Layar yang tadinya diam bergerak lagi, lalu gerakan, serangan, dan damage yang tertunda lewat dengan cepat sekaligus. Paket sempat tertahan di suatu tempat, lalu dilepas sekaligus. Penyebab yang umum: TCP menunggu retransmisi, server mengejar ketertinggalan, dan pemrosesan di klien yang tertunda. - **Slow motion** (`slowmo`, disebut juga: dunia game melambat, semuanya terasa lamban): Semuanya bergerak lambat. Cast skill dan gerakan monster terlihat molor. Tergantung desain servernya, gejala ini juga bisa muncul sebagai patah-patah atau teleport dengan kecepatan yang tetap normal. Server tidak sempat menyelesaikan tick tepat waktu. Koneksinya baik-baik saja, jadi ping yang diukur di luar game tidak berubah; ping di dalam game bisa sedikit naik jika waktu tunggu pemrosesan server ikut terhitung di dalamnya. Periksa lonjakan jumlah pemain, perhitungan jarak pandang, broadcast, dan kekurangan memori. - **Input lag** (`delay`, disebut juga: respons terlambat, lamban, kontrol terasa berat): Ada jeda antara saat tombol ditekan dan saat hasilnya muncul. Gambarnya sendiri bisa tetap mulus. Round-trip time (ping) tinggi, atau ada antrean yang menumpuk di suatu tempat. Periksa jarak, antrean router, Nagle (fitur TCP yang mengumpulkan paket kecil sebelum dikirim), dan antrean server. Jika ping rendah tetapi kontrol selalu terasa lamban, periksa sisi PC Anda (misalnya V-Sync atau FPS rendah) atau desain yang menunggu konfirmasi server untuk setiap aksi (bab model sinkronisasi). - **Freeze** (`freeze`, disebut juga: membeku, hang, tidak merespons): Semua yang ada di layar berhenti sejenak (0,5 detik hingga beberapa detik), lalu bergerak lagi. Seluruh server berhenti (GC, deadlock, pemanggilan sinkron), koneksi putus sesaat, atau PC Anda yang berhenti. - **Aksi hilang / rollback** (`dropped`, disebut juga: skill tidak keluar, item kembali seperti semula, trade gagal): Aksi yang jelas sudah dilakukan dianggap tidak pernah terjadi, atau hasilnya berbalik lama setelahnya. Permintaan hilang (packet loss, antrean meluap), server memutuskan hasil yang berbeda dari layar Anda (perbedaan waktu penilaian, ditolak setelah feedback sisi klien), atau penyimpanan gagal di tengah jalan (lock atau gangguan DB, server crash). - **Disconnect** (`disconnect`, disebut juga: DC, terlempar keluar, koneksi ke server terputus): Koneksi terputus di tengah permainan, lalu Anda kembali ke layar login atau jendela reconnect. Tidak ada satu paket pun yang datang selama batas timeout. Periksa koneksi yang putus lama, idle timeout, server crash atau restart, serta server atau PC Anda yang berhenti lebih lama dari timeout (loading yang lama). Jika game tertutup sendiri tanpa pesan apa pun, periksa dulu kemungkinan klien tertutup paksa (crash, kehabisan memori) sebelum memeriksa koneksi. - **Tidak bisa masuk / loading tanpa henti** (`noconnect`, disebut juga: tidak bisa login, loading tak kunjung selesai): Tidak bisa masuk ke dalam game, atau tertahan di layar loading atau layar masuk. Titik yang menerima koneksi baru (antrean koneksi server, firewall, server login, DB) sudah penuh. Ini sangat sering terjadi tepat setelah maintenance. - **Tidak terlihat / objek hantu** (`invisible`, disebut juga: NPC tidak muncul, karakter transparan, monster yang sudah mati masih berdiri): NPC, monster, atau pemain yang seharusnya ada tidak muncul hanya di layar Anda, atau objek yang sudah hilang masih tertinggal hanya di layar Anda. Ada satu paket yang terlewat atau objek gagal digambar. Kecepatan tidak banyak berperan di sini. Periksa perbedaan channel atau phasing, pesan spawn/despawn yang hilang, data yang dibuang saat loading, dan aset yang gagal dimuat. Petunjuk yang menentukan: apakah objek itu muncul setelah Anda keluar dari jarak pandang lalu kembali. ## Empat faktor - **Latensi** (`lat`, Latency): Jarak, antrean, dan waktu pemrosesan membuat semua paket tiba terlambat secara konsisten. Cara game mengatasinya: Aksi Anda ditampilkan lebih dulu lewat prediksi dan feedback sisi klien, sementara server memutar mundur waktu untuk menentukan hasilnya (lag compensation). - **Jitter** (`jit`, Jitter): Rata-ratanya normal, tetapi sebagian paket datang cepat dan sebagian lagi terlambat. Penyebabnya antara lain Wi-Fi, jalur yang padat, dan CPU yang sibuk. Cara game mengatasinya: Paket ditampung sebentar di buffer interpolasi, lalu diambil dan digambar dengan laju tetap. Jika jitter lebih besar dari buffer, gejalanya tidak bisa ditutupi. - **Packet loss** (`loss`, Packet loss): Antrean yang meluap, interferensi sinyal, dan perangkat yang rusak membuang paket. Koneksi yang putus sesaat juga terhitung packet loss beruntun. Cara game mengatasinya: Game berbasis UDP mengisi celah dengan interpolasi dan ekstrapolasi, dan mengirim input Anda secara berulang sehingga satu atau dua paket yang hilang tetap tertutupi. TCP tidak meneruskan paket berikutnya ke game sampai paket yang hilang diterima ulang. - **Stall** (`stall`, Stall): Tick server terlambat atau terhenti (GC, lock, pemanggilan sinkron, beban berlebih), atau frame di PC Anda terhenti. Ini bisa terjadi meskipun koneksinya baik-baik saja. Cara game mengatasinya: Perhitungan yang tertunda dikejar sekaligus, dilewati, atau dibiarkan berjalan lebih lambat. ## Penyebab ### L1 Proses game di klien (16 penyebab) #### cg-hitch · Lonjakan frame time · Frame hitch Perhitungan satu frame memakan waktu beberapa kali lebih lama dari biasanya sehingga layar berhenti sejenak. - Mengapa → Akibatnya → Di layar: Jumlah efek skill melonjak, spawn massal, dan pembaruan seluruh UI menumpuk dalam satu frame → Tidak selesai dalam 16,7 ms dan memakan 50–300 ms → Layar tersendat sesaat, lalu di frame berikutnya semua karakter berpindah sekaligus - Gejala: Patah-patah, Freeze / Faktor: Stall - Siapa: Hanya saya / Kapan: Saat banyak pemain berkumpul, Saat melakukan aksi tertentu, Sesekali secara acak - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pecah pekerjaan berat ke beberapa frame, cari frame yang melonjak dengan profiler, batasi jumlah efek. - Kisaran angka: Satu frame pada 60 FPS adalah 16,7 ms. Satu frame saja yang melewati 50 ms sudah mudah dirasakan sebagai “tersendat”. - Di grafik: Melonjak acak sesekali (Frame time) - Yang diperiksa: Rekam frame time (FrameTime) dan waktu yang dipakai CPU dan GPU untuk frame tersebut (CPUBusy dan GPUBusy) selama bermain dengan PresentMon. Untuk mobile, periksa metrik sesi lambat dan rendering lambat di Android vitals - Cocok jika: Frame time yang biasanya sekitar 16,7 ms melonjak melewati 50 ms tepat saat efek skill, spawn massal, atau pembaruan seluruh UI terjadi, dan pada saat itu ping tidak berubah - Tidak cocok jika: Frame time stabil, tetapi hanya karakter lain yang tersendat: mengarah ke sisi jaringan seperti “Buffer interpolasi tidak ada atau terlalu pendek”. Interval lonjakan teratur: periksa dulu “Garbage collection di klien” - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Slow rendering](https://developer.android.com/topic/performance/vitals/render) · Android (Google) · Untuk mencapai 60 FPS, satu frame harus digambar dalam 16 ms; jika terlambat, frame dilewati dan terlihat tersendat (jank) - [Slow Sessions (games only)](https://developer.android.com/topic/performance/issues/slow-session) · Android (Google) · Android vitals menganggap frame game lambat jika melewati 50 ms (20 FPS) atau 34 ms (30 FPS) - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · FrameTime (waktu CPU di antara frame), CPUBusy dan GPUBusy (waktu yang dipakai CPU dan GPU untuk membuat frame itu) #### cg-gc · Garbage collection di klien · Client GC (Unity C#, Unreal, Lua) Selama memori bekas pakai (garbage) dikumpulkan kembali, seluruh game berhenti. Cirinya adalah patah-patah dengan interval yang teratur. - Mengapa → Akibatnya → Di layar: Setiap frame membuat lalu membuang string, array, dan list sementara → Saat garbage menumpuk, GC menghentikan main thread untuk mengumpulkannya → Patah-patah secara teratur setiap beberapa detik hingga puluhan detik - Gejala: Patah-patah, Freeze / Faktor: Stall - Siapa: Hanya saya / Kapan: Secara berkala, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kurangi alokasi (hindari penggabungan string, LINQ, dan capture lambda), gunakan object pool, biarkan incremental GC aktif (default sejak Unity 2020), jalankan GC lebih awal saat jeda tidak mengganggu, misalnya di layar loading. - Kisaran angka: Biasanya beberapa ms hingga 100 ms sekali jalan; di ponsel spesifikasi rendah atau game yang memakai banyak memori bisa lebih lama (di simulasi sekitar 150–170 ms). GC Unity memeriksa seluruh heap setiap kali berjalan, jadi makin banyak memori yang dipakai game, makin lama jedanya. - Di grafik: Melonjak secara berkala (Frame time, waktu GC berjalan) - Yang diperiksa: Di development build, periksa marker GC.Collect dan GC.Alloc di Unity Profiler. Di Unreal, gunakan stat GC dan stat Hitches (mencatat ke log setiap frame yang melewati waktu yang ditetapkan t.HitchFrameTimeThreshold) - Cocok jika: Setiap frame yang melonjak memiliki bagian GC.Collect yang lamanya mirip dengan lama lonjakan, dan intervalnya teratur setiap beberapa detik hingga puluhan detik. GC.Alloc per frame meningkat di tempat ramai - Tidak cocok jika: Tidak ada bagian GC di frame yang melonjak: lebih mungkin “Pemuatan sinkron dan kompilasi shader di main thread” atau “Beban rendering kerumunan besar” - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Umum di klien yang memakai C# seperti Unity. Penyebab utamanya adalah kode yang membuat ulang string log pertempuran, angka damage, dan teks UI di setiap frame. Jika patah-patah hanya terjadi di tempat ramai, berarti ada kode yang menghasilkan garbage sebanding dengan jumlah pemain. Incremental GC membagi pengumpulan sedikit demi sedikit per frame (default Unity 3 ms), tetapi jika garbage dibuat lebih cepat daripada kecepatan pengumpulannya, akhirnya game tetap berhenti sekaligus. Unreal Engine juga punya GC sendiri yang membersihkan game object yang tidak dipakai. Perilakunya berbeda menurut versi engine dan pengaturannya, tetapi dengan pengaturan default GC ini berjalan kira-kira setiap 1 menit dan bisa membuat game tersendat sesaat dengan interval 1 menit. Klien yang menulis aturan game dalam skrip seperti Lua juga menjalankan GC skrip itu secara terpisah. - Sumber: - [Garbage collection modes](https://docs.unity3d.com/Manual/performance-incremental-garbage-collection.html) · Unity · Incremental GC adalah default dan mengumpulkan garbage secara terbagi di beberapa frame; jika dimatikan, main thread berhenti selama seluruh heap diperiksa dan jedanya bisa mencapai ratusan ms - [Scripting.GarbageCollector.CollectIncremental](https://docs.unity3d.com/ScriptReference/Scripting.GarbageCollector.CollectIncremental.html) · Unity · Target default waktu yang dipakai incremental GC sekali jalan (time slice) adalah 3 ms (incrementalTimeSliceNanoseconds) - [Garbage Collection Settings in the Unreal Engine Project Settings](https://dev.epicgames.com/documentation/en-us/unreal-engine/garbage-collection-settings-in-the-unreal-engine-project-settings) · Epic Games · Pengaturan bahwa GC Unreal berjalan pada interval tertentu (Time Between Purging Pending Kill Objects, dalam detik). Nilai default tidak disebutkan di dokumen ini - [Profiler markers reference](https://docs.unity3d.com/Manual/profiler-markers.html) · Unity · GC.Collect: bagian saat kode program berhenti selama garbage collection (kurang dari 1 ms hingga ratusan ms), GC.Alloc: alokasi managed heap - [Stat Commands in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/stat-commands-in-unreal-engine) · Epic Games · stat GC (statistik garbage collection), stat Hitches (mencatat ke log frame yang melewati t.HitchFrameTimeThreshold) #### cg-sync-load · Pemuatan sinkron dan kompilasi shader di main thread · Synchronous asset load, shader compile Game berhenti karena harus membaca file dan membuat shader tepat sebelum menggambar area, monster, atau efek yang baru pertama kali muncul. - Mengapa → Akibatnya → Di layar: Masuk area baru, skill, equipment, atau monster yang baru pertama kali muncul → Main thread menunggu pembacaan file dan kompilasi shader → Berhenti 0,1–1 detik hanya pada kali pertama, setelah itu normal - Gejala: Freeze, Patah-patah / Faktor: Stall - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area, Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Gunakan loading asinkron, muat lebih awal (prewarming), kompilasi shader lebih awal di layar loading atau saat game pertama kali dijalankan, manfaatkan layar loading. - Kisaran angka: Kompilasi satu shader memakan puluhan ms, kalau lama bisa 100 ms atau lebih. Loading tekstur memakan puluhan hingga ratusan ms, tergantung kecepatan storage. - Di grafik: Melonjak tepat setelah server dibuka (Jumlah lonjakan frame (tepat setelah patch atau update driver)) - Yang diperiksa: Rekam rute yang sama dua kali dengan PresentMon, lalu bandingkan kunjungan pertama dan kedua. Di development build Unreal, aktifkan r.PSOPrecache.Validation lalu periksa stat PSOPrecache dan “PSO PRECACHING MISS” di log; di Unity, periksa bagian loading dan shader pada frame yang melonjak di Timeline profiler - Cocok jika: Lonjakan 0,1–1 detik hanya terjadi di tempat yang pertama didatangi atau skill yang pertama dipakai, lalu hilang pada kali kedua. Laporan menumpuk tepat setelah patch atau update driver grafis, lalu berkurang - Tidak cocok jika: Selalu melonjak di tempat yang sama: masalahnya ada di luar cache shader. Berulang setiap kali bergerak, hanya di PC dengan storage lambat: lebih mungkin “Streaming aset tertinggal akibat storage lambat”. Memori GPU khusus penuh: lebih mungkin “Kekurangan memori grafis (VRAM)” - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Di PC, shader yang sudah dibuat sekali disimpan oleh driver grafis di cache shader lalu dipakai ulang. Karena itu, tepat setelah driver grafis diperbarui atau patch game dirilis, cache ini menjadi tidak berlaku, sehingga pemain yang tadinya lancar pun kembali mengalami patah-patah untuk sementara. Laporan yang khas berbunyi “setelah patch, tersendat setiap kali masuk tempat yang baru pertama didatangi”. - Sumber: - [Shader loading](https://docs.unity3d.com/Manual/shader-loading.html) · Unity · Saat varian shader dipakai pertama kali, driver grafis harus membuatnya untuk GPU sehingga bisa terjadi jeda yang terasa; yang sudah dibuat disimpan di cache sehingga tidak berhenti lagi - [Optimizing Rendering With PSO Caches in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/optimizing-rendering-with-pso-caches-in-unreal-engine) · Epic Games · Membuat pipeline state (PSO) tepat saat dibutuhkan bisa memakan 100 ms atau lebih, jadi PSO harus dibuat lebih awal - [Direct3D 12 Return Codes](https://learn.microsoft.com/en-us/windows/win32/direct3d12/d3d12-graphics-reference-returnvalues) · Microsoft · D3D12_ERROR_DRIVER_VERSION_MISMATCH: cache PSO yang dibuat dengan versi driver lain tidak bisa dipakai ulang (dikompilasi ulang setelah update driver) - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame) - [PSO Precaching for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/pso-precaching-for-unreal-engine) · Epic Games · Jika r.PSOPrecache.Validation diaktifkan, statistik PSO yang terlewat terlihat di stat PSOPrecache dan “PSO PRECACHING MISS” dicatat di log; pembuatan PSO saat runtime yang melewati 20 ms (default) dihitung sebagai hitch #### cg-asset-stream · Streaming aset tertinggal akibat storage lambat · Slow storage stalls asset streaming Pada storage lambat seperti HDD, kecepatan membaca tekstur dan model di open world tidak bisa mengimbangi gerakan pemain, sehingga objek terlambat muncul atau game patah-patah karena menunggu pembacaan selesai. - Mengapa → Akibatnya → Di layar: Bergerak cepat dengan tunggangan atau teleportasi, atau masuk ke tempat ramai, sehingga banyak tekstur dan model baru dibutuhkan sekaligus → Storage lambat seperti HDD tidak bisa membaca secepat yang dibutuhkan sehingga permintaan baca menumpuk, dan sebagian loading membuat main thread menunggu sampai selesai → Tekstur buram untuk sementara, bangunan dan karakter terlambat muncul, dan saat menunggu pembacaan terjadi patah-patah atau freeze - Gejala: Tidak terlihat / objek hantu, Patah-patah, Freeze / Faktor: Stall - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Gunakan streaming asinkron agar main thread tidak menunggu pembacaan, baca lebih awal berdasarkan arah dan kecepatan gerak, tampilkan resolusi rendah (mipmap) dan model sederhana lebih dulu lalu ganti kemudian, batasi kecepatan gerak sebentar atau pakai layar loading jika streaming tertinggal saat bergerak cepat, cantumkan apakah SSD diperlukan di spesifikasi minimum dan yang direkomendasikan. - Tugas Pihak Eksternal: Imbau pemain untuk memasang game di SSD, minta pemain memeriksa apakah ada unduhan atau pemindaian antivirus yang berjalan di disk yang sama. - Kisaran angka: Menurut penjelasan Microsoft, hard disk lama membaca puluhan MB per detik, NVMe SSD membaca beberapa GB per detik, dan game generasi sebelumnya memakai sekitar 50 MB per detik untuk streaming. Jika game yang dirancang dengan asumsi kecepatan SSD dan membaca jauh lebih banyak dari itu dijalankan di HDD, pembacaan mudah tertinggal dari gerakan pemain. - Di grafik: Hanya sebagian yang tinggi (Jumlah lonjakan frame (per jenis storage), latensi baca disk) - Yang diperiksa: Rekam PhysicalDisk\Avg. Disk sec/Read (rata-rata waktu satu kali baca) dan Current Disk Queue Length di Performance Monitor Windows bersama frame time PresentMon sambil bergerak cepat. Di development build, periksa stat Streaming dan stat AsyncLoad di Unreal, serta peringatan AssetBundle.asset/allAssets di Unity Profiler (hasil diminta sebelum loading selesai sehingga main thread menunggu) - Cocok jika: Saat bergerak cepat, latensi baca disk dan antrean melonjak, dan pada saat yang sama frame melonjak atau tekstur dan objek terlambat muncul. Hilang jika adegan yang sama dijalankan di SSD - Tidak cocok jika: Disk tidak sibuk, tetapi tekstur buram: lebih mungkin “Kekurangan memori grafis (VRAM)”. Normal sejak kunjungan kedua ke tempat yang sama: lebih mungkin “Pemuatan sinkron dan kompilasi shader di main thread” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Jika game hanya berhenti pada kali pertama lalu normal, penyebabnya lebih dekat ke “Pemuatan sinkron dan kompilasi shader di main thread”. Jika berulang setiap kali bergerak dan hanya di PC dengan storage lambat, penyebabnya adalah yang ini. “Kekurangan memori grafis (VRAM)”, yaitu tekstur diturunkan lalu dinaikkan lagi karena memori grafis kurang, juga membuat tekstur buram, jadi periksa waktu tunggu baca disk dan pemakaian memori grafis bersama-sama. Pemindaian real-time antivirus juga bisa menyela setiap kali game membuka file sehingga pembacaan makin lambat. - Sumber: - [DirectStorage is coming to PC](https://devblogs.microsoft.com/directx/directstorage-is-coming-to-pc/) · Microsoft · Hard disk lama membaca puluhan MB per detik, NVMe SSD beberapa GB per detik, budget streaming aset game generasi sebelumnya sekitar 50 MB per detik, dan game open world membaca serta membuang pemandangan jauh secara real-time sambil pemain bergerak - [Texture and mesh loading](https://docs.unity3d.com/Manual/LoadingTextureandMeshData.html) · Unity · Upload sinkron membaca dan mengunggah data di main thread dalam satu frame sehingga terjadi jeda yang terlihat; upload asinkron melakukan streaming di beberapa frame - [Texture Streaming Overview for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/texture-streaming-overview-for-unreal-engine) · Epic Games · Streamer menaikkan dan menurunkan resolusi tekstur (mip) sesuai sudut pandang; sebagian besar perhitungan dilakukan di worker thread asinkron, dan mip yang terlihat di layar dimuat lebih dulu - [Profiler markers reference](https://docs.unity3d.com/Manual/profiler-markers.html) · Unity · Peringatan AssetBundle.asset/allAssets: hasil diminta sebelum loading selesai sehingga main thread berhenti untuk menunggu - [Stat Commands in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/stat-commands-in-unreal-engine) · Epic Games · stat Streaming (memori dan jumlah tekstur streaming), stat AsyncLoad (statistik loading asinkron) - [Windows Performance Monitor Disk Counters Explained](https://learn.microsoft.com/en-us/archive/blogs/askcore/windows-performance-monitor-disk-counters-explained) · Microsoft · Avg. Disk sec/Read adalah rata-rata waktu untuk menyelesaikan satu kali baca (latensi I/O), Current Disk Queue Length adalah panjang antrean disk pada saat pengukuran - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame) - [About regular quick and full scans with Microsoft Defender Antivirus](https://learn.microsoft.com/en-us/defender-endpoint/schedule-antivirus-scans) · Microsoft · Perlindungan real-time memeriksa file setiap kali file dibuka dan ditutup #### cg-crowd · Beban rendering kerumunan besar · Render/animation cost of crowds Saat ratusan karakter masuk ke satu layar seperti di siege atau world boss, biaya menggambarnya saja sudah tidak sanggup ditangani. - Mengapa → Akibatnya → Di layar: Ratusan karakter dan efek bertumpuk di satu layar → Biaya animasi, bayangan, name tag, dan efek naik sebanding dengan jumlah karakter → FPS turun 60 → 15 sehingga semua gerakan patah-patah dan input juga terlambat - Gejala: Patah-patah, Input lag / Faktor: Stall - Siapa: Lokasi/channel tertentu, Hanya saya / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Sederhanakan model berdasarkan jarak (LOD), batasi jumlah karakter yang ditampilkan, sediakan opsi penyederhanaan efek, turunkan frekuensi update animasi. - Kisaran angka: Meskipun hanya 0,02–0,1 ms per karakter, 300 karakter berarti 6–30 ms. Frame budget pada 60 FPS adalah 16,7 ms, jadi itu saja sudah memakai lebih dari 1/3-nya, dan kalau banyak bisa melewatinya. - Di grafik: Naik mengikuti beban (Frame time, jumlah karakter di layar) - Yang diperiksa: Bandingkan frame time serta CPUBusy dan GPUBusy di PresentMon sebelum dan sesudah siege atau world boss. Di development build, gunakan stat Unit di Unreal (waktu game thread, rendering thread, dan GPU) - Cocok jika: Frame time ikut naik seiring bertambahnya karakter di layar, dan langsung membaik jika batas jumlah karakter yang ditampilkan atau opsi penyederhanaan efek diaktifkan - Tidak cocok jika: Melonjak tanpa kaitan dengan jumlah karakter: lebih mungkin “Lonjakan frame time” atau “Garbage collection di klien”. FPS normal, tetapi hanya gerakan pemain lain yang tertinggal: lebih mungkin “Bottleneck pemrosesan paket di main thread” - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Introduction to level of detail](https://docs.unity3d.com/Manual/LevelOfDetail.html) · Unity · Tanpa LOD, objek yang terlihat kecil di layar pun digambar dengan kompleksitas yang sama; LOD mengurangi beban menggambar - [Animation Budget Allocator in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/animation-budget-allocator-in-unreal-engine) · Epic Games · Mengurangi update (tick) animasi skeletal mesh secara dinamis untuk menjaga waktu animasi tetap dalam budget - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Membedakan apakah CPU atau GPU yang memperlambat frame dengan FrameTime, CPUBusy, dan GPUBusy - [Stat Commands in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/stat-commands-in-unreal-engine) · Epic Games · stat Unit: frame time total serta waktu game thread, rendering thread, dan GPU #### cg-net-mainthread · Bottleneck pemrosesan paket di main thread · Network processing on the main thread Jika paket yang diterima hanya diproses dalam jumlah tertentu per frame, paket yang datang bertumpuk terus terdorong ke frame berikutnya. - Mengapa → Akibatnya → Di layar: Di tempat ramai, ribuan update tiba setiap detik → Main thread terbentur batas jumlah pemrosesan per frame dan tidak sempat membaca semuanya → Gerakan pemain lain makin lama makin terlambat, lalu diterapkan sekaligus - Gejala: Fast forward, Input lag / Faktor: Stall, Latensi - Siapa: Lokasi/channel tertentu, Hanya saya / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: terima dan parse paket di thread terpisah, gabungkan update posisi lama untuk objek yang sama dan terapkan yang terbaru saja. Server: di tempat ramai, kirim update karakter yang jauh dengan frekuensi lebih rendah untuk mengurangi volume kirim. - Kisaran angka: Begitu paket yang belum diproses menumpuk, hanya butuh beberapa detik sampai tertinggal sebanyak 1 detik. - Di grafik: Naik mengikuti beban (Jumlah paket terima yang belum diproses, latensi dari diterima hingga diterapkan) - Yang diperiksa: Catat di log jumlah paket yang tersisa karena tidak sempat diproses klien di setiap frame, serta latensi dari waktu paket tiba hingga diterapkan ke game, lalu periksa bersama jumlah pemain di sekitar - Cocok jika: Di tempat ramai, jumlah paket yang tersisa dan latensi penerapan terus bertambah, sedangkan pada saat yang sama ping dan interval kirim server normal - Tidak cocok jika: Tidak ada latensi penerapan, tetapi paketnya sendiri tiba terlambat: mengarah ke jalur jaringan. Frame time naik tajam: lebih mungkin “Beban rendering kerumunan besar” - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Jika bandwidth kurang, tidak semua actor direplikasi setiap kali; prioritas ditentukan dari jarak ke pengamat dan waktu sejak replikasi terakhir - [Replication Graph in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/replication-graph-in-unreal-engine) · Epic Games · Game dengan banyak pemain dan objek replikasi (MMORPG dan sebagainya) harus mengelompokkannya per lokasi dan hanya mengirim objek yang diperlukan agar terhindar dari bottleneck CPU server #### cg-no-buffer · Buffer interpolasi tidak ada atau terlalu pendek · Missing/short interpolation buffer Jika paket server langsung digambar begitu diterima, jitter (variasi selang waktu kedatangan paket) langsung terlihat di layar. - Mengapa → Akibatnya → Di layar: Posisi yang diterima langsung digambar, atau buffer lebih pendek dari jitter → Berhenti selama paket terlambat, lalu melompat saat paket datang bertumpuk → Karakter lain bergerak tersendat-sendat - Gejala: Patah-patah / Faktor: Jitter - Siapa: Hanya saya / Kapan: Selalu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: siapkan buffer interpolasi, sesuaikan panjang buffer secara otomatis menurut kondisi koneksi. Server: terapkan lag compensation (hit registration dengan memutar mundur waktu) agar tembakan ke posisi lawan di masa lalu (sepanjang buffer) tetap dinilai tepat. - Kisaran angka: Biasanya buffer diatur sekitar 2 kali interval pengiriman paket dari server (100 ms jika menerima 20 kali per detik). - Di grafik: Selalu tinggi sejak awal (Interval kedatangan paket, berapa kali buffer interpolasi kosong) - Yang diperiksa: Di klien, catat distribusi interval kedatangan paket server dan jumlah frame yang berhenti atau beralih ke ekstrapolasi karena tidak ada snapshot berikutnya untuk diinterpolasi - Cocok jika: Variasi interval kedatangan sering melebihi panjang buffer interpolasi, dan setiap kali itu buffer kosong sehingga karakter lain tersendat. Berkurang jika buffer diperpanjang - Tidak cocok jika: Buffer sudah cukup, tetapi tetap tersendat: periksa apakah interval kirim server sendiri tidak teratur (tick terlambat) - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Buffer yang lebih panjang membuat gerakan lebih mulus, tetapi lawan juga terlihat dalam posisi masa lalu sepanjang itu. Karena itu, hit registration dibarengi lag compensation: server memutar mundur waktu ke “masa lalu yang dilihat pemain itu” untuk memeriksanya. - Sumber: - [Interpolation and extrapolation (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/interpolation.html) · Unity · Interpolasi dengan buffer, yaitu sengaja menggambar lebih lambat untuk menunggu paket yang terlambat; makin besar buffer, makin akurat, tetapi latensinya juga makin besar - [Struct ClientTickRate (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/api/Unity.NetCode.ClientTickRate.html) · Unity · Nilai default buffer interpolasi InterpolationTimeNetTicks = 2 (setara 2 kali pengiriman server) - [Physics (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/physics.html) · Unity · Lag compensation: server mencari state collision yang dilihat klien pada tick itu untuk menentukan apakah serangan kena #### cg-extrap · Ekstrapolasi berlebihan (dead reckoning) · Over-extrapolation / dead reckoning Selama paket tidak datang, objek terus ditampilkan bergerak dengan kecepatan terakhir, lalu dikembalikan begitu ketahuan salah. - Mengapa → Akibatnya → Di layar: Paket berhenti diterima, objek terus digerakkan dengan arah dan kecepatan terakhir → Sebenarnya lawan sudah berhenti atau berbelok → Karakter lawan berjalan cukup jauh lalu tiba-tiba pindah ke posisi sebenarnya atau menembus dinding. Jika interval kedatangan paket tidak beraturan, karakter berulang kali melaju ke depan lalu tertarik kembali sehingga bergerak seperti bergetar - Gejala: Teleport, Patah-patah / Faktor: Packet loss, Jitter - Siapa: Hanya saya / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Batasi waktu ekstrapolasi (misalnya 200–250 ms), geser perlahan ke posisi yang benar saat ternyata salah. - Kisaran angka: Pada kecepatan 6 m/s, selisih 300 ms saja sudah membuat posisi meleset 1,8 m. - Di grafik: Melonjak acak sesekali (Waktu ekstrapolasi, jarak koreksi posisi) - Yang diperiksa: Catat berapa lama karakter lain digambar dengan ekstrapolasi dan seberapa jauh posisinya dikoreksi setelah paket baru datang - Cocok jika: Setiap kali paket terputus, waktu ekstrapolasi memanjang tanpa batas, lalu jarak koreksinya membesar hingga beberapa m - Tidak cocok jika: Ekstrapolasi sudah berhenti cepat, tetapi karakter tetap teleport: packet loss atau latensinya sendiri besar, periksa sisi koneksi dan rute - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Interpolation and extrapolation (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/interpolation.html) · Unity · Ekstrapolasi yang terus bergerak dengan arah dan kecepatan yang sama saat snapshot berikutnya tidak datang tepat waktu sering salah, jadi diberi batas (default Unity 20 tick, sekitar 1/3 detik pada 60 Hz) - [Peeking into VALORANT's Netcode](https://technology.riotgames.com/news/peeking-valorants-netcode) · Riot Games · Jika tebakan untuk mengisi data yang terlambat atau hilang ternyata salah, posisi tidak cocok dengan server sehingga karakter melompat atau dikoreksi seperti meluncur #### cg-predict · Prediksi sisi klien meleset · Prediction mismatch / reconciliation Klien Anda menampilkan gerakan lebih dulu, tetapi jika server menghitungnya berbeda, karakter Anda tertarik kembali. - Mengapa → Akibatnya → Di layar: Klien bergerak lebih dulu sebelum konfirmasi server (prediksi) → Server menghitung collision, kecepatan gerak, atau buff secara berbeda, atau tidak menerima perintahnya → Saat konfirmasi datang, karakter Anda tertarik ke belakang - Gejala: Rubber banding / Faktor: Packet loss, Latensi - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area, Sesekali secara acak - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: pakai kode gerakan yang sama dengan server, kirim input secara duplikat, haluskan koreksi. Server: pakai kode gerakan yang sama dengan klien, saring input duplikat berdasarkan nomor input agar hanya diproses sekali. - Kisaran angka: Jarak karakter tertarik adalah “lama ketidakcocokan × kecepatan gerak”. Hilangnya beberapa perintah saja sudah membuat karakter tertarik 1–3 m. - Di grafik: Melonjak acak sesekali (Jumlah rekonsiliasi server (prediksi gagal)) - Yang diperiksa: Catat jumlah dan jarak koreksi posisi yang dikirim server. Di Unreal, hitung koreksi ClientAdjustPosition dari server; di Unity Netcode for Entities, hitung berapa kali simulasi diputar mundur dan dihitung ulang karena prediksi gagal - Cocok jika: Koreksi menumpuk pada waktu laporan rubber banding, dan jarak koreksi berulang kali besar pada buff, medan, atau skill gerak tertentu - Tidak cocok jika: Koreksi hanya menumpuk saat packet loss tinggi: mengarah ke paket input yang hilang (koneksi). Tidak ada koreksi, tetapi hanya karakter lain yang terlihat tertarik: lebih mungkin “Ekstrapolasi berlebihan (dead reckoning)” - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Introduction to prediction (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/intro-to-prediction.html) · Unity · Klien dan server memprediksi dengan kode simulasi yang sama; jika berbeda dari state server (prediksi gagal), simulasi diputar mundur dan dihitung ulang, dan koreksinya terlihat - [Use the command stream to handle user inputs (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/command-stream.html) · Unity · Untuk mengantisipasi packet loss, input beberapa tick sebelumnya dikirim secara duplikat bersama input terbaru - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Klien bergerak lebih dulu dan server mereproduksi gerakan yang sama; jika posisinya berbeda, server mengoreksi dengan ClientAdjustPosition lalu gerakan yang tersimpan diterapkan ulang #### cg-fixed-step · Catch-up fixed timestep yang lepas kendali · Fixed-timestep catch-up / spiral of death Setelah sekali berhenti, game menghitung kerja yang tertunda sekaligus, dan perhitungan itu membuatnya tertinggal lagi. - Mengapa → Akibatnya → Di layar: Simulasi game berjalan dengan interval tetap, lalu sekali berhenti → Step yang tertunda dihitung sekaligus dalam satu frame → Frame panjang terjadi beruntun dan melonjak, atau terbentur batas sehingga dunia game melambat - Gejala: Patah-patah, Fast forward, Slow motion / Faktor: Stall - Siapa: Hanya saya / Kapan: Sesekali secara acak, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Batasi catch-up per frame, tangani sisa waktu dengan interpolasi. - Di grafik: Melonjak acak sesekali (Frame time, jumlah fixed step per frame) - Yang diperiksa: Di profiler development build, periksa berapa kali fixed step berjalan dalam satu frame (di Unity, jumlah marker tahap FixedUpdate seperti FixedBehaviourUpdate) bersama frame time - Cocok jika: Setelah satu frame panjang, menyusul beruntun frame panjang yang menjalankan banyak step, dan saat menyentuh batas (Maximum Allowed Timestep di Unity) waktu game berjalan lebih lambat dari waktu nyata - Tidak cocok jika: Frame panjang hanya terjadi sekali: lebih mungkin “Lonjakan frame time” atau “Garbage collection di klien” - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Perhitungan fisika Unity (FixedUpdate) adalah contoh khas fixed step (default 0,02 detik, 50 kali per detik). Maximum Allowed Timestep di pengaturan Time (waktu maksimum yang dikejar dalam satu frame, default sekitar 0,33 detik) adalah batas catch-up. Jika satu frame lebih panjang dari itu, kelebihan waktunya dibuang, sehingga jam game tertinggal dari waktu nyata sebanyak itu. - Sumber: - [Set fixed timestep to optimize physics simulation frequency](https://docs.unity3d.com/Manual/physics-optimization-cpu-frequency.html) · Unity · Default Fixed Timestep 0,02 detik (50 kali per detik); jika frame panjang, step fisika dijalankan beberapa kali dalam satu frame sehingga beban bertambah - [Handling variation in time](https://docs.unity3d.com/Manual/time-handling-variations.html) · Unity · Default Maximum Allowed Timestep 1/3 detik (0.3333333); walaupun game berhenti 1 detik, waktu game hanya maju 0,333 detik; batas ini mencegah lingkaran setan ketika step catch-up memperlambat game lagi - [Profiler markers reference](https://docs.unity3d.com/Manual/profiler-markers.html) · Unity · FixedBehaviourUpdate: bagian eksekusi MonoBehaviour.FixedUpdate; marker fisika dipanggil di tahap FixedUpdate #### cg-clock · Kesalahan sinkronisasi jam · Clock sync error Jika waktu server yang diperkirakan klien salah, titik waktu interpolasi dan pengecekan cooldown tidak cocok dengan server. - Mengapa → Akibatnya → Di layar: Waktu server hanya disamakan sekali saat login, lalu dibiarkan meski ping berubah → Titik waktu interpolasi dan waktu berakhirnya cooldown tidak cocok dengan server → Lawan sesekali tersendat, skill ditolak padahal cooldown sudah selesai - Gejala: Patah-patah, Aksi hilang / rollback / Faktor: Latensi - Siapa: Hanya saya / Kapan: Makin lama menyala, Sesekali secara acak - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Sinkronkan waktu secara berkala (ukur waktu pulang-pergi lalu koreksi), sesuaikan perlahan tanpa perubahan mendadak, ukur waktu yang berlalu dengan monotonic clock, jangan dengan jam PC. - Di grafik: Naik perlahan (Selisih waktu server yang diperkirakan) - Yang diperiksa: Catat secara berkala selisih antara waktu server yang diperkirakan klien dan waktu server (nomor tick) yang dikirim server di dalam paket - Cocok jika: Selisih makin besar seiring waktu sejak login, atau melonjak sekaligus saat jam PC disesuaikan, dan sekitar waktu itu laporan skill ditolak atau tersendat bertambah - Tidak cocok jika: Selisih tetap kecil, tetapi skill ditolak: mengarah ke keputusan server atau latensi - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Jika waktu yang berlalu diukur dengan tanggal dan jam PC (wall clock), waktu game melonjak begitu Windows menyesuaikan jam dengan waktu internet atau pengguna mengubah jam. Waktu yang berlalu harus diukur dengan monotonic clock yang tidak pernah mundur (Stopwatch dan sebagainya). - Sumber: - [RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification](https://www.rfc-editor.org/rfc/rfc5905) · IETF · Cara menghitung latensi pulang-pergi dan selisih jam dari empat stempel waktu request dan response - [Acquiring high-resolution time stamps](https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps) · Microsoft · QueryPerformanceCounter (dipakai Stopwatch) adalah jam untuk mengukur waktu berlalu yang tidak disinkronkan dengan waktu eksternal; waktu sistem dipakai hanya jika butuh waktu UTC - [Time synchronization (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/time-synchronization.html) · Unity · Memperkirakan waktu server dari waktu pulang-pergi, lalu menyamakannya dengan menyesuaikan laju waktu sedikit demi sedikit tanpa mengubah jam secara drastis #### cg-float-time · Hilangnya presisi waktu bertipe float · Float time precision loss on long sessions Jika waktu game disimpan dalam format bilangan desimal berpresisi rendah (float), makin lama game menyala, makin turun resolusi waktunya (selisih waktu terkecil yang bisa dibedakan), sehingga gerakan dan efek bergetar. - Mengapa → Akibatnya → Di layar: Waktu sejak game dinyalakan diakumulasi dalam float atau langsung diteruskan ke shader → Makin lama game menyala, makin besar selisih terkecil yang bisa dinyatakan float → Karakter, animasi, dan efek yang mengalir bergetar hanya di klien yang sudah menyala berhari-hari, lalu normal lagi setelah game dimulai ulang - Gejala: Patah-patah / Faktor: Jitter - Siapa: Hanya saya / Kapan: Makin lama menyala - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Simpan waktu yang berlalu dalam double (64-bit) atau integer, reset waktu yang diteruskan ke shader secara berkala, jalankan tes otomatis jangka panjang selama beberapa hari. - Kisaran angka: Float 32-bit hanya punya sedikit lebih dari 7 digit signifikan, sehingga setelah menyala sehari (sekitar 86.400 detik) resolusi waktunya sekitar 8 ms, kira-kira setengah dari satu frame 60 FPS (16,7 ms), dan setelah seminggu sekitar 60 ms, lebih besar dari satu frame. - Di grafik: Naik perlahan (Laporan getaran per lama klien menyala) - Yang diperiksa: Minta laporan getaran disertai lama klien menyala, lalu bandingkan sebelum dan sesudah game dimulai ulang. Di sisi pengembangan, uji dengan mengatur nilai waktu mulai game seolah sudah lewat beberapa hari - Cocok jika: Bergetar hanya di klien yang menyala berhari-hari, hilang setelah dimulai ulang, dan makin parah makin lama klien menyala - Tidak cocok jika: Langsung bergetar begitu dinyalakan: lebih mungkin “Buffer interpolasi tidak ada atau terlalu pendek” atau “Resolusi timer” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Terutama muncul di MMO mobile yang fitur auto hunt-nya dinyalakan dan tidak dimatikan selama berhari-hari. Time.time di Unity juga bertipe float, sehingga Unity menyediakan Time.timeAsDouble yang bertipe double secara terpisah dan menyarankan pemakaiannya. - Sumber: - [Time.timeAsDouble](https://docs.unity3d.com/ScriptReference/Time-timeAsDouble.html) · Unity · Versi double dari Time.time; makin lama game menyala, makin presisi dibanding float, sehingga umumnya disarankan - [Floating-point numeric types (C# reference)](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/floating-point-numeric-types) · Microsoft · Presisi float sekitar 6–9 digit, double sekitar 15–17 digit #### cg-vsync · V-Sync dan antrean render · V-Sync, render queue Frame yang sudah digambar GPU ditumpuk beberapa buah di antrean, lalu dikirim ke layar mengikuti siklus refresh monitor; selama itu input terlambat. - Mengapa → Akibatnya → Di layar: Driver grafis menumpuk 1–3 frame lebih dulu di antrean → Input butuh waktu lebih lama sebanyak itu sampai tampil di layar → Ping rendah, tetapi kontrol terasa berat dan lamban - Gejala: Input lag, Patah-patah / Faktor: Latensi - Siapa: Hanya saya / Kapan: Selalu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Dukung mode latensi rendah, perkecil antrean frame, sediakan opsi batas FPS sedikit di bawah refresh rate, aktifkan fitur frame pacing di ponsel. - Tugas Pihak Eksternal: Imbau pemain untuk memasang batas FPS sedikit di bawah refresh rate saat memakai monitor variable refresh rate, dan untuk mengaktifkan mode latensi rendah di driver grafis. - Kisaran angka: Pada 60 Hz, satu frame 16,7 ms. Jika CPU lebih cepat dari GPU atau siklus layar sehingga antrean tiga frame (default DirectX 11) penuh, latensinya bertambah 50 ms. Pada V-Sync double buffer, frame yang butuh 17 ms harus menunggu sampai refresh layar berikutnya (33,3 ms), dan selama itu frame sebelumnya tampil sekali lagi. - Di grafik: Selalu tinggi sejak awal (Latensi dari input hingga layar) - Yang diperiksa: Bandingkan MsClickToPhotonLatency dan MsAllInputToPhotonLatency (dari input mouse dan keyboard sampai dikirim ke layar) serta DisplayLatency di PresentMon sambil mengganti V-Sync, mode latensi rendah, dan batas FPS. MsPCLatency (sejak PC menerima input sampai dikirim ke layar) hanya tercatat jika game mengirim event PC Latency - Cocok jika: Saat V-Sync aktif atau tanpa batas FPS, latensi ini bertambah satu atau dua frame (puluhan ms), lalu berkurang dengan mode latensi rendah atau batas FPS sedikit di bawah refresh rate. Ping tidak berubah - Tidak cocok jika: Latensi di dalam PC rendah, tetapi kontrol tetap terlambat: lebih mungkin “Latensi layar, perangkat input, dan frame generation”. Ping tinggi: mengarah ke sisi jaringan - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: V-Sync (vertical sync) adalah pengaturan yang hanya mengirim frame baru tepat saat monitor mengganti gambar. Screen tearing hilang, tetapi input terlambat sebanyak waktu menunggu momen itu, dan jika FPS turun di bawah 60, FPS bolak-balik antara 60 dan 30 sehingga game patah-patah. Monitor variable refresh rate mengganti gambar mengikuti saat frame siap sehingga waktu tunggu ini berkurang. Hal yang sama terjadi di ponsel. Jika game 30 FPS tidak bisa mengirim frame secara merata ke layar 60 Hz, rata-ratanya memang 30 FPS, tetapi tiap frame tampil dengan lama yang tidak beraturan seperti 49, 16, dan 33 ms sehingga game patah-patah (contoh dari dokumentasi developer Android). Masalah ini dikurangi dengan library frame pacing Android (meratakan interval keluaran frame) atau opsi serupa di engine. - Sumber: - [IDXGIDevice1::SetMaximumFrameLatency](https://learn.microsoft.com/en-us/windows/win32/api/dxgi/nf-dxgi-idxgidevice1-setmaximumframelatency) · Microsoft · Default jumlah frame yang bisa ditumpuk driver di antrean adalah 3 (1–16) - [Reduce latency with DXGI 1.3 swap chains](https://learn.microsoft.com/en-us/windows/uwp/gaming/reduce-latency-with-dxgi-1-3-swap-chains) · Microsoft · Present terblokir sampai antrean kosong sehingga frame menunggu hampir satu frame lagi antara selesai digambar dan ditampilkan; dikurangi dengan waitable swap chain - [Frame Pacing library](https://developer.android.com/games/sdk/frame-pacing) · Android (Google) · Di layar 60 Hz, jika tidak ada frame baru, frame sebelumnya ditampilkan lagi; contoh frame time game 30 FPS yang tidak beraturan seperti 49, 16, dan 33 ms - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · MsPCLatency (sejak PC menerima input hingga dikirim ke layar), MsClickToPhotonLatency (klik mouse hingga layar), MsAllInputToPhotonLatency (input keyboard dan mouse hingga layar), DisplayLatency (frame diserahkan hingga dikirim ke monitor) - [PresentMon Console Application (README-ConsoleApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-ConsoleApplication.md) · Intel · MsPCLatency hanya tercatat jika aplikasi mengirim event PC Latency (--track_pc_latency), MsAllInputToPhotonLatency diukur dari input keyboard dan mouse #### cg-leak · Kebocoran memori di klien · Client memory leak Makin lama game menyala, makin besar memori yang dipakai sehingga game makin lambat dan akhirnya tertutup paksa. - Mengapa → Akibatnya → Di layar: Tekstur, UI, dan efek tidak dilepas saat berpindah area bolak-balik → GC makin sering berjalan dan memori OS kurang sehingga terjadi swap → Setelah beberapa jam bermain, game makin patah-patah lalu tertutup paksa (bagi pemain terlihat seperti disconnect) - Gejala: Patah-patah, Disconnect / Faktor: Stall - Siapa: Hanya saya / Kapan: Makin lama menyala - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Ukur pemakaian memori saat berpindah area, cari dan perbaiki tekstur, UI, dan efek yang tidak dilepas, jalankan tes otomatis jangka panjang (soak test). - Di grafik: Naik perlahan (Memori proses game) - Yang diperiksa: Rekam Process(game)\Private Bytes selama beberapa jam dengan Performance Monitor. Untuk mobile, periksa alasan penutupan di ApplicationExitInfo Android (REASON_LOW_MEMORY) dan laporan jetsam iOS - Cocok jika: Memori naik setiap kali berpindah area dan tidak turun lagi, dan makin lama game menyala, makin sering patah-patah dan tertutup paksa - Tidak cocok jika: Memori stabil, tetapi makin lama game menyala hanya getarannya yang makin parah: lebih mungkin “Hilangnya presisi waktu bertipe float” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Ponsel umumnya bertahan dengan mengompresi memori. Jika memori tetap kurang, OS langsung menutup game (terlempar keluar). Makin kecil RAM perangkat, makin cepat game ditutup. - Sumber: - [Memory allocation among processes](https://developer.android.com/topic/performance/memory-management) · Android (Google) · Android bertahan dengan mengompresi memori ke zRAM, dan jika tetap kurang, low memory killer menutup proses; jika aplikasi yang sedang tampil di depan ditutup, terlihat seperti crash - [Identifying high-memory use with jetsam event reports](https://developer.apple.com/documentation/xcode/identifying-high-memory-use-with-jetsam-event-reports) · Apple · iOS menutup paksa aplikasi (jetsam) jika tekanan memori tidak mereda, dan aplikasi yang melewati batas memorinya menjadi sasaran penutupan - [Find user-mode memory leaks with Performance Monitor (PerfMon)](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-performance-monitor-to-find-a-user-mode-memory-leak) · Microsoft · Rekam Process > Private Bytes (memori privat yang dialokasikan proses) dan Virtual Bytes dalam waktu lama; jika terus naik, berarti ada kebocoran - [ApplicationExitInfo](https://developer.android.com/reference/android/app/ApplicationExitInfo) · Android (Google) · REASON_LOW_MEMORY: low memory killer sistem menutup proses aplikasi (perangkat yang tidak mendukungnya melaporkannya sebagai REASON_SIGNALED dengan SIGKILL) #### cg-crash · Crash di klien · Client crash Game tertutup karena error yang tidak tertangani. Bagi pemain ini terlihat seperti disconnect, tetapi server normal. - Mengapa → Akibatnya → Di layar: Null reference, memori kurang, error driver grafis → Proses game tertutup paksa → Laporan “terlempar keluar”. Pada saat yang sama pemain lain baik-baik saja - Gejala: Disconnect / Faktor: Stall - Siapa: Hanya saya / Kapan: Saat melakukan aksi tertentu, Sesekali secara acak - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Kumpulkan laporan crash, buat statistik per perangkat dan driver, perbaiki lebih dulu error yang paling banyak terjadi. - Tugas Pihak Eksternal: Jika crash terkumpul pada versi driver grafis tertentu, imbau pemain untuk memperbarui driver. - Di grafik: Hanya sebagian yang tinggi (Jumlah crash (per perangkat, driver grafis, dan build)) - Yang diperiksa: Periksa laporan crash dan crash rate di Android vitals per perangkat, driver, dan build. Di PC pemain, periksa event ID 1000 di log Application pada Event Viewer (nama modul yang error) dan catatan “Display driver stopped responding and has recovered” - Cocok jika: Ada catatan crash pada waktu laporan disconnect, dan pemain lain di server yang sama pada waktu itu normal. Terkumpul pada perangkat, versi driver, atau modul tertentu - Tidak cocok jika: Tidak ada catatan crash, hanya koneksinya yang putus: lebih mungkin “Mapping NAT kedaluwarsa” atau sisi koneksi - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Crashes](https://developer.android.com/topic/performance/vitals/crash) · Android (Google) · Crash adalah aplikasi yang tertutup tanpa terduga karena exception yang tidak ditangani atau sinyal (SIGSEGV dan sebagainya); dihitung di Android vitals pada Play Console - [WDDM Support for Timeout Detection and Recovery (TDR)](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/timeout-detection-and-recovery) · Microsoft · Jika GPU tidak menyelesaikan pekerjaan dalam 2 detik (default), Windows mengatur ulang driver grafis dan GPU - [The application or service crashing behavior troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/troubleshoot-application-service-crashing-behavior) · Microsoft · Event ID 1000 di log Application adalah catatan crash yang sebenarnya, berisi nama aplikasi yang error dan nama modul yang error (Faulting module name) #### cg-anticheat · Pemindaian oleh modul keamanan game (anti-cheat) · Anti-cheat scan and heartbeat Modul keamanan yang berjalan bersama game untuk mencegah cheat melakukan pemeriksaan secara berkala. Jika pemeriksaannya berat atau heartbeat (sinyal berkala yang menandakan klien masih hidup) ke server keamanan terlambat, game menjadi patah-patah atau disconnect. - Mengapa → Akibatnya → Di layar: Modul keamanan secara berkala memeriksa memori game, program yang sedang berjalan, dan driver → Selama pemeriksaan, thread game berhenti, atau heartbeat tidak terkirim tepat waktu → Tersendat sesaat dengan interval tetap; jika parah, disconnect disertai pesan error keamanan - Gejala: Patah-patah, Freeze, Disconnect / Faktor: Stall - Siapa: Hanya saya / Kapan: Secara berkala, Tepat setelah login atau maintenance, Sesekali secara acak - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: jalankan pemeriksaan berat di luar thread game dan bagi sedikit demi sedikit, bandingkan statistik patah-patah dan terlempar keluar per versi modul keamanan (jika menumpuk tepat setelah update, teruskan ke vendor modul keamanan). Server: toleransi heartbeat yang terlambat satu atau dua kali. - Kisaran angka: Pemeriksaan ringan biasanya kurang dari 1 ms, tetapi pemeriksaan berat yang berjalan di thread game bisa memakan puluhan hingga ratusan ms sekali jalan, tergantung implementasinya. - Di grafik: Melonjak secara berkala (Frame time, jumlah kick oleh anti-cheat) - Yang diperiksa: Ukur interval lonjakan di frame time PresentMon, lalu agregasikan alasan kick anti-cheat yang diterima server (di EOS, AuthenticationFailed / Authentication Timed Out di ClientActionReason, dan sebagainya) per versi modul keamanan dan spesifikasi - Cocok jika: Jeda singkat dengan interval tetap berulang tanpa kaitan dengan situasi game, dan tepat setelah update modul keamanan, patah-patah dan kick karena timeout autentikasi bertambah pada spesifikasi tertentu - Tidak cocok jika: Interval yang sama di semua spesifikasi tanpa kaitan dengan versi modul keamanan: lebih mungkin “Garbage collection di klien” atau “Pemakaian CPU oleh proses di latar belakang” - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Modul keamanan masuk jauh ke dalam OS sebagai driver, sehingga bisa bentrok dengan antivirus, overlay, atau modul keamanan game lain. Jika laporan patah-patah dan terlempar keluar menumpuk hanya pada spesifikasi tertentu tepat setelah update modul keamanan, curigai penyebab ini lebih dulu. - Sumber: - [Using the Anti-Cheat Interfaces](https://dev.epicgames.com/docs/epic-online-services/trust-and-safety/anti-cheat-interfaces/using-anti-cheat) · Epic Games · Jika server tidak menerima pesan anti-cheat dari klien dalam waktu yang ditentukan (RegisterTimeout), klien dikeluarkan karena timeout autentikasi (penyebab umumnya klien yang berhenti karena loading); jika masalahnya ada di update modul terbaru, kembalikan ke modul sebelumnya - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame) ### L2 OS dan perangkat klien (15 penyebab) #### co-background · Pemakaian CPU oleh proses di latar belakang · Background CPU contention Saat pemindaian antivirus, Windows Update, program streaming, atau video di browser memakai core CPU, thread game tidak mendapat jatah CPU dan harus menunggu. - Mengapa → Akibatnya → Di layar: Program lain memakai core CPU dalam waktu lama → Thread game menunggu jatah CPU → Frame terlambat dan pemrosesan paket yang diterima juga terlambat - Gejala: Patah-patah, Fast forward / Faktor: Stall - Siapa: Hanya saya / Kapan: Sesekali secara acak, Secara berkala - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Sesuaikan prioritas thread game, sertakan pemakaian CPU seluruh PC di log saat terjadi patah-patah untuk membedakan apakah penyebabnya program lain. - Tugas Pihak Eksternal: Imbau pemain untuk mengaktifkan Mode Game di Windows dan menutup program yang tidak perlu selama bermain (pemindaian antivirus, Windows Update, program streaming, video di browser). - Kisaran angka: Windows biasanya memberikan core sekali jalan selama beberapa ms hingga puluhan ms. Tertunda sekali saja dalam penjadwalan sudah membuat satu frame hilang. - Di grafik: Melonjak acak sesekali (Pemakaian CPU seluruh PC, frame time) - Yang diperiksa: Rekam kolom CPU di tab Processes pada Task Manager dan Processor Information(_Total)\% Processor Time di Performance Monitor bersama frame time PresentMon. Jika curiga antivirus, rekam dengan New-MpPerformanceRecording lalu cari file dan proses dengan waktu pemindaian terlama lewat Get-MpPerformanceReport - Cocok jika: Pada waktu tersendat, pemakaian CPU program lain (pemindaian antivirus, update, program streaming) melonjak, atau file di folder game masuk daftar teratas waktu pemindaian. Hilang jika program itu dimatikan atau dikecualikan - Tidak cocok jika: Pemakaian CPU rendah, tetapi seluruh layar tersendat dan suara berderak: lebih mungkin “Mode hemat daya NIC dan masalah driver” (latensi DPC) - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Windows memberi prioritas sedikit lebih tinggi pada program di jendela yang sedang aktif di depan (foreground), tetapi jika pekerjaan lebih banyak daripada core yang ada, game pun harus menunggu. Antivirus lebih sering mengganggu lewat “pemantauan real-time” daripada lewat pemakaian CPU. Setiap kali game membuka file, antivirus memeriksanya sehingga jeda saat membaca aset makin panjang. - Sumber: - [Multitasking](https://learn.microsoft.com/en-us/windows/win32/procthread/multitasking) · Microsoft · Windows memberi setiap thread time slice dan beralih ke thread berikutnya saat jatahnya habis; time slice sekitar 20 ms (berbeda menurut OS dan CPU) - [Priority Boosts](https://learn.microsoft.com/en-us/windows/win32/procthread/priority-boosts) · Microsoft · Proses di jendela depan (foreground) dinaikkan prioritasnya hingga minimal setara dengan proses di latar belakang - [About regular quick and full scans with Microsoft Defender Antivirus](https://learn.microsoft.com/en-us/defender-endpoint/schedule-antivirus-scans) · Microsoft · Perlindungan real-time memeriksa setiap kali file dibuka dan ditutup, dan setiap kali folder dibuka - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · Counter Processor Information: % Processor Time - [Performance analyzer for Microsoft Defender Antivirus](https://learn.microsoft.com/en-us/defender-endpoint/tune-performance-defender-antivirus) · Microsoft · Rekam dengan New-MpPerformanceRecording lalu lihat file, path, dan proses teratas yang memengaruhi waktu pemindaian dengan Get-MpPerformanceReport - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame) #### co-power · Mode hemat daya dan thermal throttling · Power saving, thermal throttling Mode baterai laptop, mode hemat daya ponsel, dan panas perangkat menurunkan kecepatan CPU dan GPU. Ciri penurunan karena panas: awalnya normal, lalu baru melambat setelah cukup lama. - Mengapa → Akibatnya → Di layar: Mode baterai atau hemat daya aktif, atau perangkat menjadi panas → Clock CPU dan GPU diturunkan 30–50%, tergantung perangkat → Dengan mode hemat daya, FPS turun dan game patah-patah sejak awal; karena panas, setelah bermain beberapa menit hingga sekitar 20 menit - Gejala: Patah-patah, Input lag / Faktor: Stall - Siapa: Hanya saya / Kapan: Makin lama menyala, Selalu - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Atur opsi grafis secara otomatis, kelola panas dengan batas FPS, turunkan opsi lebih awal berdasarkan tingkat panas yang dilaporkan OS (thermalState di iOS, API status termal di Android), tandai file executable agar memakai GPU diskrit di laptop dengan dua chip grafis (ekspor NvOptimusEnablement dan AmdPowerXpressRequestHighPerformance). - Tugas Pihak Eksternal: Imbau pemain untuk mematikan mode hemat daya dan menyambungkan laptop ke listrik, untuk laporan “laptop bagus, tetapi FPS rendah” periksa chip grafis mana yang menjalankan game lalu minta pemain menetapkan game ke GPU berperforma tinggi di pengaturan grafis Windows. - Di grafik: Naik perlahan (FPS, clock CPU dan GPU) - Yang diperiksa: Rekam CPUFrequency, GPUFrequency, CPUTemperature, dan GPUTemperature di PresentMon bersama frame time selama 20–30 menit, lalu periksa chip grafis yang menjalankan game lewat kolom GPU engine di tab Processes pada Task Manager. Untuk mobile, rekam API termal Android (getThermalHeadroom, status termal) dan thermalState iOS bersama FPS - Cocok jika: FPS turun sejak clock turun setelah suhu naik, atau clock rendah hanya dalam mode baterai atau hemat daya. Atau game berjalan di grafis terintegrasi - Tidak cocok jika: Clock dan suhu tetap, tetapi FPS turun: lebih mungkin “Pemakaian CPU oleh proses di latar belakang” atau “Kebocoran memori di klien” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Laptop dengan dua chip grafis kadang menjalankan game di grafis terintegrasi yang lebih lambat untuk menghemat daya. Jika laporannya “laptop bagus, tetapi FPS rendah”, periksa dulu chip grafis mana yang menjalankan game. - Sumber: - [Thermal API](https://developer.android.com/games/optimize/adpf/thermal) · Android (Google) · Perangkat hanya mempertahankan performa tinggi dalam waktu terbatas, lalu mengalami thermal throttling karena panas; disarankan menurunkan beban lebih awal berdasarkan status termal - [thermalState](https://developer.apple.com/documentation/foundation/processinfo/thermalstate-swift.property) · Apple · Tingkat termal saat ini yang dilaporkan iOS; jika tingkatnya naik, aplikasi harus mengurangi pemakaian sumber daya - [Selecting the Best Graphics Device to Run a 3D Intensive Application](https://gpuopen.com/learn/amdpowerxpressrequesthighperformance/) · AMD · Di laptop dengan dua chip grafis, game 60 FPS bisa menjadi 30 FPS jika berjalan di grafis terintegrasi; GPU diskrit dipilih dengan mengekspor AmdPowerXpressRequestHighPerformance - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Merekam CPUFrequency dan GPUFrequency (clock) serta CPUTemperature dan GPUTemperature (suhu) per frame - [GPUs in the task manager](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/) · Microsoft · Task Manager punya kolom yang menunjukkan pemakaian GPU per proses beserta GPU dan engine mana yang dipakai #### co-timer · Resolusi timer · Timer resolution (Windows 15.6ms) Timer default Windows bekerja dalam satuan 15,6 ms, sehingga “tidur 1 ms saja” sebenarnya memanjang sampai siklus timer berikutnya, paling lama 15,6 ms. - Mengapa → Akibatnya → Di layar: Batas frame dan pengiriman paket diimplementasikan dengan Sleep (menunggu sebentar) → OS hanya membangunkan thread dalam satuan 15,6 ms → Interval frame dan interval pengiriman input tidak beraturan - Gejala: Patah-patah / Faktor: Jitter - Siapa: Hanya saya / Kapan: Selalu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Gunakan timer resolusi tinggi, atur pacing berbasis event atau V-Sync tanpa menunggu dengan sleep. - Kisaran angka: Dengan satuan 15,6 ms, interval 16,7 ms tidak bisa dicapai, sehingga interval frame bolak-balik antara 15,6 ms dan 31,2 ms. - Di grafik: Selalu tinggi sejak awal (Distribusi interval frame) - Yang diperiksa: Periksa distribusi MsBetweenPresents (interval frame) di PresentMon dan bagian “Platform Timer Resolution” di laporan powercfg /energy (proses yang mengubah resolusi timer) - Cocok jika: Interval frame terkumpul di kelipatan 15,6 ms seperti 15,6 ms dan 31,2 ms, dan game tidak meminta resolusi timer yang lebih tinggi - Tidak cocok jika: Interval tersebar merata: kecil kemungkinan karena timer, lebih mungkin “Pemakaian CPU oleh proses di latar belakang” atau beban frame - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Di Windows versi lama, jika satu program mengubah timer menjadi 1 ms, perubahan itu berlaku untuk semua program. Karena itu sempat ada anggapan “game jadi lebih mulus kalau browser dibiarkan terbuka”. Sejak Windows 10 versi 2004, perubahan hanya berlaku untuk program yang memintanya, dan Windows 11 bisa mengabaikan permintaan dari jendela yang diminimalkan atau tertutup sepenuhnya dan tidak mengeluarkan suara. - Sumber: - [_WDF_TIMER_CONFIG (wdftimer.h)](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdftimer/ns-wdftimer-_wdf_timer_config) · Microsoft · Akurasi timer biasa adalah interval tick clock sistem, default 15,6 ms; timer resolusi tinggi 1 ms - [timeBeginPeriod function (timeapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod) · Microsoft · Sebelum Windows 10 2004 berupa pengaturan global, sesudahnya hanya berlaku untuk proses yang meminta; Windows 11 tidak menjamin resolusi tinggi untuk proses dengan jendela yang tertutup atau diminimalkan - [CreateWaitableTimerExW function (synchapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createwaitabletimerexw) · Microsoft · Flag waitable timer resolusi tinggi CREATE_WAITABLE_TIMER_HIGH_RESOLUTION - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · MsBetweenPresents: waktu (ms) antara pemanggilan Present() saat ini dan pemanggilan sebelumnya - [Results for the Idle Energy Efficiency Assessment](https://learn.microsoft.com/en-us/windows-hardware/test/assessments/results-for-the-idle-energy-efficiency-assessment) · Microsoft · Resolusi timer sistem default 15,6 ms; proses yang mengubah resolusi timer bisa ditemukan di bagian “Platform Timer Resolution” laporan energi - [Powercfg command-line options](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/powercfg-command-line-options) · Microsoft · powercfg /energy: menganalisis sistem dan membuat laporan energi (HTML) #### co-mobile-bg · Aplikasi mobile masuk ke latar belakang · App suspended in background Jika Anda keluar sebentar dari game untuk melihat notifikasi, OS menangguhkan aplikasi (suspend) beberapa detik kemudian, dan selama itu server memutus koneksi Anda. - Mengapa → Akibatnya → Di layar: Keluar sebentar dari game untuk membaca pesan atau menerima telepon → Engine game menghentikan jalannya game, dan OS pun segera menghentikan aplikasi dan jaringannya → Saat kembali, sudah disconnect dan harus reconnect - Gejala: Disconnect / Faktor: Stall, Packet loss - Siapa: Hanya saya / Kapan: Setelah lama diam, Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: saat kembali, jangan menunggu koneksi yang sudah putus, langsung reconnect otomatis dengan token sesi (melanjutkan sesi tanpa login ulang), terima state terbaru sekaligus untuk menyamakan. Server: jika heartbeat terputus, bersihkan koneksinya tetapi pertahankan sesi karakter selama masa tenggang singkat (jangan langsung dikeluarkan), lanjutkan sesi dengan token sesi jika pemain reconnect dalam waktu itu. - Kisaran angka: Engine game biasanya berhenti begitu aplikasi keluar dari layar. iOS menangguhkan aplikasi dalam beberapa detik, atau umumnya dalam puluhan detik jika mendapat waktu tambahan; Android 14 ke atas membekukan (freeze) aplikasi yang keluar dari layar sekitar 10 detik kemudian. - Di grafik: Koneksi putus serentak (Jumlah disconnect (timeout heartbeat), catatan aplikasi ditangguhkan) - Yang diperiksa: Cocokkan waktu aplikasi ditangguhkan dan kembali di log klien (OnApplicationPause di Unity) dengan alasan dan waktu disconnect di server lewat ID sesi. Di Android, periksa juga alasan penutupan proses yang tercatat di ApplicationExitInfo (REASON_LOW_MEMORY dan sebagainya) - Cocok jika: Klien masuk ke status ditangguhkan tepat sebelum server mencatat disconnect karena timeout heartbeat, lalu reconnect tepat setelah kembali - Tidak cocok jika: Terputus saat aplikasi tetap tampil di depan: lebih mungkin “Mapping NAT kedaluwarsa”, “IP bersama dari ISP (CGNAT)”, atau “Perpindahan Wi-Fi ↔ LTE/5G” - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Jika memori kurang, ponsel kadang menutup sepenuhnya game yang sedang di latar belakang. Inilah alasan game mulai lagi dari awal setelah Anda membuka kamera atau aplikasi pembayaran dan autentikasi. Makin rendah spesifikasi perangkat, makin sering terjadi. - Sumber: - [Extending your app’s background execution time](https://developer.apple.com/documentation/uikit/extending-your-app-s-background-execution-time) · Apple · Saat masuk ke latar belakang, applicationDidEnterBackground diberi waktu 5 detik lalu aplikasi segera ditangguhkan; jika butuh lebih, minta waktu dengan beginBackgroundTask (sisa waktunya di backgroundTimeRemaining) - [Cached apps freezer](https://source.android.com/docs/core/perf/cached-apps-freezer) · Android (Google) · Android 14 ke atas membekukan proses aplikasi yang sudah berstatus cached setelah 10 detik; saat dibekukan, semua thread berhenti - [Application.runInBackground](https://docs.unity3d.com/ScriptReference/Application-runInBackground.html) · Unity · Default false sehingga game berhenti di latar belakang; Android selalu berhenti di latar belakang apa pun pengaturannya, dan iOS mengabaikan pengaturan ini - [MonoBehaviour.OnApplicationPause(bool)](https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnApplicationPause.html) · Unity · Saat aplikasi ditangguhkan atau berjalan lagi, OnApplicationPause(true/false) dikirim ke semua MonoBehaviour - [ApplicationExitInfo](https://developer.android.com/reference/android/app/ApplicationExitInfo) · Android (Google) · REASON_LOW_MEMORY: low memory killer sistem menutup proses aplikasi (perangkat yang tidak mendukungnya melaporkannya sebagai REASON_SIGNALED dengan SIGKILL) #### co-netswitch · Perpindahan Wi-Fi ↔ LTE/5G · Network switch changes IP Saat Anda keluar rumah, Wi-Fi terputus dan beralih ke LTE/5G sehingga alamat IP Anda berubah dan koneksi yang ada menjadi tidak berlaku. - Mengapa → Akibatnya → Di layar: Sinyal Wi-Fi melemah sehingga beralih ke jaringan seluler → Alamat IP Anda berubah sehingga koneksi yang dibuat dengan alamat lama tidak bisa dipakai lagi → Berhenti sejenak, lalu disconnect atau reconnect - Gejala: Freeze, Disconnect / Faktor: Packet loss - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Server: sambungkan kembali sebagai pemain yang sama dengan token sesi walaupun alamatnya berubah dan langsung bersihkan koneksi di alamat lama, pertimbangkan protokol yang tetap tersambung walau alamat berubah (connection migration pada QUIC dan sebagainya). Klien: begitu mendeteksi perpindahan jaringan, langsung reconnect dengan token sesi tanpa menunggu timeout heartbeat. - Tugas Tim Infrastruktur: Jika memakai connection migration QUIC, atur load balancer agar memilih server berdasarkan connection ID (jika memilih berdasarkan alamat dan port, paket yang alamatnya berubah dikirim ke server lain). - Di grafik: Koneksi putus serentak (Jumlah disconnect dan reconnect, IP yang berubah saat reconnect) - Yang diperiksa: Cari catatan di log koneksi server saat token sesi yang sama reconnect dari IP lain, lalu cocokkan dengan waktu callback perubahan jaringan default di klien (registerDefaultNetworkCallback) - Cocok jika: IP yang dipakai untuk reconnect tepat setelah terputus berpindah dari rentang Wi-Fi (koneksi rumah) ke rentang operator seluler, atau sebaliknya, dan tepat sebelumnya ada callback perpindahan jaringan - Tidak cocok jika: IP tetap sama, tetapi koneksi terputus: lebih mungkin “Handover antar-BTS (saat bergerak)” atau “Sinyal seluler lemah dan area blank spot” - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Read network state](https://developer.android.com/training/basics/network-ops/reading-network-state) · Android (Google) · Saat jaringan default berubah, koneksi baru lewat jaringan baru dan koneksi di jaringan lama akhirnya diputus paksa; perpindahan dideteksi dengan registerDefaultNetworkCallback - [RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport](https://www.rfc-editor.org/rfc/rfc9000) · IETF · Dengan connection ID, koneksi tetap bertahan walau alamat IP dan port berubah (bab 9); load balancer yang membagi beban hanya berdasarkan alamat dan port bisa mengirim paket yang alamatnya berubah ke server lain (subbab 5.2.3) - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Koneksi TCP diidentifikasi oleh pasangan socket (alamat dan port) di kedua ujung #### co-security · Pemeriksaan paket oleh program keamanan · Antivirus / firewall inspection Jika antivirus atau firewall memeriksa semua paket, latensi bertambah, dan jika berlebihan, game salah dikira serangan lalu diblokir. - Mengapa → Akibatnya → Di layar: Program keamanan memeriksa satu per satu setiap paket yang dikirim dan diterima → Setiap paket mendapat tambahan latensi, dan jika pemeriksaan tertinggal, paket dibuang → Ping melonjak tidak beraturan atau koneksi diblokir - Gejala: Patah-patah, Tidak bisa masuk / loading tanpa henti / Faktor: Jitter, Packet loss - Siapa: Hanya saya / Kapan: Selalu, Tepat setelah login atau maintenance - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kelola daftar kompatibilitas program keamanan, daftarkan pengecualian game di Windows Firewall saat instalasi. - Tugas Pihak Eksternal: Imbau pemain untuk mendaftarkan game sebagai pengecualian di program keamanan, minta vendor program keamanan memperbaiki false positive jika game salah dikira serangan. - Kisaran angka: Dalam kondisi normal, waktu pemeriksaan paket biasanya kurang dari 1 ms. Masalah muncul saat modul pemeriksa tertinggal atau punya bug, dan saat komunikasi game salah dikira serangan. - Di grafik: Hanya sebagian yang tinggi (RTT dan kegagalan koneksi (per pemain)) - Yang diperiksa: Bandingkan setelah program keamanan dimatikan sebentar atau game didaftarkan sebagai pengecualian. Di Windows, aktifkan Audit Filtering Platform Connection dan Audit Filtering Platform Packet Drop di kebijakan audit agar 5157 (koneksi diblokir) dan 5152 (paket diblokir) tercatat di log Security, lalu lihat jumlah paket yang dibuang di WFPv4\Packets Discarded/sec pada Performance Monitor - Cocok jika: Ada catatan pemblokiran koneksi atau paket ke alamat server game, atau ping spike dan gejala tidak bisa masuk hilang saat program keamanan dimatikan - Tidak cocok jika: Perangkat lain di rumah yang sama juga mengalami hal yang sama tanpa kaitan dengan program keamanan: mengarah ke router atau koneksi - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [About Windows Filtering Platform](https://learn.microsoft.com/en-us/windows/win32/fwp/about-windows-filtering-platform) · Microsoft · Arsitektur yang mengizinkan atau memblokir paket lewat hook dan filter engine di network stack Windows; vendor keamanan pihak ketiga bisa menyisipkan modul filternya sendiri (callout) - [Windows Firewall Rules](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules) · Microsoft · Secara default koneksi masuk diblokir sehingga aplikasi perlu aturan pengecualian, yang umumnya dibuat oleh installer aplikasi - [Address false positives/negatives in Microsoft Defender for Endpoint](https://learn.microsoft.com/en-us/defender-endpoint/defender-endpoint-false-positives-negatives) · Microsoft · Prosedur pengecualian dan pengiriman file ke Microsoft untuk dianalisis saat program normal salah dikira ancaman (false positive) - [5157(F): The Windows Filtering Platform has blocked a connection.](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-5157) · Microsoft · Event 5157: Windows Filtering Platform memblokir koneksi (Audit Filtering Platform Connection) - [Audit Filtering Platform Packet Drop](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-filtering-platform-packet-drop) · Microsoft · Event 5152: Windows Filtering Platform memblokir paket - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · Counter WFPv4 dan WFPv6: Packets Discarded/sec #### co-rcvbuf · Buffer terima meluap · Socket receive buffer overflow Jika game terlalu sibuk sehingga terlambat mengambil paket dari socket (antarmuka kirim-terima jaringan yang disediakan OS), buffer OS meluap. - Mengapa → Akibatnya → Di layar: Frame tertunda sehingga game terlambat membaca socket → Buffer terima OS penuh: UDP membuang paket, TCP mengecilkan receive window sehingga pengirim berhenti mengirim → Teleport (UDP) atau fast forward (TCP) - Gejala: Teleport, Fast forward / Faktor: Packet loss, Stall - Siapa: Hanya saya / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Gunakan thread khusus untuk menerima paket, sesuaikan ukuran buffer (SO_RCVBUF). - Kisaran angka: Buffer terima default berukuran puluhan hingga ratusan KB, tergantung OS dan pengaturan. Update di tempat ramai bisa mencapai ratusan KB per detik. - Di grafik: Naik mengikuti beban (Jumlah paket UDP yang dibuang di buffer terima, frame time) - Yang diperiksa: Rekam Microsoft Winsock BSP\Dropped Datagrams (jumlah paket UDP yang dibuang karena buffer terima socket tidak cukup) dan UDPv4\Datagrams Received Errors di Performance Monitor Windows bersama frame time, dan di game hitung celah pada nomor urut paket yang diterima - Cocok jika: Dropped Datagrams naik di tempat ramai atau tepat setelah frame panjang, dan pada saat yang sama muncul celah di nomor urut game. Pada waktu itu tidak ada packet loss di sisi koneksi - Tidak cocok jika: Dropped Datagrams tidak berubah, tetapi ada nomor urut yang hilang: packet loss di sepanjang rute - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · SO_RCVBUF adalah ukuran maksimum buffer terima socket; nilai default ditentukan rmem_default dan nilai maksimum oleh rmem_max (Android juga memakai kernel Linux) - [SOL_SOCKET Socket Options (Winsock2.h)](https://learn.microsoft.com/en-us/windows/win32/winsock/sol-socket-socket-options) · Microsoft · SO_RCVBUF di Windows: ruang buffer yang disediakan untuk menerima data di setiap socket - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Field window TCP adalah jumlah byte yang masih bisa diterima penerima; jika 0, pengirim hanya mengirim zero window probe sambil menunggu - [Low Latency Workloads Management and Operations](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh997022(v=ws.11)) · Microsoft · Dropped Datagrams dan Dropped Datagrams/sec di counter set Microsoft Winsock BSP: jumlah paket yang dibuang karena UDP datang lebih cepat dari kecepatan pemrosesan aplikasi atau buffer terima socket tidak cukup - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · Counter UDPv4 dan UDPv6: Datagrams Received Errors, Microsoft Winsock BSP: Dropped Datagrams #### co-swap · Kekurangan memori dan swap di klien · Paging / swap on client Jika puluhan tab browser dan game menyala bersamaan, OS memindahkan sebagian memori game ke disk. - Mengapa → Akibatnya → Di layar: RAM total tidak cukup → OS memindahkan memori game yang tidak sedang dipakai ke disk → Saat bagian itu dipakai lagi, game berhenti puluhan hingga ratusan ms, tergantung storage - Gejala: Freeze, Patah-patah / Faktor: Stall - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area, Sesekali secara acak - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kurangi pemakaian memori, tampilkan peringatan jika sisa memori sedikit. - Tugas Pihak Eksternal: Sampaikan spesifikasi minimum kepada pemain, imbau pemain untuk menutup program lain (tab browser dan sebagainya) selama bermain. - Di grafik: Melonjak acak sesekali (Hard page fault, pemakaian memori) - Yang diperiksa: Rekam Memory\Pages Input/sec (jumlah halaman yang dibaca dari disk untuk menyelesaikan hard page fault) di Performance Monitor serta pemakaian memori dan commit di tab Performance pada Task Manager bersama frame time - Cocok jika: Pages Input/sec melonjak saat game berhenti dan memori hampir penuh. Hilang jika browser dan program lain ditutup - Tidak cocok jika: Memori masih longgar dan Pages Input/sec tenang: lebih mungkin “Pemuatan sinkron dan kompilasi shader di main thread” atau “Streaming aset tertinggal akibat storage lambat” - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Introduction to the page file](https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/introduction-to-the-page-file) · Microsoft · Page file adalah file di disk yang dipakai untuk mengeluarkan halaman memori termodifikasi yang jarang dipakai dari RAM - [Working Set](https://learn.microsoft.com/en-us/windows/win32/memory/working-set) · Microsoft · Mengakses halaman yang tidak ada di RAM menimbulkan page fault; hard fault baru selesai setelah halaman dibaca dari disk, misalnya dari page file - [Chapter 12 - Detecting Memory Bottlenecks](https://learn.microsoft.com/en-us/previous-versions/cc749872(v=technet.10)) · Microsoft · Memory\Pages Input/sec: jumlah halaman yang dibaca dari disk untuk menyelesaikan page fault (hard page fault) #### co-vram · Kekurangan memori grafis (VRAM) · VRAM over-commit Jika memori yang dibutuhkan opsi grafis lebih besar dari memori kartu grafis, OS memindahkan tekstur ke memori PC lalu mengambilnya kembali sehingga game patah-patah. - Mengapa → Akibatnya → Di layar: Opsi tekstur tinggi serta beragam equipment dan efek di tempat ramai membuat memori kartu grafis penuh → OS memindahkan tekstur yang tidak sedang dipakai ke memori PC, lalu mengambilnya kembali lewat bus PCIe yang lambat saat dibutuhkan → Tersendat sesaat setiap kali adegan atau karakter baru terlihat, tekstur buram untuk sementara - Gejala: Patah-patah, Freeze / Faktor: Stall - Siapa: Hanya saya / Kapan: Saat banyak pemain berkumpul, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Sesuaikan nilai default opsi dengan ukuran memori kartu grafis, turunkan kualitas tekstur otomatis jika melewati budget memori, sederhanakan tekstur karakter di tempat ramai. - Tugas Pihak Eksternal: Imbau pemain untuk menurunkan opsi tekstur, dan menurunkannya lagi jika menjalankan dua klien. - Kisaran angka: Memori kartu grafis membaca ratusan GB per detik, tetapi bus PCIe antara GPU dan memori PC sekitar 16–64 GB per detik tergantung generasinya, lebih dari sepuluh kali lebih lambat. - Di grafik: Mendatar di batas (Memori GPU khusus, memori GPU bersama) - Yang diperiksa: Periksa grafik memori GPU khusus dan memori GPU bersama di bagian GPU pada tab Performance Task Manager (kolom per proses juga bisa ditambahkan di tab Details) bersama frame time PresentMon - Cocok jika: Selama memori GPU khusus mendatar di batasnya dan memori GPU bersama bertambah, game sering tersendat, dan gejalanya hilang jika opsi tekstur diturunkan - Tidak cocok jika: Memori khusus masih longgar: lebih mungkin “Streaming aset tertinggal akibat storage lambat” atau “Pemuatan sinkron dan kompilasi shader di main thread” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Jika memori GPU khusus (Dedicated GPU memory) di bagian GPU pada Task Manager Windows penuh dan memori GPU bersama (Shared GPU memory) bertambah, inilah kondisinya. Jika dua klien dijalankan di PC yang sama, memori lebih cepat penuh (entri “Streaming gagal akibat kekurangan memori atau VRAM”). - Sumber: - [Residency](https://learn.microsoft.com/en-us/windows/win32/direct3d12/residency) · Microsoft · Setiap proses punya budget memori grafis yang bisa dipakai; jika terlampaui, kernel memindahkan sebagian heap GPU diskrit ke memori PC (ini upaya terakhir, jadi disarankan mengelola budget) - [GPUs in the task manager](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/) · Microsoft · Memori GPU khusus di Task Manager adalah VRAM kartu grafis, memori GPU bersama adalah memori PC yang dipakai bersama oleh GPU dan CPU - [CUDA C++ Best Practices Guide](https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html) · NVIDIA · Bandwidth memori grafis (V100 898 GB/s) jauh lebih besar daripada PCIe x16 generasi 3 (16 GB/s), sehingga disarankan mengurangi transfer bolak-balik dengan memori PC - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame) #### co-wifi-scan · Pemindaian Wi-Fi di latar belakang · Periodic Wi-Fi background scan Selama OS berpindah-pindah channel secara berkala untuk mencari Wi-Fi di sekitar, komunikasi berhenti sejenak. - Mengapa → Akibatnya → Di layar: OS atau driver mencari Wi-Fi di sekitar secara berkala → Kirim-terima berhenti sejenak selama pencarian → Ping melonjak dengan interval yang sangat teratur (misalnya setiap 60 detik) - Gejala: Patah-patah, Teleport / Faktor: Jitter - Siapa: Hanya saya / Kapan: Secara berkala - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Minta mode yang mengurangi pemindaian nirkabel selama bermain (di Android, mode Wi-Fi latensi rendah WIFI_MODE_FULL_LOW_LATENCY; di Windows, mode media streaming lewat WlanSetInterface; tergantung perangkat dan driver, kadang tidak berpengaruh). - Tugas Pihak Eksternal: Imbau pemain untuk memakai koneksi kabel, menyesuaikan pengaturan layanan lokasi dan pencarian Wi-Fi otomatis, serta memperbarui driver nirkabel. - Kisaran angka: Biasanya puluhan hingga ratusan ms sekali jalan. Jika polanya terlalu teratur, curigai penyebab ini lebih dulu. - Di grafik: Melonjak secara berkala (RTT ke router) - Yang diperiksa: Selama bermain, ukur ping ke alamat router (default gateway di ipconfig) dengan ping /t selama beberapa menit dan catat interval lonjakannya. Ulangi pengukuran yang sama dengan koneksi kabel - Cocok jika: Ping ke router melonjak puluhan hingga ratusan ms dengan interval yang sangat teratur (misalnya 60 detik), dan hilang saat memakai kabel - Tidak cocok jika: Interval lonjakan tidak beraturan: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah”. Ping ke router normal dan hanya bagian sesudahnya yang melonjak: mengarah ke koneksi atau jaringan ISP - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [WDI low latency connection quality](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/wdi-low-latency-connection-quality) · Microsoft · Pemindaian dan roaming memindahkan chip nirkabel keluar dari channel yang tersambung, sehingga mode latensi rendah membatasi waktu di luar channel dan pemindaian - [WlanSetInterface function (wlanapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/wlanapi/nf-wlanapi-wlansetinterface) · Microsoft · API Windows untuk menyalakan dan mematikan pemindaian latar belakang (wlan_intf_opcode_background_scan_enabled) dan mode media streaming - [Wi-Fi low-latency mode](https://source.android.com/docs/core/connect/wifi-low-latency) · Android (Google) · Mode latensi rendah mematikan hemat daya Wi-Fi, sedangkan optimasi pemindaian dan roaming bergantung pada implementasi produsen perangkat - [ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) · Microsoft · /t: terus mengirim echo request sampai dihentikan - [ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) · Microsoft · Jika dijalankan tanpa parameter, menampilkan alamat IPv4 dan IPv6 serta default gateway setiap adapter #### co-driver · Mode hemat daya NIC dan masalah driver · NIC power saving, driver bugs Jika kartu LAN atau chip Wi-Fi masuk ke mode hemat daya di antara paket, butuh waktu untuk aktif kembali. - Mengapa → Akibatnya → Di layar: Fitur hemat daya perangkat jaringan aktif atau driver sudah usang → Jeda saat bangun (wake-up), sesekali perangkat dimulai ulang → Latensi tidak beraturan, dalam kasus yang jarang berhenti beberapa detik - Gejala: Patah-patah, Freeze / Faktor: Jitter, Packet loss - Siapa: Hanya saya / Kapan: Setelah lama diam, Sesekali secara acak - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien Android meminta mode Wi-Fi latensi rendah (WIFI_MODE_FULL_LOW_LATENCY) selama bermain untuk mematikan hemat daya Wi-Fi. - Tugas Pihak Eksternal: Imbau pemain untuk memperbarui driver jaringan dan mematikan hemat daya perangkat jaringan di Device Manager, minta pemain mencari driver penyebabnya dengan LatencyMon jika seluruh layar tersendat dan suara berderak. - Di grafik: Melonjak acak sesekali (Waktu DPC dan ISR, RTT ke router) - Yang diperiksa: Rekam dengan Windows Performance Recorder (WPR), cari driver yang berjalan lama (kolom Module) di grafik DPC/ISR pada Windows Performance Analyzer (WPA), lalu periksa pengaturan manajemen daya (hemat daya) adapter jaringan di Device Manager - Cocok jika: Pada waktu tersendat, DPC dan ISR driver jaringan berjalan beberapa ms beruntun, atau latensi tidak beraturan hilang setelah hemat daya dimatikan - Tidak cocok jika: DPC singkat dan tetap sama walau hemat daya dimatikan: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah” atau “Pemindaian Wi-Fi di latar belakang” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Jika driver memakai CPU lama untuk menangani interrupt (di Windows disebut latensi DPC), selama itu thread game juga tidak bisa memakai core tersebut. Dalam kondisi ini, seluruh layar tersendat dan suara berderak walaupun pemakaian CPU rendah. Driver penyebabnya bisa dicari dengan tools seperti LatencyMon, dan driver Wi-Fi atau LAN adalah penyebab yang umum. - Sumber: - [Introduction to NDIS Selective Suspend](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/ndis-selective-suspend) · Microsoft · Windows bisa memasukkan adapter jaringan yang sedang tidak dipakai ke status daya rendah (selective suspend) - [Guidelines for Writing DPC Routines](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/guidelines-for-writing-dpc-routines) · Microsoft · Selama DPC berjalan, semua thread di core itu berhenti, sehingga disarankan agar satu DPC tidak melebihi 100 µs - [Wi-Fi low-latency mode](https://source.android.com/docs/core/connect/wifi-low-latency) · Android (Google) · Mode Wi-Fi latensi rendah Android membuat framework mematikan hemat daya Wi-Fi secara eksplisit - [CPU Analysis](https://learn.microsoft.com/en-us/windows-hardware/test/wpt/cpu-analysis) · Microsoft · Grafik DPC/ISR di WPA: waktu setiap bagian saat DPC dan ISR berjalan tanpa jeda, serta modul (Module) tempat fungsinya berada #### co-other-apps · Pemakaian bandwidth oleh aplikasi lain di perangkat yang sama · Other apps saturating the link Jika sinkronisasi cloud, unduhan besar, atau patch game berjalan di PC yang sama, paket game harus menunggu di antrean. - Mengapa → Akibatnya → Di layar: Aplikasi lain memakai upload dan download secara maksimal → Paket game menumpuk di antrean PC dan router → Ping melonjak drastis, input lag, fast forward - Gejala: Input lag, Fast forward / Faktor: Latensi, Jitter - Siapa: Hanya saya, Satu rumah / Kapan: Sesekali secara acak - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Hentikan atau batasi kecepatan unduhan latar belakang di launcher dan patcher kami selama game berjalan. - Tugas Pihak Eksternal: Imbau pemain untuk membatasi kecepatan unduhan dan mematikan update otomatis selama bermain. - Di grafik: Naik mengikuti beban (RTT, volume kirim-terima PC) - Yang diperiksa: Rekam Network Interface\Bytes Sent/sec dan Bytes Received/sec di Performance Monitor bersama ping. Caranya sama dengan tes bufferbloat, yaitu sengaja menjalankan transfer besar sambil ping tetap berjalan - Cocok jika: Selama download atau upload mendekati kecepatan koneksi, ping naik puluhan hingga ratusan ms, dan langsung kembali normal saat transfer dihentikan - Tidak cocok jika: Volume kirim-terima PC rendah, tetapi ping naik: lebih mungkin “Bufferbloat (antrean router)” akibat perangkat lain di rumah yang sama, atau jaringan ISP - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Introduction](https://www.bufferbloat.net/projects/bloat/wiki/Introduction/) · Bufferbloat.net · Jika perangkat jaringan seperti router menumpuk terlalu banyak data, latensi melonjak tajam (bufferbloat) - [Delivery Optimization reference](https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization-reference) · Microsoft · Unduhan Windows Update (Delivery Optimization) secara default menyesuaikan diri secara dinamis dengan bandwidth yang tersedia, dan batas bandwidth unduhan latar belakang dan latar depan bisa diatur - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · Counter Network Interface: Bytes Received/sec dan Bytes Sent/sec - [Tests for Bufferbloat](https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/) · Bufferbloat.net · Jika ping naik saat koneksi dipenuhi oleh tes kecepatan sementara ping tetap berjalan, berarti terjadi bufferbloat #### co-unfocused · Pemrosesan dibatasi saat jendela diminimalkan atau tidak aktif · Minimized / unfocused window throttling Saat Anda melihat jendela lain atau meminimalkan game, game dan Windows menjalankan game lebih lambat untuk menghemat daya. Saat kembali, paket yang tertunda datang sekaligus, atau koneksi sudah terputus. - Mengapa → Akibatnya → Di layar: Beralih ke jendela lain dengan Alt+Tab atau meminimalkan game → Selama game tidak terlihat, FPS diturunkan drastis atau game dihentikan, dan Windows juga menurunkan prioritas program yang tidak terlihat → Fast forward saat kembali; jika lama diminimalkan, disconnect - Gejala: Fast forward, Patah-patah, Disconnect / Faktor: Stall - Siapa: Hanya saya / Kapan: Saat melakukan aksi tertentu, Setelah lama diam - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Lanjutkan penerimaan paket dan heartbeat di thread terpisah walau jendela tidak terlihat, periksa pengaturan “Run In Background” di engine, samakan ke state terbaru sekaligus saat kembali. - Kisaran angka: Jika FPS diturunkan ke 5–10 saat jendela tidak terlihat, satu frame menjadi 100–200 ms. Game yang memproses paket per frame juga membaca paket selambat itu. - Di grafik: Kosong lalu datang sekaligus (Interval frame (sebelum dan sesudah berpindah jendela), jumlah paket yang diproses) - Yang diperiksa: Coba Alt+Tab dan minimalkan game sambil PresentMon berjalan, lalu periksa interval frame saat jendela tidak terlihat. Catat waktu perubahan fokus jendela di log game dan cocokkan dengan alasan disconnect - Cocok jika: Selama jendela tidak terlihat, interval frame memanjang menjadi 100 ms atau lebih atau rekamannya terputus, lalu saat kembali paket yang tertunda diproses sekaligus sehingga terjadi fast forward. Jika lama diminimalkan, koneksi putus karena timeout heartbeat - Tidak cocok jika: Tetap sama walau jendela tetap ditampilkan: lebih mungkin “Pemakaian CPU oleh proses di latar belakang” atau sisi jaringan - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Windows 11 tidak menjamin timer 1 ms untuk program dengan jendela yang diminimalkan atau tertutup sepenuhnya dan tidak mengeluarkan suara. Di laptop yang berjalan dengan baterai, program seperti itu diturunkan ke kecepatan paling hemat daya, dan pada CPU dengan campuran jenis core, program tersebut bisa dijalankan di efficiency core yang lambat. Jika dari dua klien di PC yang sama hanya yang di latar belakang yang bermasalah, lihat juga entri “Pemrosesan dibatasi di jendela latar belakang”. - Sumber: - [Quality of Service](https://learn.microsoft.com/en-us/windows/win32/procthread/quality-of-service) · Microsoft · Program dengan jendela yang tidak terlihat dan tidak terdengar dijadwalkan sebagai Low QoS, dengan kecepatan CPU paling efisien dan efficiency core saat memakai baterai - [timeBeginPeriod function (timeapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod) · Microsoft · Windows 11 tidak menjamin resolusi timer yang lebih tinggi dari default untuk proses dengan jendela yang tertutup atau diminimalkan - [Application.runInBackground](https://docs.unity3d.com/ScriptReference/Application-runInBackground.html) · Unity · Default Unity adalah false sehingga game loop berhenti saat jendela masuk ke latar belakang - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · MsBetweenPresents: waktu (ms) antara pemanggilan Present() saat ini dan pemanggilan sebelumnya #### co-overlay · Interferensi program overlay · Overlays and screen hooks Program messenger, launcher, perekam, dan penampil FPS menyusup ke proses rendering game (hooking) untuk menggambar UI mereka di atas layar game. Pekerjaan setiap frame bertambah, dan sesekali program itu bentrok dengan game sehingga game tersendat sesaat atau tertutup paksa. - Mengapa → Akibatnya → Di layar: Overlay dari messenger, launcher game, tools kartu grafis, atau program perekam aktif → Setiap kali frame dikirim ke layar, overlay menyela untuk menggambar UI-nya → Frame sedikit demi sedikit terlambat, dan saat notifikasi muncul game tersendat sesaat, mengalami error grafis, atau tertutup paksa (bagi pemain terlihat seperti disconnect) - Gejala: Patah-patah, Freeze, Disconnect / Faktor: Stall - Siapa: Hanya saya / Kapan: Selalu, Sesekali secara acak - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kumpulkan daftar overlay yang sedang berjalan bersama laporan crash dan log patah-patah. - Tugas Pihak Eksternal: Jika ada laporan, imbau pemain untuk mematikan semua overlay lalu mencoba lagi. - Di grafik: Hanya sebagian yang tinggi (Frame time dan jumlah crash (pemain yang menyalakan overlay)) - Yang diperiksa: Matikan semua overlay lalu bandingkan frame time PresentMon pada adegan yang sama; jika ada crash, periksa nama modul yang error (Faulting module name) pada event ID 1000 di Event Viewer - Cocok jika: Game tidak lagi tersendat dan error grafis hilang saat overlay dimatikan, atau modul yang error pada crash adalah DLL program overlay - Tidak cocok jika: Tetap sama walau semua overlay dimatikan: mengarah ke driver grafis atau “Crash di klien” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Jika hanya pemain tertentu yang mengalami patah-patah atau game tertutup dan spesifikasinya tidak bisa menjelaskan hal itu, curigai lebih dulu bentrokan antara overlay dan modul keamanan game. - Sumber: - [Steam Overlay (Steamworks Documentation)](https://partner.steamgames.com/doc/features/overlay) · Valve · Steam Overlay otomatis melakukan hook ke game yang dijalankan lewat Steam, dan cara kerja itu bisa memunculkan error memori dalam pemakaian API rendering oleh game sehingga terjadi crash - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · Merekam waktu per frame dengan FrameTime (waktu CPU di antara frame) - [The application or service crashing behavior troubleshooting guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/troubleshoot-application-service-crashing-behavior) · Microsoft · Event ID 1000 di log Application berisi nama modul yang error (Faulting module name), dan kadang modul Windows tercatat sebagai modul yang error karena kerusakan yang ditimbulkan modul lain #### co-display-input · Latensi layar, perangkat input, dan frame generation · Display, input device and frame generation latency Jika ping normal tetapi kontrol terasa berat, pemrosesan gambar di TV, controller nirkabel, atau fitur frame generation mungkin menambah latensi antara input dan layar. - Mengapa → Akibatnya → Di layar: Mode game TV mati, memakai controller Bluetooth atau nirkabel, atau frame generation (frame generation DLSS/FSR) aktif → TV mengeluarkan frame lebih lambat selama memproses kualitas gambar, input nirkabel tiba terlambat sebesar siklus pengiriman dan interferensi, dan frame generation menunggu frame berikutnya untuk membuat frame sisipan → Angka ping dan FPS bagus, tetapi ada jeda antara tombol ditekan dan hasilnya tampil di layar: input lag - Gejala: Input lag / Faktor: Latensi - Siapa: Hanya saya / Kapan: Selalu - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Jadikan frame generation sebagai opsi pilihan dan informasikan bahwa input lag bisa bertambah jika diaktifkan, integrasikan fitur latensi rendah dari produsen grafis (NVIDIA Reflex, AMD Anti-Lag 2) saat memakai frame generation, tampilkan latensi input hingga layar di sisi PC di dalam game, minta mode latensi rendah (ALLM) ke TV dengan Window.setPreferMinimalPostProcessing(true) pada build Android TV dan set-top box. - Tugas Pihak Eksternal: Imbau pemain untuk mengaktifkan mode game (ALLM) di TV atau monitor, memakai controller kabel dan mematikan frame generation untuk konten kompetitif, serta menaruh perangkat Bluetooth di dekatnya dan memakai Wi-Fi 5 GHz. - Kisaran angka: Layar 60 Hz butuh 16,7 ms hanya untuk mengirim satu frame, dan layar 120 Hz butuh 8,3 ms. Controller Xbox lama membaca dan mengirim input setiap 8 ms. Latensi tambahan dari pemrosesan gambar TV berbeda per perangkat sehingga sulit dinyatakan dengan satu angka, dan mode game adalah pengaturan untuk mengurangi pemrosesan ini. AMD menyarankan frame generation dipakai pada frame rate minimal 60 FPS sebelum frame dibuat. - Di grafik: Selalu tinggi sejak awal (Latensi dari input hingga layar) - Yang diperiksa: Bandingkan MsAllInputToPhotonLatency (dari input keyboard dan mouse sampai dikirim ke layar) di PresentMon dengan frame generation dinyalakan dan dimatikan, lalu periksa dengan FrameType (hanya tercatat jika driver atau SDK melaporkannya) apakah ada frame sisipan hasil generate. Nilai ini tidak mencakup jalur nirkabel controller dan pemrosesan di dalam TV, jadi bagian itu dibandingkan dengan beralih ke mode game TV dan controller kabel - Cocok jika: Ping normal, tetapi latensi input hingga layar berkurang saat frame generation dimatikan, atau latensi yang terasa hilang setelah beralih ke mode game TV atau controller kabel - Tidak cocok jika: Tetap sama setelah semua pengaturan ini diubah, dan ping tinggi atau melonjak: mengarah ke sisi jaringan. Latensi sisi PC tinggi karena V-Sync atau antrean frame: lebih mungkin “V-Sync dan antrean render” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Latensi jaringan terlihat di ping, tetapi latensi ini tidak tertangkap oleh ping. Karena itu, inilah tempat pertama yang diperiksa untuk laporan “ping rendah tapi tetap lag”. Frame generation menaikkan angka FPS di layar sekitar dua kali lipat, tetapi untuk membuat frame sisipan, game harus menunggu frame asli berikutnya sehingga waktu sampai input tampil di layar bertambah (AMD menyatakan latensinya memang bertambah menurut desainnya). Perangkat Bluetooth memakai pita 2,4 GHz yang sama dengan Wi-Fi, sehingga input bisa terputus atau melompat saat terkena interferensi. Untuk V-Sync dan antrean render yang menambah latensi di dalam PC, lihat entri “V-Sync dan antrean render”. - Sumber: - [Auto Low Latency Mode (ALLM)](https://www.hdmi.org/spec21sub/autolowlatencymode) · HDMI Licensing Administrator · ALLM membuat perangkat mengalihkan layar ke mode latensi rendah (biasanya mode game) secara otomatis; dalam mode latensi rendah, sebagian pemrosesan gambar TV dihentikan untuk mengurangi latensi - [Xbox Series X: What’s the Deal with Latency?](https://news.xbox.com/en-us/2020/03/16/xbox-series-x-latency/) · Microsoft · Input lag adalah jumlah dari jalur controller→konsol→HDMI→TV; controller lama membaca dan mengirim input setiap 8 ms; waktu mengirim satu frame lewat HDMI 16,6 ms pada 60 Hz dan 8,3 ms pada 120 Hz; ALLM mengalihkan TV ke mode game secara otomatis - [AMD FSR 3 game integrations out now + more details for developers](https://gpuopen.com/news/fsr3-in-games-technical-details/) · AMD · Interpolasi frame menambah latensi menurut desainnya; disarankan dipakai pada frame rate minimal 60 sebelum interpolasi; input 60 FPS menghasilkan output hingga 120 FPS - [AMD FSR Frame Generation](https://gpuopen.com/amd-fsr-framegeneration/) · AMD · Frame generation disarankan pada minimal 60 FPS sebelum interpolasi (di bawah 30 FPS harus dihindari); AMD Radeon Anti-Lag 2 menyelaraskan kerja CPU dan GPU untuk mengurangi latensi sistem - [NVIDIA DLSS](https://developer.nvidia.com/rtx/dlss) · NVIDIA · DLSS Frame Generation dirancang untuk menjaga responsivitas bersama NVIDIA Reflex (fitur latensi rendah) - [Resolve Wi-Fi and Bluetooth issues caused by wireless interference](https://support.apple.com/en-us/102319) · Apple · Interferensi nirkabel menyebabkan koneksi putus dan penurunan performa pada perangkat Wi-Fi dan Bluetooth; Bluetooth dan Wi-Fi memakai pita 2,4 GHz yang sama - [PresentMon Capture Application (README-CaptureApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-CaptureApplication.md) · Intel · MsAllInputToPhotonLatency (latensi input hingga layar), DisplayLatency (frame diserahkan hingga dikirim ke monitor), FrameType (membedakan frame yang digambar aplikasi dan frame hasil interpolasi driver atau SDK) - [PresentMon Console Application (README-ConsoleApplication.md)](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README-ConsoleApplication.md) · Intel · MsAllInputToPhotonLatency diukur dari input keyboard dan mouse, FrameType hanya tercatat jika aplikasi atau driver mengirim event Intel-PresentMon (--track_frame_type) - [Window.setPreferMinimalPostProcessing](https://developer.android.com/reference/android/view/Window#setPreferMinimalPostProcessing(boolean)) · Android (Google) · Jendela yang sensitif terhadap latensi seperti game meminta pemrosesan gambar minimum pada layar; pada koneksi HDMI, sinyal ALLM dan Game Content Type dikirim untuk mengalihkan TV ke mode latensi rendah ### L3 Jaringan rumah (10 penyebab) #### hn-wifi · Interferensi Wi-Fi dan sinyal lemah · Wi-Fi interference, weak signal Jika sinyal lemah atau ada interferensi, paket dikirim ulang beberapa kali di jalur nirkabel sehingga waktu kedatangannya tidak beraturan. - Mengapa → Akibatnya → Di layar: Kualitas sinyal turun karena dinding, jarak, microwave, Bluetooth, atau router tetangga → Pengiriman gagal di jalur nirkabel → dikirim ulang beberapa kali → Kedatangan paket tidak beraturan (jitter) sehingga karakter tersendat-sendat; jika parah, packet loss membuat karakter teleport - Gejala: Patah-patah, Teleport, Rubber banding / Faktor: Jitter, Packet loss - Siapa: Hanya saya, Satu rumah / Kapan: Sesekali secara acak, Selalu - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Sesuaikan panjang buffer interpolasi secara otomatis menurut kondisi koneksi, tampilkan status jaringan di layar jika jitter atau packet loss besar. - Tugas Pihak Eksternal: Imbau pemain untuk memakai koneksi kabel, memakai 5 GHz atau 6 GHz, dan memindahkan posisi router. - Kisaran angka: Satu kali retransmisi menambah sekitar 1–4 ms. Jika sinyal lemah, paket dikirim ulang berkali-kali dengan kecepatan rendah dan juga harus menunggu sampai channel kosong, sehingga latensi bisa melonjak 50–200 ms. Jebakannya, ping rata-rata terlihat normal. - Di grafik: Melonjak acak sesekali (RTT ke router) - Yang diperiksa: Ukur ping ke alamat router (default gateway di ipconfig) dengan ping /t selama beberapa menit, lalu periksa kekuatan sinyal dan channel router Anda dengan netsh wlan show networks mode=bssid. Bandingkan dengan koneksi kabel di tempat yang sama - Cocok jika: Ping ke router pun sudah melonjak tidak beraturan puluhan hingga ratusan ms, sesekali terjadi packet loss, dan kekuatan sinyalnya rendah. Hilang saat memakai kabel atau di dekat router - Tidak cocok jika: Ping ke router stabil, tetapi hanya bagian sesudahnya yang melonjak: mengarah ke koneksi atau jaringan ISP. Hanya melonjak dengan interval yang sama: lebih mungkin “Pemindaian Wi-Fi di latar belakang” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Pada mesh Wi-Fi, jika router (node) saling terhubung secara nirkabel (wireless backhaul), node perantara tidak bisa mengirim saat sedang menerima dan harus berbagi kesempatan kirim dengan segmen sebelum dan sesudahnya yang memakai channel yang sama, sehingga saat ramai throughput bisa turun dan latensi bertambah. Produk dengan pita nirkabel khusus untuk backhaul bisa lebih baik, dan jika node saling dihubungkan dengan kabel (Ethernet), segmen ini tidak lagi lewat nirkabel. Adapter powerline (PLC) juga memakai cara kirim yang memeriksa dulu apakah media kosong (CSMA/CA) seperti Wi-Fi, dan kualitasnya berubah-ubah mengikuti noise dari peralatan rumah tangga serta saat peralatan itu dinyalakan dan dimatikan, sehingga bisa terjadi retransmisi dan jitter. - Kasus nyata: ffxiv-2021 - Sumber: - [Resolve Wi-Fi and Bluetooth issues caused by wireless interference](https://support.apple.com/en-us/102319) · Apple · Sumber interferensi seperti microwave dan telepon nirkabel; Wi-Fi dan Bluetooth memakai pita 2,4 GHz yang sama; disarankan pindah ke 5 GHz dan memilih channel dengan interferensi rendah - [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325) · IETF · CSMA/CA pada 802.11: hanya mengirim saat channel kosong; jika sibuk, pengiriman ditunda sampai kosong lalu menunggu lagi selama random backoff - [Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017)](https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf) · USENIX · Antrean default Wi-Fi yang sedang dibebani menimbulkan latensi ratusan ms; median latensi perangkat yang tersambung dengan kecepatan rendah (sinyal lemah) tetap di atas 200 ms walau memakai FQ-CoDel - [ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) · Microsoft · /t: terus mengirim echo request sampai dihentikan - [ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig) · Microsoft · Jika dijalankan tanpa parameter, menampilkan alamat IPv4 dan IPv6 serta default gateway setiap adapter - [Wireless network connectivity issues troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/wireless-network-connectivity-issues-troubleshooting) · Microsoft · netsh wlan show networks mode=bssid: menampilkan BSSID, kekuatan sinyal, channel, dan standar nirkabel untuk setiap Wi-Fi yang terlihat - [Capacity of Ad Hoc Wireless Networks (MobiCom 2001)](https://pdos.csail.mit.edu/papers/grid:mobicom01/paper.pdf) · ACM · Jika paket diteruskan berkali-kali (multi-hop) lewat nirkabel 802.11, node tidak bisa mengirim saat sedang menerima dan segmen sebelum dan sesudahnya saling menimbulkan interferensi, sehingga throughput rute relay berantai secara teori turun hingga sepertiga (dalam simulasi sekitar sepertujuh) - [Electri-Fi Your Data: Measuring and Combining Power-Line Communications with WiFi (IMC 2015)](https://conferences.sigcomm.org/imc/2015/papers/p325.pdf) · ACM · Perangkat komersial powerline communication (IEEE 1901, HomePlug AV) mengirim dengan CSMA/CA mirip Wi-Fi, dan ketidakadilan jangka pendek bisa membuat jitter membesar; kualitas channel berubah mengikuti noise dari peralatan rumah tangga serta saat peralatan itu dinyalakan dan dimatikan (dalam skala beberapa menit hingga beberapa jam) #### hn-channel · Channel Wi-Fi padat · Crowded Wi-Fi channel Di tempat dengan puluhan router seperti apartemen, router harus berbagi channel yang sama sehingga harus menunggu kesempatan mengirim. - Mengapa → Akibatnya → Di layar: Puluhan router memakai channel 2,4 GHz yang sama → Untuk mengirim, harus menunggu sampai perangkat lain selesai mengirim dan channel kosong → Pada malam hari saat orang-orang pulang ke rumah, jitter (variasi selang waktu kedatangan paket) bertambah sehingga game patah-patah - Gejala: Patah-patah, Input lag / Faktor: Jitter, Latensi - Siapa: Satu rumah / Kapan: Jam sibuk malam hari - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Perpanjang buffer interpolasi secara otomatis saat jitter bertambah. - Tugas Pihak Eksternal: Imbau pemain untuk memakai 5 GHz atau 6 GHz, channel yang tidak terlalu padat, atau koneksi kabel. - Di grafik: Tinggi hanya di jam tertentu (RTT dan jitter ke router) - Yang diperiksa: Periksa channel dan kekuatan sinyal Wi-Fi di sekitar dengan netsh wlan show networks mode=bssid, lalu ukur ping ke router pada malam dan siang hari untuk dibandingkan - Cocok jika: Banyak router di sekitar terdeteksi di channel 2,4 GHz yang sama, dan jitter ke router hanya membesar pada malam hari. Berkurang setelah pindah ke 5 GHz, 6 GHz, atau channel yang lebih sepi - Tidak cocok jika: Melonjak tanpa kaitan dengan jam: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah”. Ping ke router baik, tetapi pada malam hari hanya bagian sesudahnya yang buruk: lebih mungkin “Kongesti di jalur peering saat jam sibuk” - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Recommended settings for Wi-Fi routers and access points](https://support.apple.com/en-us/102766) · Apple · Router dan perangkat lain yang memakai channel sama adalah sumber interferensi; untuk 2,4 GHz disarankan lebar 20 MHz; 5 GHz dan 6 GHz lebih sedikit masalah interferensinya - [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325) · IETF · Jika channel sibuk, 802.11 menunda pengiriman sampai kosong lalu mengirim setelah random backoff (CSMA/CA) - [Wireless network connectivity issues troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/wireless-network-connectivity-issues-troubleshooting) · Microsoft · netsh wlan show networks mode=bssid: menampilkan BSSID, kekuatan sinyal, channel, dan standar nirkabel untuk setiap Wi-Fi yang terlihat - [ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) · Microsoft · /t: terus mengirim echo request sampai dihentikan #### hn-bufferbloat · Bufferbloat (antrean router) · Bufferbloat Saat anggota keluarga mengunggah video atau mengunduh file besar, paket senilai ratusan ms menumpuk di antrean router, dan paket game pun menunggu di belakangnya. - Mengapa → Akibatnya → Di layar: Koneksi penuh karena upload video atau backup cloud oleh keluarga, live streaming yang Anda siarkan, atau unduhan besar → Router atau modem menyimpan paket yang meluap di antrean yang besar → Paket game juga menunggu di belakang antrean sehingga ping melonjak hingga ratusan ms - Gejala: Input lag, Fast forward, Teleport / Faktor: Latensi, Jitter - Siapa: Satu rumah, Hanya saya / Kapan: Sesekali secara acak, Jam sibuk malam hari - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Jika ping tiba-tiba naik ke ratusan ms, tampilkan status jaringan di layar (beri tahu kemungkinan ada transfer besar di koneksi yang sama). - Tugas Pihak Eksternal: Imbau pemain untuk memakai router dengan SQM (fq_codel, CAKE) atau QoS, mengatur kecepatan SQM ke 90–95% dari kecepatan koneksi (agar antrean terbentuk di dalam router sehingga efektif), dan membatasi kecepatan upload. - Kisaran angka: Pada koneksi dengan upload 10 Mbps dan buffer 1 MB, antrean bisa memanjang hingga senilai 800 ms. - Di grafik: Naik mengikuti beban (RTT, pemakaian upload dan download koneksi) - Yang diperiksa: Penuhi koneksi dengan tes kecepatan sambil ping tetap berjalan, atau gunakan tes web yang mengukur latensi saat koneksi dibebani (panduan Bufferbloat.net). Periksa bersama pemakaian upload dan download di halaman admin router - Cocok jika: Selama upload atau download memenuhi koneksi, ping naik ke ratusan ms dan kembali normal setelah transfer selesai (curigai jika latensi saat dibebani melebihi 50 ms). Hilang saat SQM diaktifkan - Tidak cocok jika: Ping melonjak walau koneksi sedang sepi: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah” atau “Kualitas koneksi buruk” - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Arah upload sangat mudah tersumbat, karena koneksi internet TV kabel dan seluler sering punya upload yang jauh lebih sempit daripada download. Di rumah dengan koneksi fiber optik yang lega, jalur Wi-Fi menjadi bottleneck, dan hal yang sama terjadi di antrean nirkabel router. Paket game kecil sehingga hampir tidak memakai bandwidth, tetapi tetap harus menunggu di antrean. Jika hanya arah upload yang tersumbat, hanya input Anda yang terlambat, sementara gerakan pemain lain normal. Di ponsel, backup foto atau update aplikasi di ponsel yang sama memenuhi antrean modem ponsel dan BTS sehingga hal yang sama terjadi. - Sumber: - [Setting up SQM for CeroWrt 3.10](https://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310/) · Bufferbloat.net · Kecepatan SQM harus diturunkan ke 95% dari kecepatan terukur (85% jika berdasarkan kecepatan yang diiklankan) agar bottleneck pindah dari perangkat ISP ke dalam router sehingga efektif - [SQM (Smart Queue Management)](https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm) · OpenWrt · Masukkan kecepatan download dan upload sebesar 90% dari hasil pengukuran; disarankan memakai antrean cake (fq_codel jika CPU lemah) - [Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017)](https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf) · USENIX · Jika jalur Wi-Fi penuh, antrean nirkabel router menimbulkan latensi ratusan ms; memperbaiki antrean nirkabel menurunkan latensi saat dibebani menjadi sekitar sepersepuluhnya - [Tests for Bufferbloat](https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/) · Bufferbloat.net · Jika ping naik saat koneksi dipenuhi tes kecepatan sambil ping tetap berjalan, berarti terjadi bufferbloat; disarankan mengambil tindakan jika latensi saat dibebani lebih dari 50 ms (atau peringkatnya di bawah B) #### hn-nat · Mapping NAT kedaluwarsa · NAT mapping timeout Router menghapus koneksi idle yang lama tidak dilewati paket dari tabel NAT. Ini penyebab umum disconnect tepat saat pemain mulai bergerak setelah lama diam. - Mengapa → Akibatnya → Di layar: Router mencatat koneksi “perangkat di dalam ↔ server di luar” di tabel NAT (tabel translasi alamat) → Jika lama tidak ada paket, entri dihapus dari tabel (untuk UDP umumnya 30–120 detik) → Paket dari server tidak bisa masuk ke dalam rumah sehingga terjadi disconnect - Gejala: Disconnect / Faktor: Packet loss - Siapa: Hanya saya, Satu rumah / Kapan: Setelah lama diam - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (mapping UDP hanya diperbarui dengan pasti oleh paket yang keluar dari dalam rumah, jadi klien yang mengirim), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, dan jika mapping terhapus sehingga alamat dan port luar berubah, pastikan pemainnya sama lewat token sesi (nomor konfirmasi yang diterima saat login) lalu lanjutkan sesinya. - Di grafik: Koneksi putus serentak (Jumlah disconnect (timeout heartbeat), waktu idle sebelum terputus) - Yang diperiksa: Kumpulkan alasan disconnect di server dan waktu yang berlalu sejak paket terakhir lewat di koneksi itu sebelum terputus (waktu idle), lalu lihat distribusinya. Untuk pengujian, perpanjang interval paket UDP menjadi 30 detik, 60 detik, dan 120 detik, lalu ukur pada interval berapa respons berhenti - Cocok jika: Hanya koneksi yang diam yang terputus, dan waktu idle-nya terkumpul tepat setelah nilai tertentu seperti 30–120 detik. Hilang jika interval heartbeat dibuat lebih pendek dari itu - Tidak cocok jika: Tetap terputus saat sedang bergerak: mengarah ke koneksi atau rute. Terkumpul pada nilai pendek hanya di operator seluler tertentu: lebih mungkin “IP bersama dari ISP (CGNAT)” - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) · IETF · Timer mapping UDP tidak boleh habis sebelum 2 menit dan disarankan minimal 5 menit secara default; pembaruan oleh paket keluar wajib, sedangkan pembaruan oleh paket masuk opsional - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · Pengukuran 34 router rumahan: mapping UDP bertahan 30–691 detik dengan median 90 detik sehingga lebih dari separuhnya kurang dari 2 menit; TCP median sekitar 60 menit - [RFC 9308: Applicability of the QUIC Transport Protocol](https://www.rfc-editor.org/rfc/rfc9308) · IETF · Di internet dengan NAT di sepanjang rute, keep-alive dengan interval sekitar 30 detik sudah memadai; lebih sering dari itu memboroskan trafik dan daya #### hn-router · Router kurang bertenaga atau terlalu panas · Router CPU / session table exhaustion Jika puluhan perangkat dan ribuan koneksi membebani router murah, router itu sendiri tidak sanggup memprosesnya. - Mengapa → Akibatnya → Di layar: Puluhan perangkat serta P2P dan torrent membuka ribuan koneksi → CPU dan tabel sesi router penuh → Pemrosesan paket terlambat dan paket hilang, koneksi baru gagal - Gejala: Patah-patah, Tidak bisa masuk / loading tanpa henti, Disconnect / Faktor: Packet loss, Jitter - Siapa: Satu rumah / Kapan: Makin lama menyala, Sesekali secara acak - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) - Tugas Pihak Eksternal: Imbau pemain untuk memulai ulang router (sementara), mengganti router, dan menutup program yang membuka banyak koneksi (P2P, torrent). - Di grafik: Mendatar di batas (CPU dan jumlah koneksi router, RTT ke router) - Yang diperiksa: Periksa pemakaian CPU, jumlah koneksi (sesi), dan jumlah perangkat yang tersambung di halaman admin router (jika router mendukung), lalu bandingkan ping ke router itu sendiri sebelum dan sesudah router dimulai ulang - Cocok jika: Saat jumlah koneksi banyak, ping ke router pun sudah melonjak atau terjadi packet loss, dan koneksi baru gagal. Setelah dimulai ulang, normal untuk sementara lalu memburuk lagi - Tidak cocok jika: Ping ke router normal dan hanya bagian sesudahnya yang buruk: mengarah ke koneksi atau jaringan ISP - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · Jumlah koneksi TCP yang diizinkan router rumahan ke satu port server adalah 16 hingga sekitar 1.024 (median 135), dan throughput perangkat murah kadang hanya beberapa Mbps - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Jumlah entri maksimum tabel connection tracking Linux (nf_conntrack_max) dan nilai default waktu simpan per state #### hn-handover · Handover antar-BTS (saat bergerak) · Cellular handover Saat bepergian dengan bus atau kereta bawah tanah, komunikasi terputus selama BTS berganti. - Mengapa → Akibatnya → Di layar: BTS yang tersambung berganti saat bergerak → Biasanya hanya jeda puluhan ms, tetapi jika sinyal buruk dan perpindahan gagal, koneksi bisa putus ratusan ms hingga beberapa detik → Berhenti lalu teleport; jika lama, disconnect - Gejala: Freeze, Teleport, Disconnect / Faktor: Packet loss - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: atur timeout agar tahan terhadap putus singkat, percepat reconnect. Server: atur timeout agar pemain tidak langsung dikeluarkan walau terputus beberapa detik, sambungkan kembali ke sesi yang sama saat reconnect. - Tugas Pihak Eksternal: Informasikan kepada pemain bahwa koneksi putus saat bepergian (bus, kereta bawah tanah) disebabkan oleh perpindahan BTS. - Di grafik: Kosong lalu datang sekaligus (Jumlah paket yang diterima, RTT) - Yang diperiksa: Periksa apakah laporan koneksi putus terjadi saat bepergian (bus, kereta bawah tanah), lalu periksa waktu kekosongan penerimaan di log klien serta perubahan jenis jaringan dan sinyal - Cocok jika: Hanya saat bergerak, penerimaan kosong ratusan ms hingga beberapa detik lalu datang sekaligus, dan tidak bisa direproduksi saat diam - Tidak cocok jika: Tetap sama walau diam: lebih mungkin “Sinyal seluler lemah dan area blank spot” atau “Perpindahan 5G↔LTE yang sering (di tepi jangkauan 5G)” - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s)](https://www.itu.int/pub/R-REP-M.2134-2008) · ITU · Persyaratan waktu tanpa kirim-terima data selama handover: frekuensi sama 27,5 ms, frekuensi berbeda 40–60 ms - [Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption (SIGCOMM 2020)](https://xyzhang.ucsd.edu/papers/DXu_SIGCOMM20_5Gmeasure.pdf) · ACM · Latensi handover terukur di jaringan komersial: 4G↔4G rata-rata 30 ms, antarsel 5G (NSA) rata-rata 108 ms #### hn-rrc · Jeda transisi state RRC (hemat daya radio seluler) · Radio state promotion (RRC) Jika lama tidak ada komunikasi, ponsel menurunkan koneksi radio ke status daya rendah, lalu harus menaikkannya lagi saat paket berikutnya sehingga terlambat. - Mengapa → Akibatnya → Di layar: Jika sebentar saja tidak ada komunikasi, ponsel mengalihkan koneksi radio ke mode hemat daya → Untuk mengirim paket berikutnya, koneksi harus dinaikkan lagi → Hanya aksi pertama setelah diam yang terasa sangat terlambat - Gejala: Input lag / Faktor: Latensi - Siapa: Hanya saya / Kapan: Setelah lama diam - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Jaga koneksi tetap aktif dengan pengiriman berkala yang ringan (sebagai gantinya baterai lebih boros). - Kisaran angka: LTE biasanya turun ke mode hemat daya jika tidak ada komunikasi sekitar 10 detik, dan butuh puluhan hingga ratusan ms untuk naik lagi (contoh pengukuran: sekitar 0,3–0,6 detik). 3G butuh 1 detik atau lebih. - Di grafik: Hanya sebagian yang tinggi (RTT permintaan pertama setelah idle (mobile)) - Yang diperiksa: Kelompokkan RTT di dalam game menurut jarak waktu dari komunikasi sebelumnya. Di mobile, bandingkan RTT paket pertama yang dikirim setelah diam lebih dari 10 detik dengan paket yang dikirim beruntun - Cocok jika: Di jaringan seluler, hanya paket pertama setelah diam yang terlambat ratusan ms, sedangkan paket yang langsung menyusul normal. Di Wi-Fi tidak ada perbedaan - Tidak cocok jika: Tetap terlambat walau dikirim beruntun: mengarah ke sinyal, koneksi, atau rute - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance (SIGCOMM 2013)](https://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p363.pdf) · ACM · Timer peralihan ke hemat daya (tail) di jaringan LTE yang diukur 10 detik; median latensi untuk naik lagi dari hemat daya 435 ms (persentil 25–75: 319–558 ms); 3G sekitar 1,5–2 detik - [Optimize network access](https://developer.android.com/develop/connectivity/network-ops/network-access-optimization) · Android (Google) · Latensi transisi state radio dan waktu tail berbeda menurut teknologi radio (3G, LTE, 5G) dan pengaturan operator; contoh 3G: daya rendah→daya penuh sekitar 1,5 detik, idle→daya penuh lebih dari 2 detik - [Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s)](https://www.itu.int/pub/R-REP-M.2134-2008) · ITU · Persyaratan latensi control plane dari state idle ke aktif kurang dari 100 ms (tidak termasuk paging dan jalur kabel) #### hn-weak-cell · Sinyal seluler lemah dan area blank spot · Weak cellular signal Di lift, ruang bawah tanah, atau bagian dalam gedung, retransmisi bertambah, kecepatan turun, dan akhirnya terjadi disconnect. - Mengapa → Akibatnya → Di layar: Berpindah ke tempat dengan sinyal lemah → Retransmisi radio bertambah, kecepatan turun, koneksi putus sesaat → Jitter dan packet loss menyebabkan patah-patah dan teleport, akhirnya disconnect - Gejala: Patah-patah, Teleport, Disconnect / Faktor: Jitter, Packet loss - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Rapikan alur reconnect, tampilkan kualitas jaringan. - Tugas Pihak Eksternal: Informasikan kepada pemain bahwa masalah ini terjadi di tempat dengan sinyal lemah (lift, ruang bawah tanah, bagian dalam gedung). - Di grafik: Hanya sebagian yang tinggi (RTT dan packet loss (per pemain mobile)) - Yang diperiksa: Periksa lokasi saat laporan disconnect (lift, ruang bawah tanah, dalam gedung) dan indikator sinyal ponsel, lalu ulangi aksi yang sama di tempat dengan sinyal bagus untuk dibandingkan - Cocok jika: RTT dan packet loss naik lalu koneksi putus hanya di tempat dengan sinyal lemah, dan hilang setelah pindah ke tempat dengan sinyal bagus - Tidak cocok jika: Tetap sama walau sinyal bagus: mengarah ke jaringan ISP atau sisi server - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [An In-depth Study of LTE: Effect of Network Protocol and Application Behavior on Performance (SIGCOMM 2013)](https://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p363.pdf) · ACM · LTE menyembunyikan packet loss di jalur radio dengan retransmisi di lapisan fisik dan MAC; bandwidth yang tersedia berubah drastis dalam hitungan detik mengikuti kekuatan sinyal dan faktor lainnya #### hn-5g-flip · Perpindahan 5G↔LTE yang sering (di tepi jangkauan 5G) · 5G NSA / LTE switching Di dalam gedung dengan sinyal 5G lemah atau di tepi jangkauan 5G, ponsel sering berpindah antara 5G dan LTE, dan setiap kali berpindah ping melonjak atau komunikasi terputus sejenak. - Mengapa → Akibatnya → Di layar: Berada di tempat dengan sinyal 5G yang naik turun (dalam gedung, tepi jangkauan 5G) → Ponsel sering berpindah antara 5G dan LTE, dan setiap kali itu muncul jeda singkat → Ping melonjak tanpa pola walau diam, sesekali freeze atau teleport - Gejala: Patah-patah, Teleport, Freeze / Faktor: Jitter, Packet loss - Siapa: Hanya saya / Kapan: Sesekali secara acak, Saat bergerak atau pindah area - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Perpanjang buffer interpolasi secara otomatis saat jitter bertambah, sertakan perubahan jenis jaringan (5G/LTE) di log saat terjadi lag untuk membedakan penyebabnya. - Tugas Pihak Eksternal: Imbau pemain untuk beralih ke mode yang mengutamakan LTE di pengaturan sebagai pembanding, sarankan memakai Wi-Fi. - Kisaran angka: Satu kali perpindahan memakan puluhan hingga ratusan ms. 5G di Korea kebanyakan memakai cara yang digabung dengan LTE (NSA), sehingga koneksi 5G-nya mudah tersambung dan terlepas. - Di grafik: Melonjak acak sesekali (RTT, perubahan jenis jaringan (5G/LTE)) - Yang diperiksa: Ubah pengaturan ponsel agar mengutamakan LTE lalu bandingkan di tempat yang sama. Lebih pasti jika klien mencatat perubahan indikator jaringan di TelephonyDisplayInfo Android (OVERRIDE_NETWORK_TYPE_NR_NSA dan sebagainya) bersama RTT - Cocok jika: Waktu RTT melonjak bertepatan dengan waktu indikator 5G↔LTE berubah, dan lonjakan hilang di mode yang mengutamakan LTE - Tidak cocok jika: Tetap melonjak walau indikator jaringan tidak berubah: lebih mungkin “Sinyal seluler lemah dan area blank spot” atau sisi koneksi - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Understanding Operational 5G: A First Measurement Study on Its Coverage, Performance and Energy Consumption (SIGCOMM 2020)](https://xyzhang.ucsd.edu/papers/DXu_SIGCOMM20_5Gmeasure.pdf) · ACM · 5G NSA menyerahkan kontrol ke LTE, sehingga saat berganti sel 5G, ponsel melepas 5G, lewat LTE, lalu tersambung lagi: rata-rata 108 ms (4G→5G 80 ms); throughput TCP turun 73–83% tepat setelah perpindahan yang melibatkan 5G - [5G 통신서비스 품질평가 결과 발표](https://www.korea.kr/briefing/policyBriefingView.do?newsId=156404679) · 과학기술정보통신부 · Berdasarkan pengumuman tahun 2020, 5G di Korea disediakan dengan cara NSA dan peralihan ke SA masih dalam tahap rencana - [TelephonyDisplayInfo](https://developer.android.com/reference/android/telephony/TelephonyDisplayInfo) · Android (Google) · OVERRIDE_NETWORK_TYPE_NR_NSA: indikator jaringan saat tersambung ke LTE dan dapat atau sedang tersambung ganda (EN-DC) dengan 5G (NR) #### hn-captive · Pembatasan di Wi-Fi publik dan jaringan kantor · Captive portal, restrictive network Halaman login Wi-Fi kafe atau firewall kantor memblokir koneksi game. - Mengapa → Akibatnya → Di layar: Belum lolos autentikasi di halaman login, atau firewall memblokir port game dan UDP → Upaya koneksi itu sendiri diblokir, atau hanya sebagian yang lolos → Tidak bisa masuk; login berhasil, tetapi gagal masuk ke game - Gejala: Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Hanya saya / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: tampilkan pesan yang menjelaskan alasan saat diblokir (belum autentikasi di halaman login, UDP diblokir, dan sebagainya), beralih otomatis ke rute cadangan jika UDP diblokir. Server: sediakan rute cadangan seperti TCP 443. - Tugas Pihak Eksternal: Imbau pemain untuk menyelesaikan autentikasi di halaman login lebih dulu saat memakai Wi-Fi publik, dan memakai jaringan lain di tempat yang dibatasi seperti jaringan kantor. - Di grafik: Hanya sebagian yang tinggi (Jumlah kegagalan koneksi (per jaringan)) - Yang diperiksa: Minta pemain yang gagal mencoba tersambung lewat jaringan lain seperti data seluler, lalu periksa di log koneksi server apakah paket UDP pertama sampai dan apakah koneksi lewat rute cadangan TCP 443 berhasil - Cocok jika: Hanya gagal di Wi-Fi tertentu (kafe, kantor) dan langsung tersambung di jaringan lain. Belum autentikasi di halaman login, atau hanya UDP yang tidak sampai ke server - Tidak cocok jika: Gagal di jaringan mana pun: mengarah ke akun, server, atau “Gangguan dan latensi DNS”. Gagal di seluruh negara atau ISP tertentu: lebih mungkin “Pembatasan UDP dan inspeksi paket per negara atau ISP” - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [RFC 8952: Captive Portal Architecture](https://www.rfc-editor.org/rfc/rfc8952) · IETF · Captive portal: jaringan yang membatasi akses sampai syarat seperti persetujuan ketentuan atau autentikasi dipenuhi - [RFC 9308: Applicability of the QUIC Transport Protocol](https://www.rfc-editor.org/rfc/rfc9308) · IETF · Menurut studi pengukuran, 3–5% jaringan memblokir UDP sepenuhnya, sehingga aplikasi berbasis UDP harus menyiapkan rute cadangan TCP (TLS) ### L4 Jalur internet (14 penyebab) #### isp-distance · Latensi propagasi (jarak fisik) · Propagation delay Di kabel serat optik, cahaya pun hanya menempuh sekitar 200.000 km per detik. Server yang jauh tetap lambat, sebagus apa pun servernya. - Mengapa → Akibatnya → Di layar: Server berada jauh (server luar negeri, benua lain) → Waktu pulang-pergi bertambah sebanding dengan jarak (minimal 10 ms per 1.000 km) → Input lag yang tetap di setiap aksi, pemain dirugikan dalam keputusan server - Gejala: Input lag / Faktor: Latensi - Siapa: Wilayah/ISP tertentu / Kapan: Selalu - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Infrastruktur jaringan (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Hanya bisa diredam karena hukum fisika tidak bisa diperbaiki lewat kode, sediakan pilihan region agar pemain memakai server region terdekat, kurangi kerugian dalam keputusan server dengan lag compensation (memutar mundur waktu). - Tugas Tim Infrastruktur: Server/OS: tempatkan server per region di wilayah yang banyak pemainnya. Jaringan: tempatkan titik akses (edge) di lokasi yang dekat, pilih jalur dan rute yang sedikit memutar. - Kisaran angka: Seoul–Tokyo sekitar 30 ms, Seoul–Singapura sekitar 75 ms, Seoul–AS bagian barat sekitar 140 ms, Seoul–Eropa sekitar 230–270 ms (pulang-pergi, berdasarkan rute sebenarnya). Ke Eropa hampir tidak ada kabel besar yang membentang lurus, sehingga rutenya memutar lewat Asia Tenggara dan Suez atau lewat AS, dan latensinya jauh lebih besar daripada perkiraan dari jarak. - Di grafik: Selalu tinggi sejak awal (RTT (per negara dan wilayah)) - Yang diperiksa: Tandai IP pemain dengan negaranya dan periksa distribusi RTT per negara, lalu ukur dengan ping dan traceroute ke server dari VM di region cloud wilayah itu atau dari probe RIPE Atlas (dipilih berdasarkan negara dan ASN) - Cocok jika: RTT dari negara yang jauh selalu tinggi tanpa kaitan dengan jam, dan nilainya mendekati latensi minimum yang dihitung dari jarak (10 ms pulang-pergi per 1.000 km) serta statistik latensi publik - Tidak cocok jika: Jauh lebih tinggi daripada nilai yang bisa dijelaskan oleh jarak: lebih mungkin “Routing memutar”. Hanya naik pada malam hari: lebih mungkin “Kongesti di jalur peering saat jam sibuk” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Kasus nyata: riot-direct-2015 - Sumber: - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Nilai perencanaan latensi propagasi di kabel serat optik 5 µs/km (sekitar 200.000 km per detik, 10 ms pulang-pergi per 1.000 km) - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Median pulang-pergi terukur dari Seoul (Korea Central): Tokyo 30 ms, Singapura 68 ms, AS bagian barat 124–136 ms, Eropa 234–244 ms - [AAE-1 & SMW5 cable cuts impact millions of users across multiple countries](https://blog.cloudflare.com/aae-1-smw5-cable-cuts/) · Cloudflare · Trafik antara Eropa dan Asia umumnya lewat kabel bawah laut yang melintasi Mesir (Suez) - [Probe Selection (RIPE Atlas REST API)](https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/creating-measurements/probe-selection/) · RIPE NCC · Memilih probe untuk pengukuran RIPE Atlas berdasarkan negara, wilayah, ASN, atau blok alamat, lalu menjalankan ping dan traceroute #### isp-satellite · Internet satelit (orbit rendah dan geostasioner) · Satellite internet (LEO, GEO) Pada internet satelit, sinyal harus bolak-balik ke luar angkasa. Dengan satelit geostasioner, pulang-pergi saja sudah lebih dari 0,5 detik. Satelit orbit rendah seperti Starlink biasanya cepat, tetapi saat rute dialokasikan ulang, latensinya berfluktuasi dan koneksi kadang putus sesaat. - Mengapa → Akibatnya → Di layar: Terhubung dari rumah, kapal, atau pesawat lewat internet satelit geostasioner atau orbit rendah, atau lewat Wi-Fi pesawat yang memakai satelit → Satelit geostasioner berada di ketinggian sekitar 36.000 km sehingga jarak tempuhnya memang panjang; satelit orbit rendah mengalokasikan ulang rute terminal, satelit, dan stasiun bumi dalam siklus pendek, dan pada saat itu muncul latensi dan packet loss sesaat → Geostasioner: input lag besar di setiap aksi. Orbit rendah: biasanya normal, tetapi secara berkala terjadi patah-patah atau teleport - Gejala: Input lag, Patah-patah, Teleport / Faktor: Latensi, Jitter, Packet loss - Siapa: Hanya saya, Satu rumah, Wilayah/ISP tertentu / Kapan: Selalu, Secara berkala - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: perpanjang buffer interpolasi secara otomatis mengikuti jitter, kirim input secara duplikat agar tahan terhadap packet loss singkat, tampilkan kualitas koneksi. Server: perhitungkan latensi koneksi satelit saat menentukan timing window dan batas lag compensation, pakai timeout yang tidak langsung mengeluarkan pemain karena jeda kosong sekitar 1 detik. - Tugas Pihak Eksternal: Beri tahu pemain bahwa internet satelit bisa memiliki latensi besar atau melonjak secara berkala, imbau pemain untuk memakai jaringan kabel darat untuk konten kompetitif bila memungkinkan. - Kisaran angka: Pada satelit geostasioner (ketinggian 36.000 km), perjalanan sinyal melintasi luar angkasa saja sudah 260 ms satu arah sehingga pulang-pergi lebih dari 520 ms (ITU-T G.114). Untuk Starlink yang memakai orbit rendah, data resmi (nilai rata-rata 15 detik) menunjukkan median 33 ms pada jam sibuk di AS, dan 1% terburuk (p99) pun di bawah 65 ms (2024). Dalam studi pengukuran, latensi berubah setiap kali rute dialokasikan ulang tiap 15 detik, dan muncul putus singkat kurang dari 1 detik. Dalam pengukuran internet di pesawat tahun 2018, latensi pulang-pergi sistem satelit rata-rata 750 ms. - Di grafik: Hanya sebagian yang tinggi (RTT dan jitter (per ASN penyedia internet satelit)) - Yang diperiksa: Periksa apakah ASN dari IP pemain milik penyedia internet satelit, lalu gambar distribusi dan deret waktu RTT pemain penyedia itu secara terpisah. Ukur ping terus-menerus selama beberapa menit dari probe RIPE Atlas di ASN itu ke server, atau minta pemain menjalankan ping dan mengukur interval lonjakannya - Cocok jika: Penyedia geostasioner: RTT selalu di atas 500 ms. Penyedia orbit rendah: RTT biasanya puluhan ms, lalu berubah atau putus singkat dengan interval sekitar 15 detik - Tidak cocok jika: Penyedianya tidak memakai satelit, tetapi RTT selalu tinggi: lebih mungkin “Latensi propagasi (jarak fisik)” atau “Routing memutar”. Melonjak tidak beraturan: mengarah ke sinyal Wi-Fi atau seluler - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Karena jarak ke satelit orbit rendah pendek (Starlink 1,8–3,6 ms per segmen), latensi sehari-harinya bisa mirip dengan koneksi darat. Namun, jika titik keluar ke internet dari stasiun bumi (PoP) jauh dari server game, rutenya bertambah panjang, dan jika rute memutar lewat laser link antarsatelit, latensinya bertambah lagi. Menurut studi pengukuran, fluktuasi dengan siklus 15 detik berasal dari realokasi rute yang terjadi pada waktu yang sama di seluruh dunia dan tidak berkaitan dengan perpindahan antarsatelit. Latensi Wi-Fi pesawat sangat berbeda menurut sistemnya (satelit atau BTS darat), dan sistem yang memakai satelit geostasioner menghasilkan waktu pulang-pergi panjang seperti di atas. - Sumber: - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Nilai perencanaan latensi propagasi satu arah di segmen satelit: ketinggian 400 km 12 ms, 14.000 km 110 ms, 36.000 km (geostasioner) 260 ms - [Improving Starlink’s Latency](https://starlink.com/public-files/StarlinkLatency.pdf) · Starlink · Median jam sibuk di AS 48,5 ms→33 ms, 1% paling lambat (p99) di atas 150 ms→di bawah 65 ms (2024); propagasi per segmen satelit 1,8–3,6 ms; latensi bertambah jika rute memutar lewat laser link, dan jarak dari stasiun bumi ke titik akses internet (PoP) juga menambah latensi - [A Multifaceted Look at Starlink Performance (WWW 2024)](https://www.nitindermohan.com/documents/2024/pubs/starlinkWWW2024.pdf) · ACM · Starlink mengalokasikan ulang rute setiap 15 detik pada waktu yang sama di seluruh dunia; di batas itu latensi dan throughput berfluktuasi dan muncul putus singkat kurang dari 1 detik (penyebabnya tidak terkait perpindahan antarsatelit); latensi segmen terminal↔satelit↔stasiun bumi sekitar 40 ms - [Mile High WiFi: A First Look at In-Flight Internet Connectivity (WWW 2018)](https://aqualab.cs.northwestern.edu/publication/2018/jrula-www18/) · ACM · Pengukuran internet di pesawat selama 45 jam: latensi pulang-pergi rata-rata 200 ms untuk sistem BTS darat dan 750 ms untuk sistem satelit; median tingkat packet loss sistem satelit 7% - [Probe Selection (RIPE Atlas REST API)](https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/creating-measurements/probe-selection/) · RIPE NCC · Memilih probe untuk pengukuran RIPE Atlas berdasarkan negara, wilayah, ASN, atau blok alamat, lalu menjalankan ping dan traceroute #### isp-routing · Routing memutar · Suboptimal routing Karena kontrak interkoneksi antar-ISP, rute ke server yang dekat pun bisa memutar lewat tempat yang jauh. - Mengapa → Akibatnya → Di layar: ISP Anda dan ISP di sisi server tidak terhubung langsung → Rute melewati negara atau kota lain sehingga jarak dan jumlah perangkat yang dilewati bertambah → Hanya pelanggan ISP tertentu yang ping-nya sangat tinggi - Gejala: Input lag / Faktor: Latensi - Siapa: Wilayah/ISP tertentu / Kapan: Selalu - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Infrastruktur: Hubungkan ke beberapa ISP (multihoming), pantau ping per ISP untuk menemukan ISP yang rutenya memutar, rundingkan penyesuaian rute dengan ISP. - Tugas Pihak Eksternal: Minta ISP terkait untuk menyesuaikan rute. - Kisaran angka: Bahkan di dalam satu negara, ping bisa berbeda dua sampai tiga kali lipat tergantung rutenya. - Di grafik: Selalu tinggi sejak awal (RTT (per ISP dan ASN)) - Yang diperiksa: Bandingkan RTT per ISP (ASN), lalu periksa negara dan kota yang dilewati rute dengan traceroute atau mtr dari probe RIPE Atlas di ISP yang lambat atau dari pemain. Ukur IPv4 dan IPv6 secara terpisah (mtr -4, -6) - Cocok jika: Di wilayah yang sama, hanya ISP tertentu yang selalu tinggi, dan rutenya melewati negara lain atau kota yang jauh. Atau hanya salah satu versi alamat (IPv4 atau IPv6) yang tinggi - Tidak cocok jika: Semua ISP sama-sama tinggi: lebih mungkin “Latensi propagasi (jarak fisik)”. Tinggi hanya pada malam hari: lebih mungkin “Kongesti di jalur peering saat jam sibuk” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Rute IPv4 dan IPv6 ditentukan secara terpisah, sehingga untuk server yang sama pun salah satunya bisa memutar jauh dan menjadi lambat (pengukuran APNIC 2016: di dalam satu ISP muncul kelompok pengguna yang IPv6-nya lebih lambat 15, 25, atau 75 ms daripada IPv4). Aplikasi dengan Happy Eyeballs (RFC 8305), yaitu cara yang memakai IPv6 atau IPv4 mana pun yang lebih dulu tersambung, mencoba IPv6 lebih dulu, dan jika IPv6 tersambung dalam 250 ms (nilai yang disarankan), IPv4 tidak dicoba. Karena itu, meski IPv6 sedikit lebih lambat, koneksi cenderung tersambung lewat rute IPv6. Jika ping tinggi hanya di ISP tertentu, ukur IPv4 dan IPv6 secara terpisah. - Kasus nyata: riot-direct-2015 - Sumber: - [Quantifying the Causes of Path Inflation (SIGCOMM 2003)](https://conferences.sigcomm.org/sigcomm/2003/papers/p113-spring.pdf) · ACM · Analisis 65 ISP: kebijakan peering antar-ISP dan routing antardomain sangat memperpanjang rute - [The Internet at the Speed of Light (HotNets 2014)](https://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final111.pdf) · ACM · Rute router sebenarnya memiliki median sekitar 1,5 kali panjang garis lurus kabel serat optik; ada juga kasus paket antara dua titik yang berdekatan memutar ke sisi lain bumi (hairpinning) - [Probe Selection (RIPE Atlas REST API)](https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/creating-measurements/probe-selection/) · RIPE NCC · Memilih probe untuk pengukuran RIPE Atlas berdasarkan negara, wilayah, ASN, atau blok alamat, lalu menjalankan ping dan traceroute - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · Dengan -4 atau -6, rute diukur hanya lewat IPv4 atau hanya lewat IPv6 - [RFC 8305: Happy Eyeballs Version 2: Better Connectivity Using Concurrency](https://www.rfc-editor.org/rfc/rfc8305) · IETF · Alamat atau versi alamat (IPv4, IPv6) bisa diblokir, rusak, atau lambat tergantung jaringannya; IPv6 dicoba lebih dulu, dan percobaan koneksi berikutnya menunggu 250 ms sesuai rekomendasi - [IPv6 Performance – Revisited](https://blog.apnic.net/2016/08/22/ipv6-performance-revisited/) · APNIC · Perbandingan waktu pulang-pergi IPv6 dan IPv4 pada pengguna dual-stack yang sama: jaringan akses bisa memproses paket IPv6 dengan cara yang sangat berbeda, sehingga di dalam satu ISP muncul kelompok yang IPv6-nya lebih lambat 15, 25, atau 75 ms #### isp-peak · Kongesti di jalur peering saat jam sibuk · Peak-hour congestion at peering Sekitar pukul 21.00–23.00, trafik video melonjak sehingga jalur interkoneksi antar-ISP (peering) mudah padat. - Mengapa → Akibatnya → Di layar: Streaming dan unduhan menumpuk pada malam hari → Terjadi antrean dan packet loss di jalur peering → Hanya pada malam hari, pelanggan ISP tertentu mengalami patah-patah atau teleport - Gejala: Patah-patah, Teleport, Rubber banding / Faktor: Jitter, Packet loss, Latensi - Siapa: Wilayah/ISP tertentu / Kapan: Jam sibuk malam hari - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Infrastruktur: Tambah koneksi langsung dengan ISP terkait, alihkan rute yang padat, pantau packet loss dan ping per ISP pada malam hari. - Tugas Pihak Eksternal: Minta ISP terkait untuk menambah kapasitas jalur peering. - Di grafik: Tinggi hanya di jam tertentu (RTT dan packet loss (per ISP)) - Yang diperiksa: Gambar RTT dan packet loss per ISP (ASN) menurut jam, lalu ambil hasil mtr dari probe RIPE Atlas di ISP itu atau dari pemain, masing-masing pada malam dan siang hari, untuk melihat segmen tempat packet loss mulai muncul - Cocok jika: Hanya ISP tertentu yang RTT dan packet loss-nya naik setiap malam sekitar pukul 21.00–23.00, dan di mtr packet loss serta latensi muncul terus dari segmen interkoneksi antar-ISP sampai ke tujuan - Tidak cocok jika: Semua ISP naik bersamaan: mengarah ke jalur atau server kami. Hanya satu rumah yang buruk pada malam hari: lebih mungkin “Channel Wi-Fi padat” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Inferring Persistent Interdomain Congestion (SIGCOMM 2018)](https://www.caida.org/catalog/papers/2018_inferring_persistent_interdomain_congestion/inferring_persistent_interdomain_congestion.pdf) · ACM · Kongesti berulang yang menaikkan latensi setiap jam sibuk di sebagian segmen interkoneksi antar-ISP; pada jam kongesti, tingkat packet loss juga naik - [Probe Selection (RIPE Atlas REST API)](https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/creating-measurements/probe-selection/) · RIPE NCC · Memilih probe untuk pengukuran RIPE Atlas berdasarkan negara, wilayah, ASN, atau blok alamat, lalu menjalankan ping dan traceroute #### isp-cable · Gangguan kabel bawah laut dan jalur internasional · Submarine cable fault Jika kabel bawah laut putus, trafik harus memutar lewat rute yang jauh selama beberapa minggu (jika lama, beberapa bulan) sampai kabel diperbaiki, dan jalur yang tersisa menjadi padat. - Mengapa → Akibatnya → Di layar: Kabel putus atau perangkat rusak → Trafik menumpuk di rute memutar yang jauh dan di jalur yang tersisa → Ping pemain dari luar negeri melonjak dan packet loss berlangsung beberapa hari hingga beberapa minggu - Gejala: Input lag, Teleport / Faktor: Latensi, Packet loss - Siapa: Wilayah/ISP tertentu / Kapan: Selalu - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Infrastruktur: Siapkan jalur di rute lain, pindahkan trafik ke rute itu saat terjadi gangguan. - Tugas Pihak Eksternal: Umumkan penyebab dan perkiraan waktu pemulihan kepada pemain dari luar negeri, minta penyedia jalur untuk mengonfirmasi jadwal pemulihan. - Di grafik: Naik seperti anak tangga (RTT (per negara di luar negeri)) - Yang diperiksa: Cari waktu kenaikan di grafik RTT dan packet loss per negara, cocokkan dengan ringkasan gangguan internet di Cloudflare Radar dan pengumuman operator kabel bawah laut, lalu pastikan dengan traceroute apakah rute memutar lewat benua lain - Cocok jika: Sejak saat tertentu, RTT ke wilayah tertentu di luar negeri naik satu tingkat dan bertahan beberapa hari hingga beberapa minggu, dan pada periode yang sama ada laporan gangguan kabel. Rute berubah menjadi rute memutar yang jauh dan berbeda dari biasanya - Tidak cocok jika: Kembali normal dalam beberapa hari dan tidak ada laporan gangguan: lebih mungkin “Perubahan rute dan konvergensi BGP” atau segmen ISP - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [AAE-1 & SMW5 cable cuts impact millions of users across multiple countries](https://blog.cloudflare.com/aae-1-smw5-cable-cuts/) · Cloudflare · Perbaikan kabel bawah laut memerlukan kapal perbaikan sehingga biasanya butuh beberapa hari hingga beberapa minggu (kasus Tonga 38 hari); saat kabel putus, latensi dan packet loss di segmen Eropa–Asia meningkat - [Q2 2024 Internet disruption summary](https://blog.cloudflare.com/q2-2024-internet-disruption-summary/) · Cloudflare · Kabel Laut Merah yang rusak pada Februari 2024 masih diperbaiki pada bulan Juli (wilayah konflik); kabel EASSy dan Seacom yang putus pada bulan Mei pulih dalam 19 hari - [Q1 2024 Internet disruption summary](https://blog.cloudflare.com/q1-2024-internet-disruption-summary/) · Cloudflare · Kabel di Afrika Barat yang putus (14 Maret) pulih 3–6 minggu kemudian; selama itu trafik dipindahkan ke kabel lain #### isp-bgp · Perubahan rute dan konvergensi BGP · Route change / BGP convergence Saat informasi rute internet berubah, paket hilang selama beberapa detik hingga puluhan detik (dalam kasus yang jarang, sampai beberapa menit) sampai rute kembali konvergen. - Mengapa → Akibatnya → Di layar: Informasi rute di segmen salah satu ISP berubah → Selama beberapa detik hingga puluhan detik, paket hilang atau dialihkan ke rute baru → Tiba-tiba freeze beberapa detik, lalu angka ping berubah (misalnya 40 → 70 ms) - Gejala: Freeze, Teleport / Faktor: Packet loss, Latensi - Siapa: Wilayah/ISP tertentu / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Pakai timeout yang tahan terhadap putus singkat (jangan langsung memutus koneksi yang terhenti beberapa detik). - Tugas Tim Infrastruktur: Pantau rute (awasi perubahan rute dan ping untuk blok IP kami), deteksi gangguan jalur kami dalam 1 detik dengan BFD lalu alihkan (hold time default BGP 90–180 detik), pindahkan trafik ke jalur lain jika rute berubah ke rute yang jauh dan tidak kembali. - Tugas Pihak Eksternal: Untuk segmen ISP yang rutenya sering berubah, minta ISP terkait memeriksa penyebabnya. - Di grafik: Naik seperti anak tangga (RTT, rute traceroute) - Yang diperiksa: Bandingkan rute traceroute dan mtr sebelum dan sesudah RTT berubah, lalu periksa riwayat perubahan rute BGP untuk blok alamat (prefix) kami di RIPEstat BGPlay - Cocok jika: Bersamaan dengan koneksi yang terhenti beberapa detik, RTT pindah ke nilai lain, dan pada waktu yang sama ada update BGP dan perubahan AS path - Tidak cocok jika: Tidak ada riwayat perubahan rute, tetapi hanya naik pada malam hari: lebih mungkin “Kongesti di jalur peering saat jam sibuk”. Hanya sebagian koneksi yang buruk: lebih mungkin “Satu jalur ECMP bermasalah” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Kasus nyata: cloudflare-2020, meta-2021, cloudflare-dns-2025 - Sumber: - [RFC 4271: A Border Gateway Protocol 4 (BGP-4)](https://www.rfc-editor.org/rfc/rfc4271) · IETF · Nilai default hold time BGP yang disarankan 90 detik (jika tidak ada pesan dari peer selama waktu ini, sesi diputus) - [BGP updates in 2024](https://blog.apnic.net/2025/01/07/bgp-updates-in-2024/) · APNIC · Waktu sampai rute yang tidak stabil kembali stabil: rata-rata harian 25–35 detik (IPv4) dan 40–50 detik (IPv6) - [Delayed Internet Routing Convergence (SIGCOMM 2000)](https://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-5-2.pdf) · ACM · Setelah gangguan rute, konvergensi bisa memakan waktu sampai beberapa menit, dan selama itu packet loss serta latensi meningkat (pengukuran tahun 2000) - [BGPlay (RIPEstat Data API)](https://stat.ripe.net/docs/data-api/api-endpoints/bgplay) · RIPE NCC · Menampilkan rute BGP suatu blok alamat (prefix) pada awal periode, update BGP yang teramati selama periode itu, dan informasi AS di sepanjang rute #### isp-ecmp · Satu jalur ECMP bermasalah · ECMP / link bundle member fault ISP dan data center menyiapkan beberapa jalur ke tujuan yang sama dan menetapkan satu jalur untuk setiap koneksi. Jika hanya satu jalur yang rusak, hanya pemain yang mendapat jalur itu yang terus mengalami lag. - Mengapa → Akibatnya → Di layar: Di segmen yang menggabungkan beberapa jalur, satu jalur atau satu perangkat rusak atau padat → Jalur ditentukan dari kombinasi alamat dan port (hash), sehingga hanya koneksi yang mendapat jalur itu yang mengalami packet loss dan latensi → Di wilayah dan ISP yang sama, hanya sebagian pemain yang terus-menerus teleport. Kadang normal kembali setelah reconnect - Gejala: Teleport, Rubber banding, Patah-patah / Faktor: Packet loss, Jitter - Siapa: Hanya saya, Wilayah/ISP tertentu / Kapan: Selalu - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Catat statistik packet loss dan retransmisi per koneksi agar IP, port, dan waktu dari pemain yang mengalaminya bisa diambil (untuk TCP dari jumlah retransmisi di TCP_INFO, untuk UDP dihitung dari nomor urut paket yang hilang). - Tugas Tim Infrastruktur: Kumpulkan IP, port, dan waktu dari pemain yang mengalaminya lalu teruskan ke ISP atau data center, pantau packet loss per jalur, ukur rute dengan protokol dan port yang sama dengan game (mtr --tcp atau --udp dengan --port), keluarkan jalur atau perangkat yang rusak dari grup jika jalurnya ada di perangkat kami. - Tugas Pihak Eksternal: Minta ISP memeriksa dan mengganti jalur yang rusak, imbau pemain untuk reconnect sebagai solusi sementara (jika port berubah saat reconnect). - Kisaran angka: Jika ada 4 jalur, hanya sekitar seperempat pemain yang mengalaminya. Pengukuran ping bisa lewat jalur yang berbeda dari game, sehingga hasilnya terlihat normal. - Di grafik: Hanya sebagian yang tinggi (Packet loss dan retransmisi per koneksi (per IP dan port)) - Yang diperiksa: Pisahkan packet loss dan retransmisi per koneksi berdasarkan IP dan port asal, lalu ukur dengan mtr lewat UDP (-u) ke port game (-P) dengan port asal tetap (-L), dan ulangi beberapa kali dengan port asal berbeda. Jika hanya -P tanpa -L, port asal berubah di setiap permintaan sehingga beberapa jalur tercampur - Cocok jika: Di dalam wilayah dan ISP yang sama, hanya kombinasi port asal (atau alamat) tertentu yang terus mengalami packet loss, dan normal kembali setelah reconnect mengubah port - Tidak cocok jika: Semua tetap buruk walau port diganti: mengarah ke kongesti atau gangguan di satu segmen secara keseluruhan - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Agar urutan paket dalam satu koneksi tidak teracak, perangkat (ECMP, LAG) mengunci jalur untuk setiap koneksi berdasarkan nilai yang dihitung dari alamat dan port, atau hanya dari alamat tergantung konfigurasi perangkat. Di tempat yang hanya memakai alamat, reconnect tetap lewat jalur yang sama sehingga tidak membaik. Karena itu, jika laporan seperti “ping normal tetapi game lag” dan “setelah login ulang membaik” masuk bersamaan, curigai penyebab ini. - Sumber: - [RFC 7424: Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks](https://www.rfc-editor.org/rfc/rfc7424) · IETF · LAG dan ECMP menetapkan satu link untuk setiap flow berdasarkan hash field header agar urutan paket terjaga (pemetaan flow→link banyak-ke-satu) - [RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection](https://www.rfc-editor.org/rfc/rfc2991) · IETF · Kriteria pembeda flow berbeda per implementasi (hanya alamat tujuan, pasangan alamat, atau sampai port); pada multipath, hasil ping dan traceroute sulit dipercaya - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · Opsi -u (UDP), -P (port tujuan), -L (port asal UDP); jika hanya -P yang diberikan, nomor urut permintaan dimasukkan ke port asal sehingga port asal berubah di setiap permintaan #### isp-shaping · Pembatasan kecepatan dan manajemen trafik oleh ISP · Traffic shaping, data caps Jika kuota data terlampaui atau layanan internet mengelola trafik tertentu, paket ditunda atau dibuang. - Mengapa → Akibatnya → Di layar: Kecepatan dibatasi setelah kuota data habis, atau trafik tertentu dibatasi → Paket menunggu di antrean atau dibuang → Lag setelah pemakaian tertentu, terutama di seluler - Gejala: Input lag, Teleport / Faktor: Latensi, Packet loss - Siapa: Hanya saya, Wilayah/ISP tertentu / Kapan: Selalu, Jam sibuk malam hari - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Kurangi trafik game (kompresi, kirim hanya yang diperlukan). - Tugas Tim Infrastruktur: Jika trafik game ditunda atau dibuang hanya di ISP tertentu, kumpulkan data lalu eskalasikan ke ISP. - Tugas Pihak Eksternal: Imbau pemain untuk memeriksa apakah kuota datanya habis atau kecepatannya dibatasi dan apakah aplikasi lain di ponsel yang sama sedang dipakai, minta ISP memastikan apakah trafik game dibatasi. - Kisaran angka: Di Korea, paket data seluler yang kuotanya habis biasanya dibatasi ke 1–5 Mbps, dan paket yang murah ke ratusan kbps. Game memang ringan, tetapi jika aplikasi lain di ponsel yang sama memakai koneksi, antrean terbentuk di depan perangkat pembatas kecepatan. - Di grafik: Mendatar di batas (Throughput, RTT) - Yang diperiksa: Minta pemain memeriksa sisa kuota dan status pembatasan kecepatan di aplikasi ISP, lalu ukur kecepatan maksimum dengan tes kecepatan. Di sisi server, bandingkan packet loss dan RTT per ISP - Cocok jika: Throughput tidak naik melewati satu nilai seperti 1–5 Mbps atau ratusan kbps, dan sejak itu RTT dan packet loss bertambah saat aplikasi lain di ponsel yang sama memakai koneksi. Hilang setelah kuota diisi ulang atau setelah pindah ke Wi-Fi - Tidak cocok jika: Tidak ada pembatasan kecepatan, tetapi hanya ISP tertentu yang buruk: lebih mungkin “Kongesti di jalur peering saat jam sibuk” atau “Routing memutar” - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [SKT, 고객 선택권과 혜택 강화한 신규 5G 요금제 출시](https://news.sktelecom.com/180213) · SK텔레콤 · Contoh kontrol kecepatan setelah kuota dasar paket data 5G habis: maksimal 400 kbps, 1 Mbps, 3 Mbps - [SKT, 요금제 개편](https://news.sktelecom.com/225487) · SK텔레콤 · Setelah kuota dasar habis, internet tetap bisa dipakai dengan kecepatan maksimal 400 kbps (program “data aman untuk seluruh warga”) #### isp-udp-block · Pembatasan UDP dan inspeksi paket per negara atau ISP · UDP blocking, throttling and inspection by networks Sebagian jaringan memblokir alamat dan port UDP tertentu atau membatasi kecepatan UDP, dan perangkat inspeksi paket menyaring protokol yang tidak dikenalinya. Game yang berkomunikasi lewat UDP tidak bisa tersambung atau sering terputus di jaringan itu. - Mengapa → Akibatnya → Di layar: Terhubung dari jaringan ISP yang membatasi kecepatan UDP, atau dari jaringan yang memiliki perangkat inspeksi trafik (sensor) di tingkat negara atau ISP → Memblokir alamat dan port UDP tertentu, membatasi kecepatan UDP pada jam ramai, menyaring port dan protokol yang tidak ada di allowlist, atau hanya meloloskan beberapa paket pertama lalu memblokir → Hanya pemain dari negara atau ISP tertentu yang tidak bisa masuk atau mengalami loading tanpa henti, disconnect tak lama setelah tersambung, atau teleport karena packet loss pada jam ramai - Gejala: Tidak bisa masuk / loading tanpa henti, Disconnect, Teleport / Faktor: Packet loss - Siapa: Wilayah/ISP tertentu / Kapan: Tepat setelah login atau maintenance, Selalu, Jam sibuk malam hari - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Klien: beralih otomatis ke rute cadangan TCP/TLS 443 jika UDP tidak tersambung dalam beberapa detik, deteksi juga kasus yang awalnya tersambung lalu segera putus dan coba lagi lewat rute cadangan, catat di log rute mana yang dipakai. Server: terima protokol game yang sama juga lewat TCP 443 (TLS), sesuaikan timeout karena rute cadangan bisa menambah latensi. - Tugas Tim Infrastruktur: Sebelum membuka layanan di negara baru, ukur apakah UDP bisa sampai dan seberapa besar packet loss pada jam sibuk di jaringan ISP setempat, tempatkan relay atau gateway yang menerima rute cadangan TCP 443 di dekat negara itu, pantau tingkat keberhasilan koneksi UDP dan TCP per negara dan ASN, kumpulkan data lalu eskalasikan untuk ISP yang terbukti membatasi kecepatan UDP. - Tugas Pihak Eksternal: Tanyakan kriteria pembatasan UDP dan kemungkinan pelonggarannya ke ISP atau lembaga terkait, imbau pemain untuk mencoba tersambung dari jaringan lain sebagai pembanding. - Kisaran angka: Menurut pengukuran yang dikutip dokumen IETF, 3–5% jaringan memblokir semua UDP. Pada 2016 Google meninjau hasil pemakaian QUIC (berbasis UDP) dan mendapati 4,4% klien tidak bisa memakainya karena UDP atau QUIC diblokir atau path MTU terlalu kecil. Sebagian besar klien itu berada di balik firewall perusahaan, dan tidak ditemukan kasus pemblokiran oleh seluruh jaringan satu ISP. Lalu 0,3% klien berada di jaringan yang tampaknya membatasi kecepatan UDP karena packet loss melonjak pada jam sibuk; angka ini turun dari 1% pada 2015 setelah Google meminta ISP terkait. - Di grafik: Hanya sebagian yang tinggi (Tingkat keberhasilan koneksi UDP (per negara dan ASN)) - Yang diperiksa: Pisahkan tingkat keberhasilan koneksi UDP dan tingkat keberhasilan rute cadangan TCP 443 per negara dan ASN. Uji koneksi ke port UDP game dan ke TCP 443 masing-masing dari VM cloud atau PC pemain di jaringan ISP itu, lalu bandingkan dengan mtr -u -P (port game) dan mtr -T -P 443 untuk melihat dari segmen mana respons hilang - Cocok jika: Hanya di negara atau ASN tertentu, respons pertama UDP tidak datang atau koneksi putus dalam beberapa detik, sedangkan TCP 443 dari tempat yang sama normal. Jika berupa pembatasan kecepatan, packet loss UDP jelas bertambah hanya pada jam sibuk dan TCP tidak banyak terpengaruh - Tidak cocok jika: TCP juga gagal: mengarah ke gangguan rute, pemblokiran IP, atau “Gangguan dan latensi DNS”. Sama di semua negara: mengarah ke konfigurasi server atau firewall kami. Packet loss hanya muncul saat volume kirim sesaat besar, baik UDP maupun TCP: lebih mungkin “Policer membuang trafik berlebih” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Perangkat inspeksi paket bisa memilih flow UDP berdasarkan alamat, port, dan protokol lalu memblokirnya, atau memakai allowlist, yaitu memblokir semua protokol selain yang diizinkan (menurut dokumen survei IRTF). Jika perangkat menilai hanya dari sebagian field paket, perubahan kecil pada protokol saja bisa membuatnya diblokir. Pada masa awal QUIC, sebuah firewall meloloskan beberapa paket pertama setelah 1 bit di header berubah lalu memblokir paket sesudahnya, sehingga logika klien untuk beralih ke TCP tidak berjalan. Saat membuka layanan di negara baru, masalah ini bisa muncul lewat laporan seperti “di Korea normal, tetapi hanya sebagian ISP di negara itu yang tidak bisa tersambung”. Jika pemblokiran hanya terjadi di jaringan satu tempat seperti kafe atau kantor, lihat entri “Pembatasan di Wi-Fi publik dan jaringan kantor”. - Sumber: - [RFC 9308: Applicability of the QUIC Transport Protocol](https://www.rfc-editor.org/rfc/rfc9308) · IETF · Menurut studi pengukuran, 3–5% jaringan memblokir semua UDP sehingga aplikasi berbasis UDP harus menerima kegagalan koneksi atau menyiapkan rute cadangan TCP (TLS); port yang tidak terkait layanan terdaftar bisa diblokir firewall - [The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46403.pdf) · ACM · 2016: 4,4% klien tidak bisa memakai QUIC berbasis UDP (UDP atau QUIC diblokir, atau path MTU kecil; umumnya di balik firewall perusahaan; pemblokiran oleh seluruh jaringan ISP tidak teramati); 0,3% berada di jaringan yang tampaknya membatasi kecepatan UDP (packet loss naik pada jam sibuk; turun dari 1% pada 2015 setelah meminta ISP); ada kasus firewall yang hanya meloloskan beberapa paket pertama setelah 1 bit header berubah lalu memblokir sisanya sehingga logika cadangan TCP tidak berfungsi - [RFC 9505: A Survey of Worldwide Censorship Techniques](https://www.rfc-editor.org/rfc/rfc9505) · IRTF · Perangkat inspeksi di jaringan bisa memilih flow TCP dan UDP berdasarkan alamat, port, dan protokol lalu memblokirnya (pemblokiran endpoint UDP teramati pada QUIC); cara yang memblokir semua protokol selain yang diizinkan menyebabkan pemblokiran berlebihan; pembatasan kecepatan trafik tertentu juga dipakai - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · Mengukur rute dengan protokol dan port yang sama dengan game: -u mengirim UDP, -T mengirim TCP SYN, dan -P menentukan port tujuan #### isp-line · Kualitas koneksi buruk · Faulty last-mile line / modem Konektor yang kontaknya buruk, kabel yang sudah tua, atau modem yang bermasalah menimbulkan packet loss terus-menerus dan koneksi yang putus secara berkala. - Mengapa → Akibatnya → Di layar: Kabel rusak, kontak buruk, modem atau ONT bermasalah → Paket dibuang karena bit error; sesekali koneksi terputus beberapa detik hingga sekitar 1 menit karena sedang tersambung ulang → Packet loss kecil yang terus-menerus, sesekali freeze beberapa detik atau disconnect - Gejala: Teleport, Freeze, Disconnect / Faktor: Packet loss - Siapa: Satu rumah / Kapan: Sesekali secara acak - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) - Tugas Pihak Eksternal: Imbau pemain untuk memeriksa apakah game lain dan panggilan video juga terputus, dan jika ya, meminta ISP memeriksa koneksinya. - Di grafik: Melonjak acak sesekali (Tingkat packet loss, riwayat koneksi ulang) - Yang diperiksa: Ukur packet loss sampai hop pertama ISP selama beberapa menit dengan pathping (atau mtr), lalu periksa waktu koneksi ulang di riwayat koneksi internet (WAN) di halaman admin router - Cocok jika: Packet loss terus muncul mulai dari hop pertama ISP walau koneksi sedang sepi, dan waktu koneksi ulang di log router bertepatan dengan waktu freeze atau disconnect. Game lain dan panggilan video juga ikut terputus - Tidak cocok jika: Packet loss mulai di jalur nirkabel ke router: lebih mungkin “Interferensi Wi-Fi dan sinyal lemah”. Mulai di hop ISP yang jauh: mengarah ke rute ISP - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types](https://www.rfc-editor.org/rfc/rfc3635) · IETF · Frame yang tidak lolos pemeriksaan frame (FCS) dihitung sebagai error FCS (dot3StatsFCSErrors) dan dijumlahkan ke error input (ifInErrors) - [Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017)](https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/CorrOpt_SIGCOMM2017.pdf) · ACM · Penyebab utama paket rusak adalah modul optik rusak, serat optik rusak, konektor kotor, dan pemasangan yang salah; tingkat packet loss akibat kerusakan tetap stabil tanpa kaitan dengan pemakaian - [pathping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping) · Microsoft · Mengirim ping ke setiap hop selama waktu tertentu dan menghitung tingkat packet loss per router dan link untuk menunjukkan di segmen mana packet loss terjadi #### isp-dns · Gangguan dan latensi DNS · DNS failure / slowness Jika DNS, yang menerjemahkan nama server menjadi alamat, lambat atau gagal, server login dan server patch tidak bisa ditemukan. - Mengapa → Akibatnya → Di layar: DNS ISP mengalami gangguan atau salah konfigurasi → Alamat server login dan server patch tidak ditemukan → Menunggu lama setelah menekan tombol masuk, atau tidak bisa masuk. Pemain yang sudah tersambung tetap normal - Gejala: Tidak bisa masuk / loading tanpa henti / Faktor: Latensi, Packet loss - Siapa: Wilayah/ISP tertentu, Hanya saya / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Simpan cache alamat (ingat alamat server terakhir yang berhasil dipakai untuk login), siapkan beberapa DNS (jika satu gagal, lakukan lookup ulang ke DNS lain). - Tugas Pihak Eksternal: Imbau pemain untuk mencoba mengganti DNS, misalnya ke DNS publik. - Di grafik: Hanya sebagian yang tinggi (Jumlah login gagal (per ISP), waktu lookup DNS) - Yang diperiksa: Tanyakan nama server login ke DNS ISP dan ke DNS publik masing-masing dengan Resolve-DnsName -Server (atau nslookup), lalu bandingkan waktu respons dan hasilnya - Cocok jika: Hanya DNS ISP yang tidak merespons atau lama merespons, dan begitu diganti ke DNS publik langsung bisa masuk. Pemain yang sudah tersambung tetap normal - Tidak cocok jika: Alamat langsung didapat dari DNS mana pun, tetapi tetap tidak bisa masuk: mengarah ke rute, firewall, atau server - Sarana pemeriksaan: Lingkungan pemain sendiri - Kasus nyata: meta-2021, cloudflare-dns-2025, aws-2025 - Sumber: - [Cloudflare 1.1.1.1 Incident on July 14, 2025](https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/) · Cloudflare · Saat resolver DNS publik berhenti selama 62 menit, pengguna yang tidak bisa me-resolve nama praktis tidak bisa memakai layanan internet apa pun - [RFC 8767: Serving Stale Data to Improve DNS Resiliency](https://www.rfc-editor.org/rfc/rfc8767) · IETF · Cara bertahan saat gangguan dengan terus memakai record cache yang sudah kedaluwarsa ketika server otoritatif tidak bisa dijangkau (serve-stale) - [Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) · Microsoft · Menentukan server DNS yang ditanya dengan -Server, lalu me-lookup nama - [nslookup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup) · Microsoft · Perintah untuk me-lookup nama langsung ke server DNS #### isp-ddos-path · Jalur bersama penuh akibat DDoS · DDoS saturating shared links Serangan besar yang ditujukan ke perusahaan game atau ke pihak lain di jaringan yang sama memenuhi jalur bersama. - Mengapa → Akibatnya → Di layar: Muncul trafik serangan dalam jumlah besar → Trafik normal yang memakai jalur yang sama ikut tertahan dan dibuang → Banyak pemain sekaligus mengalami teleport, disconnect, atau tidak bisa masuk - Gejala: Teleport, Disconnect, Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss, Latensi - Siapa: Seluruh server, Wilayah/ISP tertentu / Kapan: Sesekali secara acak, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Infrastruktur: Pakai layanan proteksi DDoS, alihkan trafik saat terjadi serangan, sembunyikan alamat server (tempatkan di belakang perangkat proteksi agar alamat aslinya tidak terekspos). - Tugas Pihak Eksternal: Jika serangannya ditujukan ke pihak lain di jaringan yang sama, minta ISP memblokirnya di segmen upstream. - Di grafik: Mendatar di batas (Volume terima jalur (bps, pps), drop di interface) - Yang diperiksa: Periksa volume terima di interface jalur dan perangkat kami, jumlah paket yang dibuang, dan log deteksi serangan dari layanan proteksi DDoS, bersama waktu ketika disconnect menumpuk - Cocok jika: Volume terima jalur menempel di kapasitas jalur dan mendatar, drop bertambah, dan pada waktu yang sama pemain dari banyak wilayah dan ISP sekaligus mengalami teleport atau disconnect - Tidak cocok jika: Jalur masih longgar, tetapi hanya sebagian ISP yang buruk: mengarah ke kongesti atau masalah rute di segmen ISP - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Infrastructure layer attacks](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/infrastructure-layer-attacks.html) · AWS · Serangan besar seperti UDP reflection dan SYN flood membuat kapasitas jaringan meluap atau menghabiskan sumber daya firewall dan load balancer - [Obfuscating AWS resources (BP1, BP4, BP5)](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/obfuscating-aws-resources-bp1-bp4-bp5.html) · AWS · Tempatkan layanan edge seperti CloudFront atau load balancer di depan server origin untuk mengurangi paparan langsung - [RFC 7999: BLACKHOLE Community](https://www.rfc-editor.org/rfc/rfc7999) · IETF · BLACKHOLE community, yaitu pengumuman lewat BGP yang meminta ISP tetangga membuang trafik ke alamat tertentu #### isp-cgnat · IP bersama dari ISP (CGNAT) · Carrier-grade NAT Jaringan seluler dan sebagian ISP membuat banyak pelanggan berbagi satu IP, dan mapping koneksi idle dihapus dalam waktu singkat. - Mengapa → Akibatnya → Di layar: Perangkat ISP mengelola tabel sesi untuk banyak sekali pelanggan → Batas tabel sesi, idle timeout yang pendek → Disconnect setelah lama diam, false positive yang memblokir sekaligus semua orang yang memakai IP yang sama - Gejala: Disconnect, Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Wilayah/ISP tertentu / Kapan: Setelah lama diam - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek, yang di jaringan seluler bisa sekitar 30 detik (mapping CGNAT ISP hanya diperbarui dengan pasti oleh paket yang keluar dari dalam, jadi klien yang mengirim), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, lanjutkan sesi pemain yang sama lewat token sesi walau mapping berubah dan alamat serta port berbeda, terapkan kebijakan pemblokiran berbasis IP dengan hati-hati karena satu IP bisa dipakai banyak orang (nilai bersama kriteria akun dan perangkat). - Tugas Tim Infrastruktur: Sesuaikan batas jumlah koneksi per IP dan jumlah koneksi baru per detik di firewall dan perangkat proteksi DDoS dengan IP bersama dari ISP (naikkan ambang atau beri pengecualian untuk blok alamat operator seluler). - Kisaran angka: Idle timeout UDP di jaringan seluler ada yang hanya sekitar 30 detik. - Di grafik: Koneksi putus serentak (Jumlah disconnect (timeout heartbeat), waktu idle sebelum terputus (per ISP)) - Yang diperiksa: Periksa jumlah akun yang tersambung bersamaan dari satu IP dan ISP-nya (ASN) di log koneksi, lalu kumpulkan waktu idle koneksi yang terputus setelah idle per ISP. Di sisi pemain, periksa alamat internet (WAN) di halaman admin router - Cocok jika: Di blok alamat operator seluler, banyak akun tersambung dari satu IP, dan waktu idle sebelum terputus terkumpul pendek di sekitar 30–60 detik. Alamat WAN router berada di 100.64.0.0/10 (alamat bersama untuk NAT ISP) atau berbeda dari alamat yang dilihat server - Tidak cocok jika: Terkumpul pada pengguna router rumahan tanpa kaitan dengan ISP: lebih mungkin “Mapping NAT kedaluwarsa” - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [A Multi-perspective Analysis of Carrier-Grade NAT Deployment (IMC 2016)](https://www.icir.org/vern/papers/cgn-imc16.pdf) · ACM · Waktu bertahan mapping UDP pada NAT yang diukur 10–200 detik, 74% maksimal 1 menit; median CGN 65 detik di jaringan seluler dan 35 detik di jaringan kabel - [RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs)](https://www.rfc-editor.org/rfc/rfc6888) · IETF · CGN harus mendukung pembatasan jumlah port eksternal per pelanggan dan pembatasan laju pembuatan mapping baru - [RFC 6269: Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) · IETF · Jika satu alamat dipakai bersama, pemblokiran berbasis IP (penalty box) juga memblokir pelanggan lain di alamat yang sama - [RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space](https://www.rfc-editor.org/rfc/rfc6598) · IETF · 100.64.0.0/10 adalah blok alamat bersama yang dipakai antara perangkat NAT ISP (CGN) dan router pelanggan #### isp-vpn · Rute lewat VPN atau game booster · VPN / game accelerator detour Jika VPN atau game booster diaktifkan, paket melewati server relay milik perusahaan itu. Jika server relay jauh atau padat, koneksi malah menjadi lebih lambat. - Mengapa → Akibatnya → Di layar: VPN atau game booster mengalihkan semua paket game ke server relay → Jarak dan kongesti sampai server relay ikut bertambah, dan header tunnel juga mengurangi MTU (ukuran paket yang bisa dikirim sekaligus) → Ping naik dan packet loss, atau tidak bisa masuk karena ikut diblokir bersama orang lain yang memakai alamat relay yang sama - Gejala: Input lag, Teleport, Tidak bisa masuk / loading tanpa henti / Faktor: Latensi, Packet loss - Siapa: Hanya saya / Kapan: Selalu, Tepat setelah login atau maintenance - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Infrastruktur jaringan (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Jaga paket UDP maksimal 1.200 byte (agar tidak terfragmentasi walau MTU berkurang karena header tunnel), nilai pemblokiran berbasis IP bersama kriteria akun dan perangkat dengan memperhitungkan alamat relay bersama milik VPN dan game booster. - Tugas Tim Infrastruktur: Jika banyak pemain dari luar negeri, tempatkan sendiri titik akses di dekat mereka, periksa rute ISP yang pelanggannya banyak melaporkan “setelah game booster dinyalakan jadi lebih baik”. - Tugas Pihak Eksternal: Imbau pemain untuk mematikan VPN atau game booster lalu membandingkan hasilnya. - Kisaran angka: Jika server relay dekat, tambahannya beberapa ms; jika memutar lewat negara lain, tambahannya puluhan ms hingga lebih dari 100 ms. - Di grafik: Hanya sebagian yang tinggi (RTT (per pemain), penyedia IP pemain) - Yang diperiksa: Periksa apakah ASN dari IP pemain milik penyedia VPN, game booster, atau hosting, lalu minta pemain mematikan VPN atau game booster dan membandingkan ping serta traceroute - Cocok jika: RTT dan packet loss bertambah atau koneksi diblokir hanya saat VPN atau game booster aktif, dan traceroute menunjukkan segmen yang melewati server relay - Tidak cocok jika: Sama saja saat dimatikan atau dinyalakan: mengarah ke koneksi atau segmen ISP. Lebih baik saat dinyalakan: masalahnya ada di rute ISP asli (“Routing memutar”, “Kongesti di jalur peering saat jam sibuk”) - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Sebaliknya, saat rute ISP buruk, game booster bisa memutar lewat rute yang lebih baik sehingga ping turun. Laporan “setelah game booster dinyalakan jadi lebih baik” adalah petunjuk adanya masalah rute ISP, seperti routing memutar atau kongesti malam hari. - Sumber: - [RFC 4459: MTU and Fragmentation Issues with In-the-Network Tunneling](https://www.rfc-editor.org/rfc/rfc4459) · IETF · Masalah fragmentasi dan path MTU yang muncul karena header enkapsulasi dari tunnel di tengah jaringan mengurangi ukuran yang bisa dikirim - [RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports](https://www.rfc-editor.org/rfc/rfc8899) · IETF · 1.200 byte disarankan sebagai ukuran aman dasar (BASE_PLPMTU) untuk transport datagram seperti UDP - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Besarnya latensi pulang-pergi yang bertambah saat lewat titik akses di negara lain: Seoul–Tokyo 30 ms, Seoul–Hong Kong 39 ms, Seoul–Singapura 68 ms ### L5 Perangkat jaringan data center (11 penyebab) #### dc-firewall · Tabel sesi firewall penuh · Firewall session table exhaustion Firewall mencatat dan melacak setiap koneksi yang diloloskannya di tabel sesi. Jika tabelnya penuh, koneksi baru tidak bisa diterima. - Mengapa → Akibatnya → Di layar: Jumlah sesi mencapai batas karena lonjakan koneksi atau serangan → Koneksi baru ditolak karena tidak ada entri kosong untuk mencatatnya → Pemain yang baru mau masuk tidak bisa masuk atau mengalami loading tanpa henti, dan sebagian koneksi yang sudah ada juga disconnect - Gejala: Tidak bisa masuk / loading tanpa henti, Disconnect / Faktor: Packet loss - Siapa: Seluruh server / Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: atur lonjakan koneksi dengan sistem antrean login, pakai ulang koneksi agar tidak berulang kali membuka koneksi singkat, bersihkan lebih dulu koneksi yang heartbeat-nya berhenti (agar koneksi mati tidak lama memakai tabel sesi). Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek, reconnect otomatis jika terputus dengan interval percobaan ulang yang makin panjang dan disebar secara acak (agar tidak menyerbu bersamaan lagi). - Tugas Tim Infrastruktur: Perbesar tabel sesi, bersihkan cepat koneksi yang berakhir singkat (perpendek timeout sesi yang sudah ditutup), beri tahu Tim Pengembang Game nilai idle timeout sesi saat memperpendeknya agar interval heartbeat disesuaikan, blokir serangan, pasang alert utilisasi jumlah sesi. - Di grafik: Mendatar di batas (Jumlah sesi firewall, jumlah koneksi baru yang gagal) - Yang diperiksa: Lihat grafik jumlah sesi bersamaan di perangkat firewall bersama batas sesinya, lalu cari log paket yang dibuang karena sesi tidak bisa dibuat. Untuk firewall Linux, bandingkan nf_conntrack_count dengan nf_conntrack_max dan cari “nf_conntrack: table full, dropping packet” di dmesg; untuk instance AWS, periksa conntrack_allowance_exceeded di ethtool -S - Cocok jika: Sejak jumlah sesi mendatar di batas, koneksi baru yang gagal bertambah, dan log kegagalan pembuatan sesi atau counter drop ikut naik - Tidak cocok jika: Jumlah sesi masih jauh di bawah batas, tetapi tetap tidak bisa masuk: lebih mungkin “Antrean koneksi (backlog) meluap” atau server login. Hanya koneksi idle yang terputus: lebih mungkin “Connection tracking di security group cloud kedaluwarsa” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Jumlah entri maksimum tabel connection tracking (nf_conntrack_max), lama penyimpanan koneksi yang sedang ditutup (TIME_WAIT dan FIN_WAIT default 120 detik), TCP yang sudah terbentuk default 5 hari, jumlah entri saat ini (nf_conntrack_count) - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Jika jumlah koneksi yang bisa dilacak per instance terlampaui, paket koneksi baru dibuang; koneksi idle bisa menghabiskan tabel pelacakan - [Infrastructure layer attacks](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/infrastructure-layer-attacks.html) · AWS · Serangan seperti SYN flood menghabiskan sumber daya server, firewall, dan load balancer - [net/netfilter/nf_conntrack_core.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_core.c?h=v6.12) · Linux kernel · Jika tabel connection tracking penuh, kernel mencatat “nf_conntrack: table full, dropping packet” dan membuang paket koneksi baru - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · conntrack_allowance_exceeded: jumlah paket yang dibuang karena melewati batas connection tracking instance, diperiksa dengan ethtool -S #### dc-ddos · Rute lewat proteksi DDoS dan false positive · DDoS scrubbing latency, false positives Saat trafik dialihkan ke scrubbing center untuk menangkal serangan, rutenya menjadi lebih panjang, dan pemain yang normal kadang salah dikira serangan lalu diblokir. - Mengapa → Akibatnya → Di layar: Setelah serangan terdeteksi (atau terus-menerus), trafik masuk dialihkan ke scrubbing center → Rute bertambah panjang, dan sebagian paket normal dinilai sebagai serangan → Ping semua pemain naik, hanya wilayah atau ISP tertentu yang tidak bisa masuk - Gejala: Input lag, Tidak bisa masuk / loading tanpa henti, Teleport / Faktor: Latensi, Packet loss - Siapa: Seluruh server, Wilayah/ISP tertentu / Kapan: Saat banyak pemain berkumpul, Sesekali secara acak - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Rangkum pola trafik game (port, ukuran paket, jumlah paket per detik) lalu bagikan ke Tim Infrastruktur, jaga paket UDP maksimal 1.200 byte. - Tugas Tim Infrastruktur: Buat aturan proteksi yang sesuai dengan pola trafik game, siapkan lokasi scrubbing per region, perkecil ukuran paket TCP di segmen tunnel (penyesuaian MSS), periksa false positive dari tingkat kegagalan koneksi per wilayah dan ISP. - Kisaran angka: Jika lokasi scrubbing ada di negara yang sama, tambahannya beberapa ms; jika lewat lokasi di negara lain, tambahannya 30 ms hingga lebih dari 100 ms. Biasanya hanya trafik masuk yang memutar, sedangkan respons server langsung keluar. Jika trafik yang sudah disaring dikembalikan lewat tunnel, ukuran yang bisa dikirim sekaligus (MTU) juga berkurang dan bisa berujung pada masalah hanya paket besar yang hilang. - Di grafik: Naik seperti anak tangga (RTT (ping), tingkat kegagalan koneksi per wilayah dan ISP) - Yang diperiksa: Letakkan log mulai dan selesainya pengalihan (scrubbing) serta log pemblokiran dari perangkat atau layanan proteksi pada sumbu waktu yang sama dengan grafik RTT dan tingkat kegagalan koneksi per wilayah dan ISP. Dari wilayah yang bermasalah, pastikan dengan mtr atau traceroute apakah lokasi scrubbing ada di rute - Cocok jika: Saat pengalihan aktif, RTT naik satu tingkat dan bertahan, lalu kembali setelah pengalihan dimatikan. Atau alamat pemain normal muncul di log pemblokiran dan hanya wilayah atau ISP itu yang tingkat kegagalan koneksinya naik - Tidak cocok jika: RTT naik pada saat tidak ada log pengalihan atau pemblokiran: lebih mungkin “Routing memutar” atau “Perubahan rute dan konvergensi BGP”. Hanya paket besar yang hilang: lebih mungkin “MTU tidak cocok (hanya paket besar yang hilang)” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Maximum transmission unit and maximum segment size](https://developers.cloudflare.com/magic-transit/reference/mtu-mss/) · Cloudflare · Trafik masuk diteruskan lewat tunnel GRE (MTU 1.476) setelah disaring, respons keluar langsung ke internet (DSR); disarankan membatasi TCP MSS maksimal 1.436, dan jika tidak disesuaikan, paket besar dibuang atau terfragmentasi - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Besarnya latensi pulang-pergi menurut lokasi: Seoul–wilayah Busan 8 ms, Seoul–Tokyo 30 ms, Seoul–Singapura 68 ms #### dc-lb-idle · Idle timeout load balancer · Load balancer idle timeout Load balancer menghapus koneksi idle setelah waktu tertentu. Game masih menganggap koneksinya tersambung, lalu pemain disconnect. - Mengapa → Akibatnya → Di layar: Pemain tidak mengirim paket apa pun selama beberapa waktu (membuka jendela dialog, AFK) → Load balancer membersihkan koneksi idle (nilai default umum 60–350 detik) → Disconnect tepat saat pemain mulai bergerak lagi - Gejala: Disconnect / Faktor: Packet loss - Siapa: Hanya saya, Seluruh server / Kapan: Setelah lama diam - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (jika ALB 60 detik, maksimal 30 detik), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, lanjutkan sesi lewat token sesi. - Tugas Tim Infrastruktur: Periksa nilai idle timeout load balancer di sepanjang rute lalu bagikan ke Tim Pengembang Game, dan perpanjang jika perlu. - Kisaran angka: Nilai default AWS ALB 60 detik, NLB 350 detik untuk TCP dan 120 detik untuk UDP, dan Azure Load Balancer 4 menit untuk TCP. Nilai TCP pada ALB dan NLB bisa diubah, tetapi nilai UDP 120 detik pada NLB tidak bisa diubah. Saat waktunya habis, ALB juga menutup koneksi ke server, sedangkan NLB menghapusnya diam-diam sehingga server sering tidak tahu. - Di grafik: Koneksi putus serentak (Jumlah disconnect, waktu idle sebelum terputus) - Yang diperiksa: Periksa nilai konfigurasi idle timeout load balancer di sepanjang rute, lalu kumpulkan waktu dari paket terakhir sampai terputus untuk setiap koneksi yang terputus. Untuk AWS NLB, periksa juga TCP_ELB_Reset_Count (jumlah RST yang dikirim load balancer) di CloudWatch - Cocok jika: Waktu idle koneksi yang terputus terkumpul tepat setelah nilai konfigurasi (ALB 60 detik, NLB TCP 350 detik, dan sebagainya), dan masalah muncul lagi jika pemain diam lebih lama dari itu lalu bergerak. Pada NLB, TCP_ELB_Reset_Count naik pada saat itu - Tidak cocok jika: Terputus tanpa kaitan dengan waktu idle: bukan penyebab ini. Terkumpul di sekitar 350 detik pada server yang tersambung langsung tanpa load balancer: lebih mungkin “Connection tracking di security group cloud kedaluwarsa”. Terjadi di router rumah pemain: lebih mungkin “Mapping NAT kedaluwarsa” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Edit attributes for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-load-balancer-attributes.html) · AWS · Idle timeout ALB default 60 detik (1–4.000 detik); jika koneksi klien dan target diam selama waktu ini, load balancer menutup koneksi - [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) · AWS · Idle TCP NLB default 350 detik (60–6.000 detik); setelah lewat, NLB hanya berhenti melacak, dan data yang datang sesudahnya dibalas RST; flow UDP 120 detik tidak bisa diubah - [Configure load balancer TCP reset and idle timeout](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout) · Microsoft Azure · Idle timeout Azure Load Balancer default 4 menit (4–100 menit); jika terlampaui, sesi tidak dijamin tetap ada; TCP reset adalah pengaturan opsional - [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) · AWS · TCP_ELB_Reset_Count: jumlah paket RST yang dibuat dan dikirim load balancer #### dc-cloud-conntrack · Connection tracking di security group cloud kedaluwarsa · Cloud security group connection tracking timeout Firewall yang terpasang di server cloud (security group) juga melacak koneksi, dan entri pelacakan untuk koneksi idle kedaluwarsa setelah waktu tertentu. Server yang tersambung langsung tanpa load balancer pun bisa membuat pemain yang lama diam terputus. - Mengapa → Akibatnya → Di layar: Konfigurasi yang membuat security group melacak koneksi game (hanya mengizinkan alamat tertentu, membatasi aturan outbound, lewat NLB, dan sebagainya) → Entri pelacakan untuk koneksi yang idle cukup lama kedaluwarsa, lalu security group membuang diam-diam paket yang datang sesudahnya → Setelah AFK, pemain bergerak lagi tetapi tidak ada respons, lalu disconnect. Program server baru menyadarinya lama kemudian - Gejala: Disconnect / Faktor: Packet loss - Siapa: Hanya saya, Seluruh server / Kapan: Setelah lama diam - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (jika TCP 350 detik, maksimal 175 detik; jika UDP stream 180 detik, maksimal 90 detik), reconnect otomatis jika terputus. Server: balas heartbeat, bersihkan koneksi lebih dulu jika tidak menerima heartbeat dalam waktu tertentu, lanjutkan sesi lewat token sesi. - Tugas Tim Infrastruktur: Periksa waktu connection tracking instance (TcpEstablishedTimeout) dan perpanjang jika perlu (UDP tidak bisa diperpanjang karena maksimal 180 detik), tinjau konfigurasi security group yang tidak memicu pelacakan (izinkan semua alamat untuk port game, izinkan semua trafik outbound; koneksi lewat NLB tetap dilacak), jalankan uji koneksi idle saat pindah ke generasi instance yang baru. - Kisaran angka: Di AWS, tipe instance Nitro v6 menghapus entri pelacakan koneksi TCP idle setelah 350 detik secara default (tipe lain 5 hari). Untuk UDP, defaultnya 180 detik untuk flow yang request dan response-nya bolak-balik beberapa kali (stream), dan 30 detik untuk flow yang hanya satu arah atau hanya satu kali request dan response. - Di grafik: Koneksi putus serentak (Jumlah disconnect, waktu idle sebelum terputus) - Yang diperiksa: Periksa konfigurasi waktu connection tracking instance dan aturan security group (apakah konfigurasinya memicu pelacakan), lalu kumpulkan waktu idle koneksi yang terputus. Segera setelah terputus, jalankan ss -tnoi di server dan periksa apakah koneksi itu masih ESTABLISHED dengan timer retransmisi (timer:(on,…)) berjalan dan backoff yang terus membesar - Cocok jika: Waktu idle koneksi yang terputus terkumpul tepat setelah 350 detik untuk TCP, 180 detik untuk UDP stream, dan 30 detik untuk UDP satu arah, dan socket di sisi server tetap ESTABLISHED tanpa mendeteksi putusnya koneksi (jika server punya data untuk dikirim, ia hanya terus mengirim ulang) - Tidak cocok jika: Konfigurasi security group tidak memicu pelacakan (port game diizinkan untuk semua alamat, aturan outbound mengizinkan semua, tidak lewat NLB): bukan penyebab ini. Jika lewat NLB, bandingkan nilainya dengan “Idle timeout load balancer” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Pelacakan TCP idle default 350 detik (Nitro v6; tipe lain 432.000 detik = 5 hari), UDP satu arah 30 detik dan stream 180 detik (maksimal 180); tidak dilacak jika aturannya mengizinkan semua alamat; koneksi lewat NLB selalu dilacak - [Update the TCP idle timeout for your Network Load Balancer listener](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/update-idle-timeout.html) · AWS · Jika idle timeout NLB lebih panjang daripada waktu connection tracking instance target, sisi instance lebih dulu membuang status koneksi secara diam-diam - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · timer:(on,…) pada -o adalah timer retransmisi, dan backoff pada -i adalah berapa kali waktu tunggu retransmisi digandakan #### dc-nat-gateway · Batas koneksi dan port NAT gateway cloud · Cloud NAT gateway connection / port limits Koneksi dari server di subnet privat ke luar (autentikasi platform, pembayaran, API eksternal) dikirim keluar oleh NAT gateway setelah alamat dan portnya diganti. Jika koneksi bersamaan ke tujuan yang sama melebihi batas port gateway, koneksi baru gagal. - Mengapa → Akibatnya → Di layar: Server-server membuka banyak koneksi singkat ke alamat eksternal yang sama, seperti autentikasi platform atau pembayaran, atau membiarkan koneksi terbuka lama → NAT gateway tidak bisa lagi mengalokasikan port sumber untuk tujuan itu sehingga koneksi baru gagal → Di dalam game normal, tetapi hanya fitur yang memanggil layanan eksternal seperti login, pembayaran, dan pemberian hadiah yang gagal atau lambat (tidak bisa masuk / loading tanpa henti, aksi hilang / rollback) - Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback / Faktor: Packet loss, Latensi - Siapa: Fitur tertentu saja, Seluruh server / Kapan: Tepat setelah login atau maintenance, Jam sibuk malam hari, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pakai ulang koneksi ke API eksternal (HTTP keep-alive, connection pool) dan jangan membuka koneksi baru untuk setiap request, kirim keepalive untuk koneksi idle di pool dengan interval lebih pendek dari idle timeout NAT (AWS 350 detik) atau tutup lebih dulu, jika gagal coba lagi dengan interval yang makin panjang dan disebar secara acak, catat tingkat kegagalan dan latensi per panggilan eksternal. - Tugas Tim Infrastruktur: Tambah alamat IP ke NAT gateway (NAT gateway publik AWS secara default hanya bisa memasang hingga 2 Elastic IP, jadi untuk lebih dari itu ajukan kenaikan kuota), pisahkan gateway per availability zone dan subnet, pasang alert untuk metrik kegagalan alokasi port (AWS ErrorPortAllocation, Failed pada Azure SNAT Connection Count, OUT_OF_RESOURCES pada Google Cloud dropped_sent_packets_count), untuk Google Cloud NAT naikkan jumlah port minimum per VM atau pakai alokasi port dinamis. - Kisaran angka: AWS NAT gateway bisa membuka hingga 55.000 koneksi bersamaan ke tujuan yang sama (IP, port, protokol) per satu alamat IP, dan kapasitasnya bisa ditambah dengan memasang hingga 8 IP. Koneksi yang diam selama 350 detik dihapus, dan paket yang dikirim lewat koneksi itu sesudahnya dibalas RST. Azure NAT Gateway menyediakan 64.512 port SNAT per IP publik (maksimal 16 IP). Google Cloud NAT membagi 64.512 port per NAT IP ke setiap VM, tetapi nilai default port minimum per VM adalah 64 (alokasi statis), sehingga dengan pengaturan default, koneksi bersamaan dari satu VM ke tujuan yang sama umumnya terbatas pada 64. - Di grafik: Mendatar di batas (Jumlah koneksi bersamaan NAT gateway, jumlah kegagalan alokasi port) - Yang diperiksa: Untuk AWS, letakkan metrik NAT gateway ErrorPortAllocation, ActiveConnectionCount, dan PacketsDropCount di CloudWatch (Azure: SNAT Connection Count yang difilter ke status Failed serta Dropped Packets; Google Cloud: dropped_sent_packets_count dengan reason OUT_OF_RESOURCES) berdampingan dengan waktu kegagalan panggilan eksternal dari server game - Cocok jika: Pada saat panggilan eksternal gagal, ErrorPortAllocation (Azure: SNAT Connection Count berstatus Failed, Google Cloud: drop OUT_OF_RESOURCES) lebih dari 0, dan kegagalan terkumpul pada panggilan ke satu atau dua tujuan yang menerima banyak koneksi, seperti server autentikasi atau pembayaran - Tidak cocok jika: Kegagalan alokasi port 0, tetapi connect dari server game gagal dengan EADDRNOTAVAIL dan TIME_WAIT mendekati rentang port ephemeral: lebih mungkin “Port ephemeral habis pada koneksi antarserver”. Koneksi berhasil tetapi responsnya saja yang lambat: lebih mungkin “Ketergantungan pada layanan eksternal” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Berbeda dengan “Port ephemeral habis pada koneksi antarserver”, yaitu habisnya port ephemeral di satu server, batas ini berlaku di NAT gateway dan dipakai bersama oleh server-server di belakang gateway (Google Cloud NAT membaginya per VM). Jika TIME_WAIT dan rentang port ephemeral di sisi server masih longgar tetapi hanya panggilan ke luar yang gagal, penyebabnya ada di sini. Port dari koneksi yang sudah ditutup juga tidak langsung dipakai lagi untuk tujuan yang sama (di Azure ada cooldown, di Google Cloud tidak bisa dipakai selama TIME_WAIT), sehingga makin sering koneksi singkat diulang, makin cepat batasnya tercapai. - Sumber: - [NAT gateway basics](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-basics.html) · AWS · 55.000 koneksi bersamaan ke tujuan yang sama (IP, port, dan protokol tujuan) per alamat IPv4, bisa ditambah dengan memasang hingga 8 IP (Elastic IP pada NAT gateway publik default 2, ditambah lewat permintaan kenaikan kuota); bandwidth naik otomatis dari 5 Gbps hingga 100 Gbps dan throughput dari 1 juta hingga 10 juta paket per detik, dan paket dibuang jika batas itu terlampaui - [NAT gateway metrics and dimensions](https://docs.aws.amazon.com/vpc/latest/userguide/metrics-dimensions-nat-gateway.html) · AWS · ErrorPortAllocation: berapa kali port sumber gagal dialokasikan (jika lebih dari 0, koneksi bersamaan terlalu banyak), ActiveConnectionCount, IdleTimeoutCount (koneksi yang dibersihkan karena idle 350 detik), PacketsDropCount - [Troubleshoot NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html) · AWS · Jika idle 350 detik, koneksi kedaluwarsa dan pengiriman berikutnya dibalas RST; disarankan keepalive lebih pendek dari 350 detik; jika batas koneksi tercapai, tambah gateway per availability zone, tambah IP, atau kurangi jumlah koneksi - [Source Network Address Translation (SNAT) with Azure NAT Gateway](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-gateway-snat) · Microsoft Azure · 64.512 port SNAT per IP publik (maksimal 16 IP); setiap koneksi ke tujuan yang sama memerlukan port yang berbeda; port yang sudah ditutup melewati cooldown sebelum dipakai lagi untuk tujuan yang sama - [Metrics and alerts for Azure NAT Gateway](https://learn.microsoft.com/en-us/azure/nat-gateway/nat-metrics) · Microsoft Azure · Jika SNAT Connection Count yang difilter ke status Failed lebih dari 0, kemungkinan port SNAT habis; Dropped Packets - [IP addresses and ports](https://cloud.google.com/nat/docs/ports-and-addresses) · Google Cloud · 64.512 port masing-masing untuk TCP dan UDP per NAT IP; default port minimum per VM 64 (alokasi statis) dan 32 (alokasi dinamis); jumlah port yang dicadangkan untuk VM membatasi jumlah koneksi bersamaan ke tujuan yang sama; port dari koneksi yang sudah ditutup tidak bisa dipakai selama TIME_WAIT - [Logs and metrics](https://cloud.google.com/nat/docs/monitoring) · Google Cloud · dropped_sent_packets_count dengan reason OUT_OF_RESOURCES: paket yang dibuang karena NAT IP atau port tidak cukup #### dc-lb-imbalance · Distribusi load balancer timpang dan health check keliru · LB imbalance, bad health checks Koneksi menumpuk di satu server saja, atau pemain terus dikirim ke server yang sudah mati. - Mengapa → Akibatnya → Di layar: Aturan distribusi tidak sesuai, atau health check tidak melihat kondisi sebenarnya → Hanya satu server yang kelebihan beban, atau ada percobaan koneksi ke server yang sudah mati → Hanya sebagian channel atau sebagian pemain yang mengalami slow motion, tidak bisa masuk, atau loading tanpa henti - Gejala: Slow motion, Tidak bisa masuk / loading tanpa henti / Faktor: Stall, Packet loss - Siapa: Lokasi/channel tertentu / Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Implementasikan health check yang menjawab permintaan pemeriksaan dari load balancer berdasarkan kondisi game sebenarnya (tick berjalan, koneksi DB), sertakan juga nilai beban server. - Tugas Tim Infrastruktur: Ganti health check ke cara yang memeriksa respons game sebenarnya, distribusikan berdasarkan beban server, pantau selisih jumlah koneksi antarserver. - Di grafik: Hanya sebagian yang tinggi (Jumlah koneksi dan utilisasi CPU per server) - Yang diperiksa: Tumpangkan jumlah koneksi (ss -s) dan utilisasi CPU setiap server di belakang load balancer dalam satu grafik, lalu bandingkan status kesehatan target di load balancer (AWS: HealthyHostCount dan UnHealthyHostCount di CloudWatch) dengan kondisi server game yang sebenarnya - Cocok jika: Hanya satu atau dua server yang jumlah koneksi dan CPU-nya jauh lebih tinggi daripada server lain, atau server yang tick-nya berhenti tetap berstatus “sehat” dan terus menerima koneksi baru - Tidak cocok jika: Jumlah koneksi per server merata, tetapi hanya satu channel yang lambat: mengarah ke beban di dalam channel itu (“Kelebihan beban di area single-thread (hotspot)”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Kasus nyata: aws-2025 - Sumber: - [Load Balancing in the Datacenter](https://sre.google/sre-book/load-balancing-datacenter/) · Google · Round robin sederhana membuat penggunaan CPU antar-task berbeda hingga 2 kali lipat; distribusi berbobot dengan backend menyertakan beban di respons dan health check; status lame duck yang menyatakan tidak mau menerima request lagi - [Health checks for Network Load Balancer target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html) · AWS · Health check default berinterval 30 detik dan target dikeluarkan setelah 2 kali gagal; layanan UDP diperiksa dengan health check TCP atau HTTP, jadi disarankan mengonfigurasinya agar mencerminkan kondisi layanan sebenarnya - [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) · AWS · HealthyHostCount dan UnHealthyHostCount: jumlah target yang dinilai sehat dan tidak sehat #### dc-microburst · Microburst di switch · Switch microburst drops Jika beberapa server sekaligus mengirim paket ke ribuan pemain pada saat yang sama, buffer kecil di port switch tempat trafik itu bertemu meluap dalam waktu kurang dari 1 ms. - Mengapa → Akibatnya → Di layar: Kemunculan world boss, skill berskala besar, atau tick beberapa server yang bertepatan di saat yang sama membuat pengiriman terjadi sekaligus → Buffer (ratusan KB hingga beberapa MB per port) di titik tempat beberapa port bertemu di satu port, atau tempat trafik pindah dari port cepat ke port lambat, penuh sesaat → Sebagian paket dibuang, banyak pemain sekaligus mengalami teleport atau skill tidak keluar - Gejala: Teleport, Aksi hilang / rollback / Faktor: Packet loss - Siapa: Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur jaringan (Tim Infrastruktur), Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Bagi pengiriman secara merata di dalam satu tick (pacing), geser sedikit waktu mulai tick di setiap server. - Tugas Tim Infrastruktur: Jaringan: pakai switch dengan buffer besar, sebar trafik (tempatkan server di beberapa switch dan port), pantau counter drop per port switch. Server/OS: batasi kecepatan kirim total server (shaper tc Linux). - Kisaran angka: Jumlah data yang bisa dikirim port 10 Gbps dalam 1 ms sekitar 1,25 MB. Jika trafik dua port masuk bersamaan ke satu port, 1,25 MB menumpuk setiap 1 ms. Walau utilisasi rata-rata per 1 detik hanya 10%, buffer bisa meluap pada skala 1 ms. - Di grafik: Naik mengikuti beban (Jumlah drop output port switch) - Yang diperiksa: Kumpulkan counter drop output (ifOutDiscards, atau output drops tergantung perangkat) dari port switch tempat server terhubung dan port tempat trafiknya bertemu dengan interval sependek mungkin, lalu cocokkan dengan waktu kemunculan boss atau pertempuran besar. Tidak terlihat hanya dari grafik utilisasi rata-rata per 1 detik atau 1 menit - Cocok jika: Utilisasi rata-rata rendah, tetapi drop output bertambah setiap kali pemain berkumpul di satu tempat, dan pada saat itu banyak pemain sekaligus melaporkan teleport atau skill tidak keluar - Tidak cocok jika: Drop terus bertambah pada jam ketika utilisasi rata-rata tinggi: lebih mungkin “Jalur data center penuh”. Error input (CRC) bertambah: lebih mungkin “Kabel rusak dan error port” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [High-Resolution Measurement of Data Center Microbursts (IMC 2017)](https://conferences.sigcomm.org/imc/2017/papers/imc17-final60.pdf) · ACM · Lebih dari 70% burst di data center selesai dalam puluhan µs; paket dibuang karena burst bahkan di port dengan utilisasi rata-rata sekitar 9% - [Data Center TCP (DCTCP) (SIGCOMM 2010)](https://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p63.pdf) · ACM · Switch umum memiliki buffer dangkal (48 port berbagi 4 MB, satu port bisa memakai hingga sekitar 700 KB); jika banyak flow masuk ke satu port dalam waktu singkat, terjadi packet loss - [RFC 2863: The Interfaces Group MIB](https://www.rfc-editor.org/rfc/rfc2863) · IETF · ifOutDiscards: jumlah paket yang tidak bisa dikirim dan dibuang walau tidak ada error, misalnya untuk mengosongkan ruang buffer #### dc-uplink · Jalur data center penuh · Uplink saturation Jika deploy patch, pengiriman log, dan backup memakai jalur yang sama dengan game, jalurnya penuh. - Mengapa → Akibatnya → Di layar: Transfer besar memakai jalur yang sama → Antrean dan packet loss di jalur bertambah → Ping seluruh server naik dan pemain teleport - Gejala: Input lag, Teleport / Faktor: Latensi, Packet loss - Siapa: Seluruh server / Kapan: Secara berkala, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Jaringan: prioritaskan trafik game (QoS), pisahkan jalur untuk transfer besar, pasang alert utilisasi jalur. Server/OS: batasi kecepatan backup, pengiriman log, dan deploy lalu jalankan di jam sepi. - Di grafik: Mendatar di batas (Utilisasi jalur, RTT (ping)) - Yang diperiksa: Letakkan utilisasi interface uplink data center, yang dihitung dari SNMP ifHCInOctets dan ifHCOutOctets, dan drop output (ifOutDiscards) pada sumbu waktu yang sama dengan jadwal backup, deploy, dan pengiriman log - Cocok jika: Pada saat utilisasi jalur menempel di batas bandwidth dan mendatar, RTT dan drop seluruh server naik, dan waktunya bertepatan dengan pekerjaan transfer besar - Tidak cocok jika: Utilisasi per menit masih jauh di bawah batas, tetapi ada drop: lebih mungkin “Microburst di switch” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 4594: Configuration Guidelines for DiffServ Service Classes](https://www.rfc-editor.org/rfc/rfc4594) · IETF · Trafik interaktif real-time seperti game dan transfer besar seperti backup diproses di kelas layanan yang berbeda - [RFC 7567: IETF Recommendations Regarding Active Queue Management](https://www.rfc-editor.org/rfc/rfc7567) · IETF · Jika jumlah yang masuk ke perangkat melebihi kecepatan kirimnya, antrean menumpuk, dan antrean yang berlebihan adalah penyebab utama latensi - [RFC 2863: The Interfaces Group MIB](https://www.rfc-editor.org/rfc/rfc2863) · IETF · ifHCInOctets dan ifHCOutOctets: jumlah byte yang diterima dan dikirim interface (64 bit); ifOutDiscards: jumlah paket yang tidak bisa dikirim dan dibuang #### dc-failover · Failover perangkat jaringan · Network device failover Saat satu router atau firewall rusak dan dialihkan ke perangkat cadangan (failover), semua pemain mengalami freeze selama beberapa detik. - Mengapa → Akibatnya → Di layar: Dialihkan ke perangkat cadangan karena perangkat rusak atau maintenance → Peralihan memakan waktu beberapa detik, dan jika informasi sesi tidak tersinkronisasi, koneksi di-reset → Semua pemain di server mengalami freeze bersamaan, disconnect massal - Gejala: Freeze, Disconnect / Faktor: Packet loss - Siapa: Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: pakai timeout yang tahan terhadap putus singkat (beberapa detik), dan jika terputus lalu reconnect, lanjutkan sesi lewat token sesi. Klien: reconnect otomatis jika terputus (sebar interval percobaan ulang secara acak agar tidak menyerbu bersamaan). - Tugas Tim Infrastruktur: Pakai redundansi yang berbagi status koneksi, deteksi kerusakan dalam 1 detik dengan BFD, uji failover secara berkala. - Kisaran angka: Jika perangkat langsung mendeteksi kerusakan, sekitar 1–3 detik. Jika hanya mengandalkan timer default BGP tanpa deteksi kerusakan cepat (BFD), rute bisa terputus selama 90–180 detik sampai perangkat tetangga mendeteksinya. - Di grafik: Koneksi putus serentak (Jumlah koneksi, volume kirim dan terima seluruh server) - Yang diperiksa: Periksa log event router dan firewall (perubahan peran VRRP, sesi BFD atau BGP down, catatan failover) bersama jumlah koneksi dan volume kirim-terima seluruh server pada waktu yang sama - Cocok jika: Pada waktu failover di log perangkat, trafik semua server di belakang perangkat itu menjadi 0 selama beberapa detik atau jumlah koneksi turun bersamaan - Tidak cocok jika: Hanya koneksi satu server yang turun: lebih mungkin “Crash di server” atau “Masalah driver dan firmware NIC”. Log perangkat bersih dan server yang berhenti adalah satu virtual machine di cloud: lebih mungkin “Maintenance host cloud dan live migration” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 5880: Bidirectional Forwarding Detection (BFD)](https://www.rfc-editor.org/rfc/rfc5880) · IETF · Metode Hello pada protokol routing butuh lebih dari 1 detik untuk mendeteksi kerusakan, sehingga dibuat BFD untuk mendeteksinya dalam waktu lebih singkat - [RFC 7938: Use of BGP for Routing in Large-Scale Data Centers](https://www.rfc-editor.org/rfc/rfc7938) · IETF · Jika hanya mengandalkan keepalive BGP, konvergensi lambat; jika link down langsung diterima dan sesi diputus, kerusakan terdeteksi dalam skala ms lalu rute konvergen ulang - [RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6](https://www.rfc-editor.org/rfc/rfc5798) · IETF · Advertisement VRRP default 1 detik; perangkat cadangan mengambil alih peran jika advertisement berhenti lebih dari sekitar 3 kali intervalnya (dengan pengaturan default, sedikit di atas 3 detik) #### dc-bad-cable · Kabel rusak dan error port · Bad cable / optics (CRC errors) Jika modul optik atau kabel rusak, sebagian paket yang lewat jalur itu rusak dengan persentase tertentu. - Mengapa → Akibatnya → Di layar: Bit error karena modul optik atau kabel rusak → Paket yang rusak dibuang diam-diam oleh perangkat → Hanya sebagian server dan pemain yang memakai jalur itu yang terus mengalami packet loss sehingga terjadi teleport atau rubber banding - Gejala: Teleport, Rubber banding / Faktor: Packet loss - Siapa: Lokasi/channel tertentu / Kapan: Selalu - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Infrastruktur: Pantau counter error port (CRC) dan pasang alert, ganti komponen seperti modul optik dan kabel, keluarkan link yang bermasalah dan alihkan trafik sampai komponen diganti. - Di grafik: Hanya sebagian yang tinggi (Jumlah error CRC per port, tingkat packet loss per server dan rute) - Yang diperiksa: Periksa counter CRC di kedua ujung link. Di switch: error FCS port (dot3StatsFCSErrors) dan error input (ifInErrors); di server: crc di antara RX errors pada ip -s -s link (statistik kernel rx_crc_errors) - Cocok jika: Error CRC di satu port terus bertambah tanpa kaitan dengan volume trafik dan jam, dan hanya server serta pemain yang lewat port itu yang mengalami packet loss - Tidak cocok jika: Tidak ada error CRC dan hanya drop output yang bertambah: mengarah ke kongesti (“Microburst di switch”, “Jalur data center penuh”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017)](https://www.microsoft.com/en-us/research/wp-content/uploads/2017/06/CorrOpt_SIGCOMM2017.pdf) · ACM · Analisis 350.000 link di data center: penyebab kerusakan paket adalah modul optik rusak, serat optik rusak, dan konektor kotor; tingkat kerusakan stabil tanpa kaitan dengan pemakaian; link bermasalah dikeluarkan lalu diperbaiki sambil menjaga jumlah jalur - [RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types](https://www.rfc-editor.org/rfc/rfc3635) · IETF · Counter kegagalan pemeriksaan frame FCS (dot3StatsFCSErrors); error ini dijumlahkan ke error input (ifInErrors) - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · rx_crc_errors: jumlah paket yang diterima dengan error CRC; jenis error bisa diperiksa satu per satu dengan ip -s -s link #### dc-mtu · MTU tidak cocok (hanya paket besar yang hilang) · MTU black hole Jika MTU (ukuran yang bisa dikirim sekaligus) di segmen tengah mengecil tetapi notifikasi ukuran terlampaui diblokir, hanya paket besar yang terus hilang. - Mengapa → Akibatnya → Di layar: MTU mengecil di segmen tunnel atau VPN → Notifikasi ukuran terlampaui (ICMP) diblokir firewall sehingga pengirim tidak tahu → Freeze hanya saat membuka layar besar seperti inventory atau daftar karakter, lalu disconnect - Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Wilayah/ISP tertentu, Hanya saya / Kapan: Saat melakukan aksi tertentu, Tepat setelah login atau maintenance - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Untuk menurunkannya langsung dari sisi server, atur ukuran segmen maksimum socket dengan TCP_MAXSEG (memecah pesan menjadi kecil di kode game saja tidak mencegahnya), jaga paket UDP maksimal 1.200 byte. - Tugas Tim Infrastruktur: Jaringan: perkecil ukuran paket TCP di segmen tunnel (penyesuaian MSS), izinkan notifikasi ukuran terlampaui (ICMP) di firewall dan network ACL cloud. Server/OS: izinkan juga notifikasi ukuran terlampaui (ICMP) di firewall server dan security group cloud, aktifkan MTU probing di kernel server dengan tcp_mtu_probing=1 (jaring pengaman terakhir yang baru bekerja setelah koneksi terhenti beberapa detik). - Kisaran angka: Biasanya 1.500 byte, dan menyusut ke sekitar 1.400 setelah lewat tunnel. - Di grafik: Hanya sebagian yang tinggi (Disconnect per wilayah dan ISP, kegagalan respons besar) - Yang diperiksa: Dari PC pemain yang bermasalah, kirim ping ke server dengan tanda jangan-fragmentasi (DF) aktif sambil mengubah ukurannya. Di Windows ping /f /l 1472 SERVER_IP, di Linux ping -M do -s 1472 SERVER_IP (1.472 adalah MTU 1.500 dikurangi header IP 20 byte dan header ICMP 8 byte). Kecilkan ukurannya bertahap untuk menemukan ukuran maksimum yang lolos, lalu pastikan security group dan firewall di sisi server mengizinkan notifikasi ICMP ukuran terlampaui (Fragmentation Needed) - Cocok jika: Ping kecil berhasil, tetapi ping DF 1.472 byte gagal (tidak ada respons atau ada error yang menyatakan perlu fragmentasi), dan ukuran maksimum yang lolos kecil, sekitar 1.400. Pemain di wilayah yang sama mengalami freeze hanya saat membuka layar besar - Tidak cocok jika: Ping DF 1.472 byte juga lancar: bukan masalah path MTU. Ping kecil pun gagal: ICMP sendiri diblokir sehingga cara ini tidak bisa dipakai untuk menilai - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [RFC 2923: TCP Problems with Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc2923) · IETF · Jika firewall memblokir ICMP (Fragmentation Needed), path MTU discovery gagal dan hanya paket besar yang terus hilang (black hole); ping dan komunikasi kecil tetap berjalan sehingga sulit didiagnosis - [Maximum transmission unit and maximum segment size](https://developers.cloudflare.com/magic-transit/reference/mtu-mss/) · Cloudflare · Path MTU internet 1.500, menjadi 1.476 setelah lewat tunnel GRE; disarankan membatasi TCP MSS maksimal 1.436 - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Dengan tcp_mtu_probing=1, TCP path MTU discovery biasanya nonaktif dan baru diaktifkan saat ICMP black hole terdeteksi - [ping(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ping.8.html) · iputils · -M do mengaktifkan tanda DF dan menolak paket yang lebih besar dari path MTU; -s menentukan ukuran data (default 56 byte ditambah header ICMP 8 byte) - [ping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping) · Microsoft · /f mengaktifkan tanda DF untuk mencari masalah path MTU, /l menentukan ukuran data ### L6 Kartu jaringan server (9 penyebab) #### nic-irq · Interrupt NIC terpusat di satu core · Single-queue NIC / no RSS Jika NIC hanya mengirim interrupt kedatangan paket ke satu core CPU, core itu menjadi bottleneck. - Mengapa → Akibatnya → Di layar: Hanya ada satu antrean terima (RX queue), atau RSS, yang menyebar paket ke beberapa core, dimatikan → Satu core mencapai 100% sehingga paket tidak diambil tepat waktu → Saat pemain berkumpul, terjadi packet loss dan latensi di seluruh server (teleport, input lag) - Gejala: Teleport, Rubber banding, Input lag / Faktor: Packet loss, Latensi - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Konfigurasikan RSS (disebar oleh NIC) dan RPS (disebar oleh kernel), sebar interrupt ke beberapa core, atur agar antrean untuk UDP dibagi sampai ke port (rx-flow-hash udp4 sdfn pada ethtool -N), pisahkan core pemroses interrupt dari core thread tick game, pantau %soft per core. - Kisaran angka: Jumlah paket yang bisa diproses satu core lewat kernel kira-kira ratusan ribu paket per detik, tergantung ukuran paket dan konfigurasi. Jika di utilisasi per core porsi pemrosesan paket masuk (%soft pada mpstat) hanya menumpuk di satu core, inilah penyebabnya. - Di grafik: Mendatar di batas (%soft per core, jumlah paket diterima per detik) - Yang diperiksa: Periksa %soft (persentase pemrosesan software interrupt) per core dengan mpstat -P ALL 1, lalu pastikan ke core mana interrupt setiap antrean NIC pergi dengan /proc/interrupts, jumlah antrean dengan ethtool -l, dan jumlah paket per antrean dengan ethtool -S (namanya berbeda per driver) - Cocok jika: Hanya satu core yang %soft-nya menempel di dekat 100% sementara core lain longgar, dan interrupt serta paket menumpuk di satu antrean. Sejak itu jumlah paket diterima per detik tidak bisa naik lagi - Tidak cocok jika: %soft tersebar merata di beberapa core: bukan penyebab ini. CPU longgar tetapi ada packet loss: lebih mungkin “Batas PPS cloud terlampaui” atau “Ring buffer terlalu kecil” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Walau ada beberapa antrean, jika sebagian besar trafik datang dari sedikit alamat seperti gateway atau proxy, trafik menumpuk di satu antrean. Untuk UDP, konfigurasi default NIC kadang membagi antrean hanya berdasarkan alamat, jadi harus diubah agar port juga diperhitungkan supaya trafik tersebar merata. - Sumber: - [Scaling in the Linux Networking Stack](https://docs.kernel.org/networking/scaling.html) · Linux kernel · RSS (NIC menyebar ke beberapa antrean terima) dan RPS (kernel yang menyebar), konfigurasi yang memberi interrupt terpisah untuk setiap antrean dan membaginya ke beberapa core; jika pemrosesan interrupt terima menjadi bottleneck, disarankan RSS - [How to receive a million packets per second](https://blog.cloudflare.com/how-to-receive-a-million-packets/) · Cloudflare · Pengukuran ketika satu antrean terima hanya diproses satu core: core itu mentok di sekitar 350.000–430.000 paket per detik; kasus NIC yang meng-hash UDP hanya dengan alamat IP sehingga trafik menumpuk di satu antrean - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Opsi ethtool -N rx-flow-hash udp4 untuk memasukkan port (f, n) ke hash UDP - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · %soft: persentase waktu CPU yang dipakai untuk memproses software interrupt; per core dengan -P ALL #### nic-ring · Ring buffer terlalu kecil · RX ring buffer overflow Jika ring buffer, tempat NIC menampung paket sementara, terlalu kecil, buffer meluap saat paket datang serentak dan paket dibuang. - Mengapa → Akibatnya → Di layar: Ring buffer kecil karena masih memakai nilai default (256–2.048 slot, tergantung driver) → Saat burst, buffer meluap sebelum CPU sempat mengambil paket → Packet loss hanya pada saat burst (teleport, skill tidak keluar). Tidak ada jejak di log server game - Gejala: Teleport, Aksi hilang / rollback / Faktor: Packet loss - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Perbesar ring buffer (ethtool -G), pantau counter drop (rx_missed_errors dan lainnya di ethtool -S, namanya berbeda per driver). - Kisaran angka: Jika 1 juta paket per detik datang serentak, 1.024 slot penuh dalam sekitar 1 ms. Jika CPU terlambat sekali saja di sela itu, buffer meluap. Sebagian besar NIC bisa diperbesar sampai ribuan slot. - Di grafik: Melonjak acak sesekali (Counter drop terima NIC) - Yang diperiksa: Kumpulkan counter drop terima di ethtool -S (rx_missed_errors, rx_fifo_errors, dan lainnya; namanya berbeda per driver) dan missed di ip -s -s link dengan interval pendek, lalu periksa ukuran ring saat ini dan nilai maksimumnya dengan ethtool -g - Cocok jika: Counter drop bertambah pada saat burst, dan ukuran ring saat ini jauh lebih kecil daripada nilai maksimum. Drop berkurang setelah ring diperbesar - Tidak cocok jika: Counter drop tidak berubah tetapi ada packet loss: mengarah ke tahap kernel berikutnya (“Buffer socket kernel terlalu kecil”) atau segmen jaringan. %soft di satu core 100%: lebih mungkin “Interrupt NIC terpusat di satu core” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Linux Base Driver for Intel(R) Ethernet Network Connection (e1000)](https://docs.kernel.org/networking/device_drivers/ethernet/intel/e1000.html) · Linux kernel · Receive descriptor (slot ring) e1000 default 256, bisa diperbesar sampai 4.096 - [drivers/net/ethernet/intel/ice/ice.h (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ice/ice.h?h=v6.12) · Linux kernel · Receive descriptor driver ice default 2.048, maksimal 8.160 - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · Paket yang dibuang perangkat karena buffer tidak cukup dihitung sebagai rx_missed_errors; statistik per driver diperiksa dengan ethtool -S - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · -g memeriksa ukuran ring (nilai saat ini dan maksimum), -G mengubahnya, -S menampilkan statistik per driver #### nic-coalesce · Interrupt coalescing berlebihan · Interrupt coalescing Jika NIC mengumpulkan paket lalu memberi tahu CPU sekaligus untuk mengurangi beban CPU, paket terlambat selama waktu pengumpulan itu. - Mengapa → Akibatnya → Di layar: NIC mengumpulkan paket selama waktu atau jumlah tertentu lalu memberi tahu CPU → Paket menunggu selama dikumpulkan → Latensi bertambah sedikit. Biasanya kecil, tetapi jika berlebihan bisa mencapai skala ms - Gejala: Input lag / Faktor: Latensi - Siapa: Seluruh server / Kapan: Selalu - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Pakai coalescing adaptif, sesuaikan nilainya agar cocok untuk server game (ethtool -C). - Kisaran angka: Biasanya puluhan hingga ratusan µs. Untuk game umumnya bisa diabaikan, tetapi jika pengaturannya berlebihan bisa membesar sampai skala ms. - Di grafik: Selalu tinggi sejak awal (Waktu pulang-pergi di dalam data center yang sama) - Yang diperiksa: Periksa konfigurasi coalescing saat ini (adaptive-rx, rx-usecs, rx-frames) dengan ethtool -c, lalu bandingkan waktu pulang-pergi ping ke server lain di data center yang sama sebelum dan sesudah konfigurasi diubah - Cocok jika: rx-usecs diatur besar, ratusan µs atau lebih, dan jika nilainya diturunkan, waktu pulang-pergi di dalam data center yang sama berkurang sebanding - Tidak cocok jika: Waktu pulang-pergi tidak berubah walau nilainya diturunkan: bukan penyebab ini - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Linux Driver for Intel(R) Ethernet Network Connection (e1000e)](https://docs.kernel.org/networking/device_drivers/ethernet/intel/e1000e.html) · Linux kernel · Secara default, interrupt moderation adaptif menghasilkan 4.000–20.000 interrupt per detik (interval 50–250 µs); mengurangi interrupt menghemat CPU tetapi menambah latensi - [Linux Base Driver for Intel(R) Ethernet Network Connection (e1000)](https://docs.kernel.org/networking/device_drivers/ethernet/intel/e1000.html) · Linux kernel · RxIntDelay bisa menunda interrupt terima dalam satuan 1,024 µs hingga maksimal 65.535 (sekitar 67 ms); makin besar nilainya, makin besar latensi terima - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Pengaturan adaptive-rx, rx-usecs, dan rx-frames pada ethtool -C #### nic-cloud-pps · Batas PPS cloud terlampaui · Cloud PPS / bandwidth allowance Server cloud memiliki batas jumlah paket per detik dan bandwidth per tipe instance, dan jika terlampaui, paket dibuang diam-diam. - Mengapa → Akibatnya → Di layar: Jumlah pemain online bersamaan bertambah sehingga jumlah paket per detik melewati batas instance → Jaringan cloud membuang kelebihannya → Teleport dan skill tidak keluar karena packet loss yang penyebabnya tidak jelas. CPU server masih longgar - Gejala: Teleport, Aksi hilang / rollback / Faktor: Packet loss - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Gabungkan paket (pesan dalam satu tick dimasukkan ke satu paket), jangan terlalu sering mengirim paket yang sangat kecil. - Tugas Tim Infrastruktur: Periksa counter pelampauan batas (di AWS: pps_allowance_exceeded, conntrack_allowance_exceeded, dan lainnya) dan pasang alert, pakai instance yang lebih besar, hindari batas connection tracking dengan konfigurasi security group yang tidak memicu pelacakan. - Tugas Pihak Eksternal: Tanyakan ke penyedia cloud batas jumlah paket per detik dan batas connection tracking per tipe instance. - Kisaran angka: Batasnya berbeda per ukuran instance, dan batas jumlah paket per detik sering tidak dipublikasikan. “Hingga 10 Gbps” pada instance kecil adalah kecepatan burst yang hanya bisa dipakai selama kreditnya masih ada (biasanya 5–60 menit), sedangkan kecepatan dasar sehari-hari jauh lebih rendah. - Di grafik: Mendatar di batas (Jumlah paket per detik, counter pelampauan allowance) - Yang diperiksa: Kumpulkan counter ENA pps_allowance_exceeded, bw_in_allowance_exceeded, bw_out_allowance_exceeded, dan conntrack_allowance_exceeded di ethtool -S dengan interval pendek, lalu lihat bersama jumlah paket per detik. Counter ini juga bisa dikirim ke CloudWatch lewat CloudWatch agent untuk dipasangi alert - Cocok jika: Pada saat packet loss terjadi, counter pelampauan allowance bertambah, dan jumlah paket per detik tidak bisa naik melewati nilai tertentu. CPU server masih longgar - Tidak cocok jika: Counter pelampauan tidak berubah: bukan penyebab ini. %soft di satu core 100%: lebih mungkin “Interrupt NIC terpusat di satu core” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: conntrack_allowance_exceeded menunjukkan kasus ketika tabel connection tracking penuh sehingga koneksi baru dibuang. Jika tabelnya masih longgar tetapi hanya koneksi idle yang terputus karena entri pelacakannya kedaluwarsa, lihat entri “Connection tracking di security group cloud kedaluwarsa”. - Sumber: - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Setiap instance punya batas bandwidth, PPS, dan connection tracking; jika terlampaui, paket ditampung di antrean lalu dibuang; counter pps_allowance_exceeded dan conntrack_allowance_exceeded - [Amazon EC2 instance network bandwidth](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) · AWS · “Hingga N Gbps” pada instance dengan 16 vCPU atau kurang adalah burst yang memakai kredit I/O jaringan (biasanya 5–60 menit); jika kredit habis, kecepatan kembali ke bandwidth dasar #### nic-saturate · Bandwidth NIC penuh · NIC bandwidth saturation Jika kartu 1 Gbps atau 10 Gbps dipakai sampai batasnya, antrean kirim memanjang dan akhirnya paket dibuang. - Mengapa → Akibatnya → Di layar: Broadcast bertambah sehingga volume kirim mencapai batas kartu → Antrean kirim memanjang, dan jika meluap, paket dibuang → Latensi dan packet loss di seluruh server (input lag, teleport) - Gejala: Input lag, Teleport / Faktor: Latensi, Packet loss - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Kurangi volume kirim (area of interest, kompresi, kirim perubahan saja). - Tugas Tim Infrastruktur: Tingkatkan kartu (NIC yang lebih cepat, di cloud instance yang lebih besar), pasang alert utilisasi NIC. - Di grafik: Mendatar di batas (Volume kirim NIC, drop kirim) - Yang diperiksa: Bandingkan txkB/s dan %ifutil (utilisasi terhadap kecepatan interface) dari sar -n DEV 1 dengan kecepatan NIC dan bandwidth instance, lalu lihat juga TX dropped di ip -s link - Cocok jika: Volume kirim mendatar di sekitar bandwidth NIC atau instance, dan sejak itu drop kirim dan latensi seluruh server bertambah - Tidak cocok jika: Bandwidth masih longgar: bukan penyebab ini. Banyak paket kecil dan ada packet loss: lebih mungkin “Batas PPS cloud terlampaui” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · tx_dropped: jumlah paket yang dibuang di tengah pengiriman karena sumber daya tidak cukup - [Amazon EC2 instance network bandwidth](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) · AWS · Bandwidth yang bisa dipakai instance ditentukan oleh jumlah vCPU (ukuran instance) - [sar(1) — Linux manual page](https://man7.org/linux/man-pages/man1/sar.1.html) · sysstat · rxkB/s, txkB/s, dan %ifutil (utilisasi terhadap kecepatan interface) pada -n DEV #### nic-noisy · Overhead virtualisasi dan noisy neighbor · Noisy neighbors in virtualization Jika virtual machine lain di server fisik yang sama banyak memakai jaringan atau CPU, pemrosesan di server Anda tertunda secara tidak beraturan. - Mengapa → Akibatnya → Di layar: Virtual machine lain di server fisik yang sama banyak memakai sumber daya → Pemrosesan paket di virtual machine Anda tertunda secara tidak beraturan → Tanpa penyebab yang jelas, sesekali muncul jitter (variasi selang waktu kedatangan paket) sehingga game patah-patah - Gejala: Patah-patah / Faktor: Jitter - Siapa: Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Infrastruktur: Pakai dedicated host atau instance dengan performa terjamin, hentikan lalu jalankan ulang instance yang jitter-nya terus berlanjut agar pindah ke host lain. - Tugas Pihak Eksternal: Laporkan host yang bermasalah ke penyedia cloud. - Di grafik: Melonjak acak sesekali (Jitter waktu pulang-pergi di dalam data center yang sama, %steal) - Yang diperiksa: Kirim ping terus-menerus ke server lain di data center yang sama untuk mencatat jitter waktu pulang-pergi, lalu bandingkan bersama %steal dari mpstat dengan instance lain berkonfigurasi sama - Cocok jika: Hanya instance ini yang jitter waktu pulang-pergi atau %steal-nya melonjak tidak beraturan, sedangkan instance lain berkonfigurasi sama tenang. Hilang setelah instance dihentikan lalu dijalankan ulang dan pindah ke host lain - Tidak cocok jika: Semua instance berkonfigurasi sama melonjak dengan cara yang sama: bukan masalah host. Periksa beban di sisi server game atau segmen jaringan - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [How EC2 instance stop and start works](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-ec2-instance-stop-start-works.html) · AWS · Jika instance dihentikan lalu dijalankan lagi, sebagian besar akan dipindahkan ke host baru (kecuali dedicated host) - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · %steal: persentase waktu vCPU ini terpaksa menunggu selama hypervisor menjalankan vCPU lain #### nic-host-maintenance · Maintenance host cloud dan live migration · Cloud host maintenance / live migration Saat penyedia cloud melakukan maintenance pada server fisik (host), virtual machine dipindahkan ke host lain (live migration) atau dihentikan sementara. Selama itu seluruh server terhenti, dan jika jedanya lama, koneksi terputus. - Mengapa → Akibatnya → Di layar: Penyedia memindahkan virtual machine ke host lain atau menjedanya sementara karena maintenance host atau prediksi kerusakan → Selama dipindahkan, CPU, memori, dan jaringan melambat, dan di akhir proses virtual machine berhenti total sesaat (kurang dari 1 detik hingga sekitar 30 detik, tergantung penyedia dan caranya) → Semua pemain di server mengalami freeze bersamaan lalu fast forward atau teleport; jika jedanya lebih lama dari timeout, terjadi disconnect massal - Gejala: Freeze, Fast forward, Teleport, Disconnect / Faktor: Stall, Packet loss - Siapa: Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Pakai timeout yang tahan terhadap jeda beberapa detik, batasi jumlah tick yang dikejar setelah jeda, hitung waktu yang berlalu dengan monotonic clock, siapkan prosedur untuk menyimpan progres dan memindahkan pemain ke server lain saat menerima pemberitahuan maintenance. - Tugas Tim Infrastruktur: Berlangganan pemberitahuan maintenance dan pasang alert (Google Cloud maintenance-event, AWS scheduled event dan AWS Health, Azure Scheduled Events), ganti server lebih awal di jam sepi pemain saat menerima pemberitahuan, atur waktu maintenance jika penyedia mengizinkan (Azure Maintenance Configuration, AWS scheduled event tergantung jenisnya), cocokkan catatan maintenance dengan catatan insiden. - Tugas Pihak Eksternal: Pastikan jadwal dan cakupan dampak maintenance ke penyedia cloud, laporkan jika jeda berulang di instance yang sama. - Kisaran angka: Google Compute Engine menyatakan jeda live migration biasanya jauh lebih singkat dari 1 detik, dan selama jeda, jam sistem bisa melompat maju hingga 5 detik. Nilai maintenance-event di metadata berubah 60 detik sebelum pemindahan (jika nilai ini sudah pernah di-query minimal sekali sebelumnya). Untuk maintenance yang tidak memerlukan reboot, Azure hampir selalu berhenti kurang dari 10 detik dan dalam kasus yang jarang (untuk ukuran umum maksimal sekali dalam 18 bulan) sekitar 30 detik, sedangkan live migration biasanya tidak lebih dari 5 detik. Azure Scheduled Events memberi tahu jeda seperti ini (Freeze) minimal 15 menit sebelumnya. Namun, jika hardware host tiba-tiba rusak, pemulihan langsung dimulai tanpa pemberitahuan. - Di grafik: Kosong lalu datang sekaligus (Jumlah paket kirim dan terima server, interval tick) - Yang diperiksa: Cocokkan waktu jeda dengan catatan penyedia. Google Cloud: compute.instances.migrateOnHostMaintenance di audit log; AWS: scheduled event di describe-instance-status dan AWS Health; Azure: Microsoft.Compute/virtualMachines/liveMigration/action di Activity Log dan waktu ketika metrik ketersediaan VM (VmAvailabilityMetric) turun ke 0. Di dalam server, periksa apakah metrik dan log kosong selama jeda dan apakah jam melompat sesudahnya (log sinkronisasi waktu) - Cocok jika: Waktu seluruh server berhenti bertepatan dengan waktu maintenance atau migrasi yang dicatat penyedia, dan selama beberapa detik itu semua metrik dan log di dalam server kosong - Tidak cocok jika: Tidak ada di catatan penyedia dan jeda singkat sering berulang: lebih mungkin “CPU steal (virtual machine)”. Ada catatan reset NIC di log kernel: lebih mungkin “Masalah driver dan firmware NIC” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: AWS memberi tahu lewat scheduled event. system-reboot berarti instance di-reboot sambil dipindahkan ke host baru, dan system-maintenance berarti instance bisa terdampak sesaat oleh maintenance jaringan atau listrik. Walau jedanya hanya beberapa detik, klien yang tidak menerima ACK untuk paket yang dikirim ke server selama itu menggandakan waktu tunggu retransmisi berulang kali, sehingga koneksi TCP bisa tetap terhenti lebih lama walau server sudah berjalan lagi (“RTO TCP dan exponential backoff”). Setelah bangun dari jeda, jam bisa melompat dan berlanjut ke “Lompatan jam sistem (NTP step)”, dan health check load balancer bisa gagal sehingga server itu dikeluarkan sementara. Instance yang tidak bisa dipindahkan (seperti instance bare metal di Google Cloud) dihentikan atau dijalankan ulang saat maintenance. - Sumber: - [Live migration process during maintenance events](https://cloud.google.com/compute/docs/instances/live-migration-process) · Google Cloud · Jeda live migration biasanya jauh lebih singkat dari 1 detik; selama jeda, jam sistem melompat maju hingga 5 detik; performa disk, CPU, memori, dan jaringan turun sementara selama pemindahan; VM yang tidak menjalani live migration dimatikan saat maintenance (instance bare metal tidak didukung) - [Query metadata server for maintenance event notices](https://cloud.google.com/compute/docs/metadata/getting-live-migration-notice) · Google Cloud · Nilai metadata maintenance-event berubah 60 detik sebelum live migration (jika VM diatur untuk live migration dan nilai ini sudah di-query minimal sekali sejak maintenance terakhir) - [Monitor and plan for a host maintenance event](https://cloud.google.com/compute/docs/instances/monitor-plan-host-maintenance-event) · Google Cloud · Saat maintenance, system event compute.instances.migrateOnHostMaintenance tercatat di audit log - [Scheduled events for Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html) · AWS · Jenis scheduled event (system-reboot: di-reboot sambil dipindahkan ke host baru; system-maintenance: terdampak sesaat oleh maintenance jaringan atau listrik), pemberitahuan lewat email dan AWS Health, diperiksa dengan describe-instance-status, waktunya bisa diatur tergantung jenisnya - [Maintenance and updates](https://learn.microsoft.com/en-us/azure/virtual-machines/maintenance-and-updates) · Microsoft Azure · Maintenance tanpa reboot hampir selalu berhenti kurang dari 10 detik, dalam kasus yang jarang (untuk ukuran umum maksimal sekali dalam 18 bulan) sekitar 30 detik; live migration biasanya maksimal 5 detik; jam disinkronkan otomatis setelah jeda; koneksi TCP yang berumur panjang bisa terputus, atau pihak lawan mengirim ulang data yang ditujukan ke VM yang terhenti dengan exponential backoff sehingga pemulihan makin lambat; health check load balancer menilai tidak sehat dalam sekitar 10 detik; diperiksa lewat Microsoft.Compute/virtualMachines/liveMigration/action di Activity Log dan VmAvailabilityMetric yang menjadi 0 selama jeda; waktu penerapan dipilih dengan Maintenance Configuration - [Scheduled Events for Linux VMs in Azure](https://learn.microsoft.com/en-us/azure/virtual-machines/linux/scheduled-events) · Microsoft Azure · Freeze (jeda beberapa detik, CPU dan jaringan bisa berhenti) diberitahukan minimal 15 menit sebelumnya; saat hardware host rusak, pemulihan langsung dimulai tanpa masa pemberitahuan #### nic-reset · Masalah driver dan firmware NIC · NIC hang / reset Selama kartu berhenti dan dimulai ulang karena bug driver atau fitur yang tidak berfungsi dengan benar, semua pengiriman dan penerimaan terputus. - Mengapa → Akibatnya → Di layar: Bug driver, fitur offload tidak berfungsi dengan benar → NIC berhenti lalu dimulai ulang (beberapa detik) → Semua pemain di server itu mengalami freeze bersamaan lalu teleport atau disconnect - Gejala: Freeze, Disconnect / Faktor: Packet loss - Siapa: Seluruh server / Kapan: Sesekali secara acak, Makin lama menyala - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Periksa catatan “transmit queue … timed out” dan “Link is Down” di log kernel dan pasang alert, update driver dan firmware, matikan fitur yang bermasalah (offload dan sebagainya). - Di grafik: Kosong lalu datang sekaligus (Jumlah paket kirim dan terima server) - Yang diperiksa: Cari catatan “NETDEV WATCHDOG … transmit queue N timed out”, reset driver, serta “Link is Down” dan “Link is Up” di log kernel dengan dmesg, lalu periksa jumlah paket kirim dan terima server pada waktu itu - Cocok jika: Pada waktu jeda, ada catatan timeout antrean kirim atau link down dan up di log kernel, dan selama beberapa detik itu jumlah paket kirim dan terima 0 - Tidak cocok jika: Log kernel bersih dan port di sisi switch juga normal: mengarah ke proses server game yang berhenti (“Jeda GC stop-the-world di server”, “Deadlock”) atau “Failover perangkat jaringan” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [net/sched/sch_generic.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/sched/sch_generic.c?h=v6.12) · Linux kernel · Jika antrean kirim berhenti, watchdog kernel mencatat “NETDEV WATCHDOG … transmit queue N timed out” dan memanggil fungsi reset driver - [drivers/net/ethernet/intel/ixgbe/ixgbe_main.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c?h=v6.12) · Linux kernel · Driver ixgbe me-reset adapter saat pengiriman berhenti, dan mencatat “NIC Link is Down” jika link terputus - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Opsi ethtool -K untuk mematikan fitur offload satu per satu #### nic-offload · Jeda tunggu penggabungan GRO/LRO · GRO/LRO batching Fitur ini menggabungkan beberapa paket menjadi satu untuk mengurangi beban CPU. Tergantung konfigurasinya, paket game yang kecil kadang menunggu sebentar paket berikutnya untuk digabung bersama. - Mengapa → Akibatnya → Di layar: NIC atau kernel menggabungkan paket yang datang lalu memprosesnya sekaligus → Jika penggabungan di hardware (LRO) atau pengaturan waktu tunggu penggabungan aktif, paket menunggu sebentar paket berikutnya → Latensi bertambah sedikit (umumnya puluhan µs atau kurang) - Gejala: Input lag / Faktor: Latensi - Siapa: Seluruh server / Kapan: Selalu - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Sesuaikan dengan trafik game (matikan LRO, periksa pengaturan waktu tunggu penggabungan), periksa setelah penyebab lain karena dampaknya umumnya kecil. - Di grafik: Selalu tinggi sejak awal (Waktu pulang-pergi di dalam data center yang sama) - Yang diperiksa: Periksa status lro dan gro dengan ethtool -k serta nilai gro_flush_timeout di pengaturan sysfs perangkat, lalu bandingkan waktu pulang-pergi paket kecil di dalam data center yang sama sebelum dan sesudah diubah - Cocok jika: LRO aktif atau gro_flush_timeout lebih dari 0, dan jika dimatikan atau diatur ke 0, waktu pulang-pergi paket kecil berkurang - Tidak cocok jika: Selisihnya hanya beberapa µs walau diubah: bukan penyebab ini - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [NAPI](https://docs.kernel.org/networking/napi.html) · Linux kernel · Jika gro_flush_timeout diatur besar, paket diproses berkelompok, tetapi imbalannya muncul latensi saat beban rendah - [Linux Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Adapters (ixgbe)](https://docs.kernel.org/networking/device_drivers/ethernet/intel/ixgbe.html) · Linux kernel · GRO adalah fitur yang menggabungkan trafik masuk menjadi potongan besar untuk menghemat CPU, dan merupakan pengembangan dari LRO - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Pengaturan gro dan lro on|off pada ethtool -K ### L7 OS server (kernel) (14 penyebab) #### so-backlog · Antrean koneksi (backlog) meluap · Listen backlog / SYN queue overflow Jika puluhan ribu pemain login bersamaan tepat setelah maintenance, antrean koneksi (backlog) di kernel meluap dan upaya koneksi dibuang. - Mengapa → Akibatnya → Di layar: Begitu maintenance selesai, koneksi berdatangan lebih cepat daripada kecepatan server game memprosesnya dengan accept → Antrean koneksi kernel (backlog, yaitu nilai yang lebih kecil antara nilai yang diberikan kode server ke listen dan batas atas kernel) penuh → Upaya koneksi dibuang dan percobaan ulang terus berulang, sehingga pemain tidak bisa masuk atau mengalami loading tanpa henti - Gejala: Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Seluruh server / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: naikkan nilai listen yang diberikan di kode, jaga agar thread yang menerima koneksi tidak tertahan oleh pekerjaan lain, gunakan sistem antrean login. Klien: perpanjang interval percobaan ulang (disebar secara acak). - Tugas Tim Infrastruktur: Naikkan somaxconn di kernel (baru efektif jika nilai listen di kode server juga dinaikkan), biarkan SYN cookie tetap aktif, pantau jumlah overflow (TcpExtListenOverflows di nstat). - Kisaran angka: Batas atas kernel Linux (somaxconn) secara default 4.096 sejak versi 5.4 (sebelumnya 128), tetapi jika kode server memberikan nilai yang lebih kecil ke listen, nilai itulah yang menjadi batasnya. Saat antrean penuh, Linux membuang permintaan koneksi diam-diam tanpa error. OS klien mengirim ulang permintaan beberapa kali mulai 1 detik kemudian, sehingga yang dilihat pemain adalah loading yang lama, tanpa pesan “Koneksi gagal”. Server Windows mengirim balik respons penolakan, sehingga klien langsung melihat “Koneksi gagal”. - Di grafik: Melonjak tepat setelah server dibuka (Jumlah overflow antrean koneksi (ListenOverflows), jumlah upaya koneksi) - Yang diperiksa: Periksa kenaikan TcpExtListenOverflows dan TcpExtListenDrops di nstat -az, lalu dengan ss -ltn bandingkan Recv-Q (jumlah koneksi yang menunggu accept) dan Send-Q (batas backlog) pada socket listen - Cocok jika: ListenOverflows naik saat koneksi membanjir, dan Recv-Q socket listen menempel di nilai Send-Q - Tidak cocok jika: ListenOverflows tidak berubah: bukan penyebab ini. Koneksi sudah terbentuk tetapi loading tidak selesai: lebih mungkin “Lonjakan login dan N+1 query”. Tertahan tepat di jumlah pemain tertentu: lebih mungkin “Batas file descriptor” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · backlog pada listen dipotong diam-diam jika melebihi somaxconn; somaxconn default 4.096 (sejak 5.4, sebelumnya 128); saat antrean penuh, permintaan bisa diabaikan dan diserahkan ke percobaan ulang klien - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_syn_retries: permintaan koneksi (SYN) dikirim ulang beberapa kali dengan jeda retransmisi pertama 1 detik; tcp_abort_on_overflow default nonaktif (tidak ada respons penolakan walaupun antrean meluap); tcp_syncookies default aktif - [listen function (winsock2.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen) · Microsoft · Di Windows, jika antrean penuh, klien menerima error WSAECONNREFUSED - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtListenOverflows: jumlah permintaan koneksi (SYN) yang dibuang karena antrean accept penuh; saat itu TcpExtListenDrops juga ikut naik - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK #### so-fd · Batas file descriptor · File descriptor limit (ulimit) Setiap koneksi membutuhkan satu file descriptor (fd, nomor yang diberikan OS untuk file dan socket yang terbuka), dan jumlah fd yang bisa dibuka oleh satu proses dibatasi. - Mengapa → Akibatnya → Di layar: Jumlah pemain online bersamaan mencapai batas file descriptor proses → Server tidak bisa menerima koneksi baru (Too many open files). Membuka file log dan koneksi DB juga ikut gagal → Begitu jumlah pemain mencapai angka tertentu, tidak ada lagi yang bisa masuk: pemain baru gagal masuk atau terjebak loading tanpa henti - Gejala: Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Seluruh server / Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Tutup socket dengan pasti saat koneksi diakhiri (mencegah kebocoran fd), jika accept gagal dengan EMFILE (fd habis) hentikan sementara penerimaan koneksi atau terima koneksi dengan fd cadangan yang sudah disisihkan lalu langsung tutup (agar CPU tidak terbuang untuk memproses notifikasi koneksi yang sama berulang-ulang). - Tugas Tim Infrastruktur: Periksa ulimit dan konfigurasi service (LimitNOFILE di systemd), pasang alert saat mendekati batas. - Kisaran angka: Di Linux, jika service tidak dikonfigurasi khusus, batasnya masih sering 1.024. Server game biasanya menaikkannya ke puluhan ribu hingga ratusan ribu. Windows tidak punya batas default serendah ini. - Di grafik: Mendatar di batas (Jumlah fd terbuka pada proses, jumlah koneksi bersamaan) - Yang diperiksa: Periksa fd-nr (jumlah file descriptor yang terbuka) proses server game dengan pidstat -v dan batas jumlah file terbuka di /proc/PID/limits, lalu cari kegagalan accept (EMFILE, Too many open files) di log server - Cocok jika: Jumlah fd mendatar di nilai batas, dan sejak saat itu accept gagal dengan EMFILE - Tidak cocok jika: Jumlah fd masih jauh di bawah batas: bukan penyebab ini. Permintaan koneksi dibuang di kernel: lebih mungkin “Antrean koneksi (backlog) meluap”. Masalahnya di connection tracking: lebih mungkin “Tabel conntrack server penuh” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Koneksi yang tidak diterima tetap tertinggal di antrean koneksi (backlog) kernel. Akibatnya, tergantung kodenya, server bisa terus menerima notifikasi “ada koneksi baru” dan membuang-buang CPU. - Sumber: - [systemd-system.conf(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd-system.conf.5.html) · systemd · Nilai default DefaultLimitNOFILE untuk service adalah 1024:524288 (soft limit 1.024) - [accept(2) — Linux manual page](https://man7.org/linux/man-pages/man2/accept.2.html) · Linux man-pages · Saat batas fd proses tercapai, accept gagal dengan EMFILE - [Maximum Number of Sockets Supported](https://learn.microsoft.com/en-us/windows/win32/winsock/maximum-number-of-sockets-supported-2) · Microsoft · Winsock di Windows membatasi jumlah socket hanya berdasarkan memori yang tersedia - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · fd-nr pada -v: jumlah file descriptor yang dibuka proses - [proc_pid_limits(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_pid_limits.5.html) · Linux man-pages · /proc/PID/limits berisi nilai soft dan hard batas sumber daya per proses #### so-sockbuf · Buffer socket kernel terlalu kecil · Small socket buffers Jika buffer kirim dan buffer terima kecil, saat burst trafik datang paket yang diterima lewat UDP dibuang, dan pengiriman TCP tertahan karena buffer tidak punya ruang. - Mengapa → Akibatnya → Di layar: SO_SNDBUF dan SO_RCVBUF masih default atau terlalu kecil → Saat burst atau saat thread penerima tertahan sebentar, buffer terima UDP meluap dan paket dibuang; TCP menunggu karena buffer kirim tidak punya ruang → Teleport (packet loss UDP) atau fast forward (TCP menunggu) - Gejala: Teleport, Fast forward / Faktor: Packet loss, Stall - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Atur ukuran buffer (SO_SNDBUF, SO_RCVBUF) di kode sesuai trafik, ingat bahwa untuk TCP menetapkan ukuran secara manual mematikan auto-tuning Linux, jangan pakai ukuran terlalu besar karena data lama menumpuk di buffer dan latensi bertambah, jaga agar thread penerima tidak tertahan. - Tugas Tim Infrastruktur: Sesuaikan batas atas kernel (rmem_max dan wmem_max; ukuran buffer yang diatur di kode juga tidak bisa melewati nilai ini) dan nilai default (rmem_default), pantau counter buffer meluap (RcvbufErrors). - Kisaran angka: Default buffer terima UDP di Linux sekitar 208 KB. Satu paket kecil pun memakan memori kernel jauh lebih besar dari ukuran aslinya, jadi puluhan hingga ratusan paket sudah cukup untuk memenuhinya. Di server yang menerima 100.000 paket per detik, buffer meluap walaupun thread penerima hanya tertahan beberapa ms. - Di grafik: Melonjak acak sesekali (Buffer terima UDP meluap (UdpRcvbufErrors)) - Yang diperiksa: Periksa kenaikan UdpRcvbufErrors di nstat -az dan skmem di ss -uamn (rb adalah ukuran buffer terima, d adalah jumlah paket yang dibuang karena tidak bisa dimasukkan ke socket). Untuk TCP, periksa skmem di ss -tm, apakah memori antrean kirim (w) sudah mencapai ukuran buffer kirim (tb) - Cocok jika: UdpRcvbufErrors (atau d pada socket) naik saat burst atau saat thread penerima tertahan, dan rb di sekitar nilai default (kira-kira 208 KB). Untuk TCP, w menempel di tb dan send tertahan - Tidak cocok jika: Counter tidak berubah tetapi ada packet loss: lebih mungkin di tahap NIC (“Ring buffer terlalu kecil”) atau di jalur jaringan - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · Default SO_RCVBUF dan SO_SNDBUF adalah rmem_default dan wmem_default, batas atasnya rmem_max dan wmem_max; kernel menggandakan nilai yang diatur - [include/net/sock.h (Linux v6.18)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/sock.h?h=v6.18) · Linux kernel · Buffer socket default didefinisikan sebesar 256 paket berukuran 256 byte termasuk overhead sk_buff (SKB_TRUESIZE(256)×256); frame kecil pun dihitung sebesar sk_buff+MTU (sekitar 208 KB adalah hasil hitungan untuk x86-64) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_rmem dan tcp_wmem: jika SO_RCVBUF dan SO_SNDBUF ditetapkan langsung, auto-tuning ukuran untuk socket itu mati - [net/ipv4/udp.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/udp.c?h=v6.12) · Linux kernel · Jika antrean terima UDP melebihi ukuran buffer socket, paket langsung dibuang dan RcvbufErrors naik - [net/ipv4/proc.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Nama counter yang ditampilkan nstat: RcvbufErrors dan SndbufErrors di grup Udp - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · skmem pada -m: rb ukuran buffer terima, tb ukuran buffer kirim, w memori antrean kirim, d jumlah paket yang dibuang sebelum masuk ke socket #### so-context · Thread berlebihan dan context switching · Thread oversubscription, context switching Jika jumlah thread jauh melebihi jumlah core, OS menghabiskan CPU hanya untuk menjalankan thread-thread itu secara bergiliran. - Mengapa → Akibatnya → Di layar: Ada ratusan hingga ribuan thread, misalnya karena setiap koneksi dibuatkan thread sendiri → Biaya context switching (pergantian thread yang berjalan) dan cache miss meningkat → CPU sibuk tetapi throughput rendah dan tick tidak beraturan, sehingga terjadi patah-patah atau slow motion - Gejala: Patah-patah, Slow motion / Faktor: Stall, Jitter - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Sesuaikan jumlah thread dengan jumlah core, gunakan I/O asinkron (epoll, IOCP). - Tugas Tim Infrastruktur: Pantau jumlah context switching dan jumlah thread yang menunggu dijalankan (cs dan r di vmstat). - Kisaran angka: Satu kali context switching memakan beberapa µs, dan menjadi lebih besar jika ditambah biaya cache miss sesudahnya. - Di grafik: Naik mengikuti beban (Jumlah context switching per detik, jumlah thread yang menunggu dijalankan) - Yang diperiksa: Bandingkan cs (context switching per detik) dan r (jumlah yang sedang berjalan atau menunggu CPU) di vmstat 1 dengan jumlah core, lalu periksa context switching voluntary (cswch/s) dan involuntary (nvcswch/s) per thread server game dengan pidstat -w -t - Cocok jika: Saat jumlah pemain online bertambah, r naik jauh melebihi jumlah core dan cs ikut melonjak, serta ada ratusan thread dengan banyak context switching involuntary - Tidak cocok jika: r tetap sama dengan atau di bawah jumlah core: bukan penyebab ini. Hanya context switching voluntary yang banyak: thread sedang menunggu lock atau I/O (“Perebutan lock”, “Arsitektur I/O blocking”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Quantifying The Cost of Context Switch (ExpCS 2007)](https://www.usenix.org/legacy/events/expcs07/papers/2-li.pdf) · ACM · Biaya langsung context switching sekitar 3,8 µs; biaya tidak langsung termasuk efek cache berkisar dari beberapa µs hingga lebih dari 1.000 µs (sesuai lingkungan pengukuran) - [vmstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/vmstat.8.html) · procps-ng · Kolom cs (jumlah context switching per detik) dan r (jumlah proses yang sedang berjalan atau menunggu dijalankan) - [I/O Completion Ports](https://learn.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports) · Microsoft · Memproses banyak I/O asinkron dengan thread pool yang dibuat lebih dulu dan IOCP, serta menyesuaikan jumlah thread yang berjalan bersamaan dengan konkurensi CPU - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · cswch/s pada -w adalah context switching voluntary (thread berhenti sendiri karena menunggu sumber daya), nvcswch/s adalah context switching involuntary (dipaksa berganti karena time slice habis), -t untuk melihat per thread #### so-steal · CPU steal (virtual machine) · CPU steal time Server game berhenti selama server fisik (hypervisor) sementara memberikan waktu CPU milik virtual machine ini ke virtual machine lain (CPU steal). - Mengapa → Akibatnya → Di layar: Virtual machine lain di host yang sama memakai banyak CPU → Virtual machine server game kehilangan jatah eksekusi selama beberapa hingga puluhan ms setiap kali → Waktu tick melonjak tanpa sebab yang jelas, sehingga terjadi patah-patah atau freeze - Gejala: Patah-patah, Freeze / Faktor: Stall - Siapa: Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Infrastruktur: Pantau metrik steal (st di top dan vmstat), gunakan core atau host khusus (dedicated), hindari instance burstable yang melambat saat kredit CPU habis, hentikan lalu jalankan lagi instance yang steal-nya terus tinggi agar pindah ke host lain. - Tugas Pihak Eksternal: Laporkan ke penyedia cloud host yang steal-nya terus tinggi. - Di grafik: Melonjak acak sesekali (%steal, waktu tick server) - Yang diperiksa: Tampilkan %steal dari mpstat -P ALL 1 pada sumbu waktu yang sama dengan waktu tick server - Cocok jika: %steal ikut melonjak saat tick melonjak, dan turun setelah instance dihentikan lalu dijalankan lagi sehingga pindah ke host lain - Tidak cocok jika: %steal mendekati 0 tetapi tick tetap melonjak: penyebabnya di dalam server game (“Jeda GC stop-the-world di server”, “Perebutan lock”). Jika memakai container: lebih mungkin “CPU throttling di container (kuota CFS)” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [proc_stat(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_stat.5.html) · Linux man-pages · steal: waktu yang direbut karena sistem operasi lain sedang berjalan di lingkungan virtualisasi - [Standard mode for burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) · AWS · Instance burstable memakai kredit untuk melampaui performa dasar (baseline), dan saat kredit habis, utilisasi CPU turun ke tingkat baseline - [How EC2 instance stop and start works](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-ec2-instance-stop-start-works.html) · AWS · Jika instance dihentikan lalu dijalankan lagi, sebagian besar akan dipindahkan ke host baru - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · %steal: persentase waktu vCPU ini terpaksa menunggu selama hypervisor menjalankan vCPU lain #### so-cpu-quota · CPU throttling di container (kuota CFS) · Container CPU throttling (CFS quota) Jika container diberi batas CPU, begitu kuota dalam satu periode (biasanya 100 ms) habis, container dipaksa berhenti selama sisa periode itu (throttling). - Mengapa → Akibatnya → Di layar: Batas CPU (limit) dipasang pada container server game, misalnya di Kubernetes → Saat perhitungan tick menumpuk, kuota habis dan proses berhenti puluhan ms sampai periode berikutnya → Rata-rata CPU rendah tetapi tick melonjak secara berkala, sehingga terjadi patah-patah atau slow motion - Gejala: Patah-patah, Slow motion / Faktor: Stall, Jitter - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul, Sesekali secara acak - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Sesuaikan jumlah worker thread dengan batas CPU (agar runtime tidak membuat thread sebanyak seluruh core host). - Tugas Tim Infrastruktur: Beri batas CPU yang longgar atau hapus batasnya dan alokasikan core khusus, pantau jumlah throttling (nr_throttled). - Kisaran angka: Pada server dengan batas 2 core, jika 8 thread bekerja bersamaan, kuota periode 100 ms habis dalam 25 ms dan proses berhenti selama 75 ms. - Di grafik: Naik mengikuti beban (Jumlah throttling (nr_throttled), waktu tick server) - Yang diperiksa: Periksa kenaikan nr_throttled dan throttled_usec (di cgroup v1: nr_throttled dan throttled_time) di cpu.stat cgroup container bersama waktu tick server - Cocok jika: Rata-rata utilisasi CPU di bawah batas, tetapi nr_throttled dan throttled_usec terus naik dan waktunya bertepatan dengan lonjakan tick - Tidak cocok jika: nr_throttled tidak naik: bukan penyebab ini. Virtual machine itu sendiri yang tertahan: lebih mungkin “CPU steal (virtual machine)” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [CFS Bandwidth Control](https://docs.kernel.org/scheduler/sched-bwc.html) · Linux kernel · Jika kuota yang diterima di setiap periode habis, thread berhenti sampai periode berikutnya (throttling); periode default 100 ms; statistik nr_throttled - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) · Linux kernel · cpu.max berformat “$MAX $PERIOD” (kuota, periode), dengan nilai default “max 100000” (periode 100 ms) - [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) · Kubernetes · CPU limit pada container adalah batas keras (hard limit) yang ditegakkan kernel melalui CPU throttling #### so-cstate · Lonjakan latensi akibat manajemen daya server (C-state, pengaturan frekuensi) · CPU power management latency (C-states, frequency scaling) Core CPU yang sedang menganggur masuk ke mode hemat daya yang dalam (C-state) dan menurunkan frekuensinya untuk menghemat listrik. Saat paket atau timer datang, core butuh waktu untuk bangun dan menaikkan frekuensi, sehingga pemrosesan paket kecil mendapat tambahan latensi. - Mengapa → Akibatnya → Di layar: Kebijakan pengaturan frekuensi OS (governor) atau pengaturan daya BIOS mengizinkan C-state yang dalam dan frekuensi rendah → Setiap kali core yang menganggur bangun dari mode hemat daya yang dalam, ada keterlambatan hingga ratusan µs; jika frekuensi tertahan rendah, perhitungan tick itu sendiri menjadi lambat → Biasanya sulit dirasakan, tetapi jika pemanggilan antarserver banyak, keterlambatan menumpuk dan muncul input lag yang justru terjadi saat server sepi. Jika frekuensi tertahan rendah, tick tertinggal saat pemain ramai dan terjadi slow motion - Gejala: Input lag, Slow motion / Faktor: Latensi, Jitter, Stall - Siapa: Seluruh server / Kapan: Selalu, Sesekali secara acak - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Atur daya BIOS ke mode performa, set governor OS ke performance (scaling_governor di cpufreq), batasi C-state yang dalam pada server yang peka latensi (profil tuned latency-performance, /dev/cpu_dma_latency di PM QoS, parameter kernel intel_idle.max_cstate), setelah diubah bandingkan waktu pulang-pergi di dalam data center yang sama, jitter waktu tick, dan pemakaian daya. - Kisaran angka: Menurut tabel driver intel_idle di Linux 6.12, C1 yang dangkal pada CPU server Intel butuh 1–2 µs untuk bangun, sedangkan C6 yang dalam butuh 133 µs (Skylake-SP) hingga 290 µs (Sapphire Rapids). Sekali saja memang kecil, tetapi jika satu permintaan melewati beberapa server, keterlambatan itu menumpuk sebanyak jumlah servernya. Kernel memilih state yang makin dalam jika waktu idle yang diperkirakan makin panjang, jadi gejala ini lebih sering muncul di server sepi yang paketnya datang jarang-jarang. Governor powersave pada cpufreq umum mengunci frekuensi di nilai terendah dalam rentang yang diizinkan (algoritma intel_pstate dengan nama yang sama mengatur frekuensi sesuai beban). - Di grafik: Selalu tinggi sejak awal (Waktu pulang-pergi di dalam data center yang sama, frekuensi core) - Yang diperiksa: Periksa persentase waktu di setiap C-state per core dan frekuensi sebenarnya dengan cpupower monitor, lalu periksa name, latency (µs yang dibutuhkan untuk bangun), dan usage tiap state di bawah /sys/devices/system/cpu/cpu0/cpuidle/, scaling_governor di cpufreq, serta profil aktif dengan tuned-adm active - Cocok jika: Saat sepi, core lama berada di C-state terdalam atau frekuensinya tertahan di dekat nilai terendah, dan setelah diganti ke governor performance dan C-state dangkal, waktu pulang-pergi dan jitter permintaan kecil berkurang - Tidak cocok jika: Setelah diubah selisihnya hanya puluhan µs atau kurang: penyebab ini bisa diabaikan. Melonjak dalam satuan ms: lebih mungkin “CPU steal (virtual machine)” atau lapisan lain - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Untuk server bare metal di data center, periksa pengaturan daya BIOS (firmware) bersama pengaturan OS. Di cloud, hanya sebagian jenis instance yang mengizinkan OS mengubah C-state dan frekuensi; di AWS, pengaturan default mengutamakan performa maksimum, jadi sebagian besar bisa dibiarkan apa adanya. Profil tuned latency-performance di keluarga Red Hat menetapkan governor ke performance dan memakai PM QoS agar hanya C-state dangkal yang dipakai. Mematikan fitur hemat daya menaikkan konsumsi listrik, jadi terapkan hanya pada server yang peka terhadap latensi. - Sumber: - [CPU Idle Time Management](https://docs.kernel.org/admin-guide/pm/cpuidle.html) · Linux kernel · Setiap mode hemat daya punya waktu bangun (exit latency) dan waktu tinggal minimum (target residency), dan state yang dalam dipilih sesuai waktu idle yang diperkirakan; latency, usage, dan time per state ada di sysfs; state yang dalam dibatasi dengan PM QoS (/dev/cpu_dma_latency) dan intel_idle.max_cstate - [drivers/idle/intel_idle.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/idle/intel_idle.c?h=v6.12) · Linux kernel · Waktu bangun per C-state pada CPU server Intel: Skylake-SP C1 2 µs, C1E 10 µs, C6 133 µs; Ice Lake C6 170 µs; Sapphire Rapids C1 1 µs, C6 290 µs - [CPU Performance Scaling](https://docs.kernel.org/admin-guide/pm/cpufreq.html) · Linux kernel · Periksa dan ubah governor dengan scaling_governor; performance meminta frekuensi tertinggi dalam rentang yang diizinkan, powersave meminta frekuensi terendah - [intel_pstate CPU Performance Scaling Driver](https://docs.kernel.org/admin-guide/pm/intel_pstate.html) · Linux kernel · Algoritma powersave pada intel_pstate berbeda dari governor powersave umum karena mengatur frekuensi sesuai beban (mirip schedutil dan ondemand) - [Chapter 2. Getting started with TuneD](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/getting-started-with-tuned_monitoring-and-managing-system-status-and-performance) · Red Hat · Profil latency-performance mematikan fitur hemat daya, menetapkan governor ke performance, dan memakai PM QoS agar hanya C-state dangkal yang dipakai; profil aktif diperiksa dengan tuned-adm active - [tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/power/cpupower/man/cpupower-monitor.1?h=v6.12) · Linux kernel · cpupower monitor: statistik frekuensi dan mode hemat daya per core - [Processor state control for Amazon EC2 Linux instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) · AWS · Hanya sebagian jenis instance yang mengizinkan OS mengontrol C-state dan P-state, dan keduanya bisa diubah untuk menurunkan latensi; pengaturan default adalah performa maksimum sehingga cocok untuk sebagian besar beban kerja; Graviton memakai frekuensi tetap sehingga OS tidak mengontrolnya #### so-oom · OOM killer · Out-of-memory killer Saat memori habis, Linux memilih proses yang memakai memori paling banyak lalu mematikannya secara paksa. Biasanya proses itu adalah server game. - Mengapa → Akibatnya → Di layar: Memori habis karena kebocoran atau lonjakan pemakaian, atau batas memori container tercapai → Kernel menghentikan paksa proses server game → Semua pemain di server itu disconnect bersamaan, dan progres terakhir bisa hilang karena rollback - Gejala: Disconnect, Aksi hilang / rollback / Faktor: Stall - Siapa: Seluruh server / Kapan: Makin lama menyala, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Perbaiki kebocoran, tetapkan batas atas pemakaian memori dan siapkan prosedur untuk menyimpan data lalu mematikan server secara normal saat batas itu mendekat. - Tugas Tim Infrastruktur: Pasang alert memori, atur batas memori container sesuai pemakaian sebenarnya, sesuaikan urutan proses yang dimatikan lebih dulu (oom_score_adj). - Kisaran angka: Log kernel (dmesg) mencatat “Out of memory: Killed process”, dan di Kubernetes terlihat sebagai OOMKilled. Windows tidak punya OOM killer; yang sering terjadi adalah alokasi memori gagal lalu server mati karena error. - Di grafik: Koneksi putus serentak (Jumlah koneksi, pemakaian memori) - Yang diperiksa: Cocokkan catatan “Out of memory: Killed process” di dmesg, status OOMKilled pada pod (di Kubernetes), atau kenaikan oom_kill di memory.events (di cgroup v2) dengan waktu koneksi terputus - Cocok jika: Pada waktu koneksi putus serentak, ada catatan proses server game dimatikan, dan sampai sesaat sebelumnya pemakaian memori naik hingga batas - Tidak cocok jika: Tidak ada catatan OOM tetapi prosesnya mati: periksa log crash dan core dump yang dibahas di “Crash di server” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [mm/oom_kill.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/oom_kill.c?h=v6.12) · Linux kernel · Skor dihitung sehingga proses yang memakai memori paling banyak mendapat skor tertinggi (oom_score_adj ikut diperhitungkan), dan saat mematikan proses dicatat “Out of memory: Killed process …” - [Assign Memory Resources to Containers and Pods](https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/) · Kubernetes · Jika container terus memakai memori melebihi limit, container dihentikan dan statusnya ditampilkan sebagai OOMKilled - [Pushing the Limits of Windows: Virtual Memory](https://learn.microsoft.com/en-us/archive/blogs/markrussinovich/pushing-the-limits-of-windows-virtual-memory) · Microsoft · Di Windows, saat commit limit tercapai, alokasi yang meng-commit memori gagal, dan ini bisa berujung pada error aplikasi atau gangguan sistem - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) · Linux kernel · oom_kill di memory.events: jumlah proses yang dimatikan OOM killer di cgroup ini #### so-reclaim · Jeda akibat reclaim dan compaction memori · Memory compaction / reclaim stalls (THP) Proses berhenti selama OS memadatkan memori (compaction) untuk membuat halaman besar (huge page) atau mengambil kembali memori (reclaim) agar tersedia ruang kosong. - Mengapa → Akibatnya → Di layar: Memori kosong menipis, atau fitur halaman besar (THP) menjalankan compaction memori → Thread yang meminta memori menunggu sampai reclaim dan compaction selesai → Server berhenti secara tidak teratur (beberapa ms hingga ratusan ms) - Gejala: Freeze, Patah-patah / Faktor: Stall - Siapa: Seluruh server / Kapan: Makin lama menyala, Sesekali secara acak - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kurangi alokasi memori besar saat server berjalan (alokasikan lebih dulu saat startup lalu pakai ulang). - Tugas Tim Infrastruktur: Atur halaman besar (THP) agar hanya dipakai di tempat yang membutuhkannya (madvise), naikkan batas memori kosong (vm.min_free_kbytes dan lainnya). - Di grafik: Melonjak acak sesekali (Waktu tick server, PSI memori) - Yang diperiksa: Periksa some dan full di /proc/pressure/memory (persentase waktu berhenti karena menunggu memori) serta kenaikan compact_stall di /proc/vmstat bersama waktu tick server, lalu periksa pengaturan /sys/kernel/mm/transparent_hugepage/defrag - Cocok jika: PSI memori naik dan compact_stall bertambah saat tick melonjak. defrag bernilai always - Tidak cocok jika: PSI dan compact_stall tidak berubah: bukan penyebab ini. Pemakaian swap naik: lebih mungkin “Swap” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Transparent Hugepage Support](https://docs.kernel.org/admin-guide/mm/transhuge.html) · Linux kernel · Jika defrag=always, saat alokasi THP gagal, reclaim dan compaction memori dilakukan saat itu juga sehingga proses berhenti; madvise hanya melakukannya untuk area yang memintanya - [Documentation for /proc/sys/vm/](https://docs.kernel.org/admin-guide/sysctl/vm.html) · Linux kernel · min_free_kbytes: batas memori kosong minimum (watermark) yang disisakan kernel - [PSI - Pressure Stall Information](https://docs.kernel.org/accounting/psi.html) · Linux kernel · some (persentase waktu sebagian tugas berhenti karena menunggu memori) dan full (persentase waktu semua tugas berhenti) di /proc/pressure/memory #### so-timejump · Lompatan jam sistem (NTP step) · Wall-clock jump (NTP step) Jika jam server disesuaikan beberapa detik maju atau mundur sekaligus, timer yang bergantung pada jam sistem terpicu bersamaan atau berhenti. - Mengapa → Akibatnya → Di layar: Sinkronisasi waktu menggeser jam dalam jumlah besar sekaligus → Timer terpicu bertumpuk atau berhenti, dan timeout dinilai keliru → Buff dan cooldown kacau, disconnect serentak, fast forward - Gejala: Fast forward, Disconnect, Aksi hilang / rollback / Faktor: Stall - Siapa: Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Hitung waktu berlalu, timeout, dan cooldown dengan monotonic clock yang tidak melompat atau mundur, pakai wall clock hanya untuk tampilan dan pencatatan. - Tugas Tim Infrastruktur: Sesuaikan jam secara perlahan (makestep di chrony hanya tepat setelah dinyalakan), pantau status sinkronisasi waktu (selisih jam). - Kisaran angka: ntpd langsung menyamakan jam sekaligus jika selisihnya lebih dari 0,128 detik; jika lebih kecil, jam disesuaikan perlahan dengan kecepatan yang butuh lebih dari 30 menit untuk menghapus selisih 1 detik. chrony, yang kini banyak dipakai, dengan pengaturan yang disarankan (makestep) hanya menyamakan sekaligus beberapa kali tepat setelah dinyalakan, lalu menyesuaikan perlahan sesudahnya. Jam juga melompat saat virtual machine berhenti sebentar lalu berjalan lagi. - Di grafik: Melonjak acak sesekali (Jumlah timer terpicu dan jumlah disconnect, catatan penyesuaian jam) - Yang diperiksa: Cari catatan penyesuaian jam yang besar sekaligus di log layanan sinkronisasi waktu, lalu cocokkan dengan waktu terjadinya anomali. chrony mencatat ke syslog jika penyesuaian lebih besar dari nilai logchange (default 1 detik) - Cocok jika: Ada catatan penyesuaian jam pada waktu buff dan cooldown kacau, disconnect serentak, atau fast forward terjadi, dan besar penyesuaiannya mirip dengan besar anomali - Tidak cocok jika: Tidak ada catatan penyesuaian jam: bukan penyebab ini. Jika memakai virtual machine, periksa juga kemungkinan VM berhenti lalu berjalan lagi (“Maintenance host cloud dan live migration”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [ntpd - Network Time Protocol (NTP) daemon](https://www.ntp.org/documentation/4.2.8-series/ntpd/) · Network Time Foundation · Jika selisih melewati ambang step 128 ms, jam disamakan sekaligus; jika lebih kecil, disesuaikan perlahan dengan kecepatan 0,5 ms per detik, sehingga menyamakan 1 detik butuh 2.000 detik (sekitar 33 menit) - [chrony – Frequently Asked Questions](https://chrony-project.org/faq.html) · chrony · Disarankan hanya mengizinkan step beberapa kali tepat setelah start, seperti makestep 1 3; virtual machine yang berhenti lalu dilanjutkan bisa bangun dengan jam yang sudah meleset - [clock_gettime(2) — Linux manual page](https://man7.org/linux/man-pages/man2/clock_gettime.2.html) · Linux man-pages · CLOCK_MONOTONIC tidak terpengaruh lompatan tidak kontinu pada jam sistem dan tidak berjalan mundur - [chrony.conf(5)](https://chrony-project.org/doc/4.6/chrony.conf.html) · chrony · logchange: jika jam disesuaikan lebih besar dari nilai ini (default 1 detik), penyesuaian dicatat ke syslog #### so-cron · Tugas terjadwal · Cron jobs (log rotation, backup, scans) Kompresi log, backup, dan pemindaian keamanan yang berjalan pada jam yang sama setiap hari menyita CPU dan disk. - Mengapa → Akibatnya → Di layar: Tugas OS dijalankan pada waktu yang sudah ditentukan → Server game harus berbagi CPU dan disk dengan tugas tersebut → Patah-patah atau slow motion pada waktu tertentu, misalnya setiap pukul 04.00 dini hari - Gejala: Patah-patah, Slow motion / Faktor: Stall - Siapa: Seluruh server / Kapan: Secara berkala - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Sebar waktu eksekusi tugas, turunkan prioritasnya (nice, ionice), pisahkan dari server game (jalankan di server terpisah). - Di grafik: Melonjak secara berkala (Utilisasi CPU, antrean disk, waktu tick server) - Yang diperiksa: Kumpulkan waktu eksekusi tugas terjadwal dari crontab dan systemctl list-timers, lalu pada waktu tick melonjak periksa proses mana yang memakai CPU dan disk dengan pidstat -u -d - Cocok jika: Tick melonjak di jam yang sama setiap hari (atau setiap jam), dan pada saat itu proses tugas terjadwal menyita CPU dan disk - Tidak cocok jika: Waktu lonjakan tidak cocok dengan jam yang sama setiap hari: bukan penyebab ini. Melonjak dengan interval beberapa detik atau beberapa menit: lebih mungkin “Jeda GC stop-the-world di server” atau “Timer terpicu serentak” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [ionice(1) — Linux manual page](https://man7.org/linux/man-pages/man1/ionice.1.html) · util-linux · Tugas dengan kelas idle hanya mendapat I/O saat program lain tidak memakai disk - [systemd.timer(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd.timer.5.html) · systemd · RandomizedDelaySec menunda waktu tugas terjadwal secara acak untuk mengurangi penumpukan beban - [systemctl(1) — Linux manual page](https://man7.org/linux/man-pages/man1/systemctl.1.html) · systemd · list-timers: menampilkan unit timer menurut urutan waktu eksekusi berikutnya - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -u menampilkan CPU, -d menampilkan I/O disk per proses #### so-os-update · Perubahan performa setelah update OS, kernel, driver, atau firmware · Performance regression after OS / kernel / driver / firmware update Kode game tidak berubah, tetapi server menjadi lambat sejak OS, kernel, driver, atau firmware server diperbarui. Update bisa mengubah nilai default, scheduler, mitigasi kerentanan CPU (mitigations), dan perilaku driver. - Mengapa → Akibatnya → Di layar: Kernel, driver, atau firmware berubah karena patch keamanan rutin atau image server baru → Nilai default atau scheduler berubah, atau mitigasi kerentanan baru aktif, sehingga pekerjaan yang sama butuh waktu CPU lebih banyak dan urutan thread mendapat jatah CPU berubah → Server yang tadinya lancar selalu sedikit lebih lambat sejak hari update, sehingga terjadi input lag, dan saat pemain ramai terjadi patah-patah atau slow motion - Gejala: Input lag, Patah-patah, Slow motion / Faktor: Latensi, Stall, Jitter - Siapa: Seluruh server / Kapan: Selalu, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Terapkan update ke sebagian server lebih dulu dan bandingkan waktu tick, latensi, dan utilisasi CPU dengan versi sebelumnya sebelum diperluas, deploy di hari yang berbeda dari patch game, catat versi kernel, driver, dan firmware serta nilai sysctl penting sebelum dan sesudah update, jika muncul masalah boot dengan kernel sebelumnya untuk memastikan, putuskan pengaturan yang mematikan mitigasi (mitigations=off) setelah menimbang risiko keamanannya. - Kisaran angka: Jika versi kernel berubah, perilaku default juga berubah. Misalnya, sejak 6.6 Linux mulai beralih dari scheduler CFS ke EEVDF, dan nilai default batas antrean koneksi (somaxconn) berubah dari 128 menjadi 4.096 sejak 5.4. Mitigasi kerentanan CPU menambah pekerjaan, misalnya mengosongkan buffer internal CPU saat kembali dari kernel ke program (setiap kali system call selesai) serta saat context switching dan peralihan virtual machine. Akibatnya, server jaringan yang memanggil system call untuk setiap paket lebih terpengaruh. Untuk menutup sebagian kerentanan secara penuh, SMT (fitur yang membuat satu core bekerja seperti dua thread) harus dimatikan, dan mematikan SMT bisa menurunkan performa secara drastis tergantung beban kerjanya. Parameter kernel mitigations=off mematikan semua mitigasi ini sehingga performa kembali, tetapi server terbuka terhadap kerentanan. - Di grafik: Naik seperti anak tangga (Waktu tick server, utilisasi CPU, latensi pada beban yang sama) - Yang diperiksa: Cocokkan riwayat update di package manager dan waktu reboot, versi kernel dari uname -r, serta informasi driver NIC dari ethtool -i dengan waktu latensi naik. Bandingkan server yang sudah dan belum diperbarui pada beban yang sama dengan mpstat dan pidstat, lalu bandingkan juga status mitigasi di /sys/devices/system/cpu/vulnerabilities/ - Cocok jika: Latensi dan utilisasi CPU naik satu tingkat sejak reboot setelah update lalu tetap di sana, dan pada beban yang sama hanya server yang sudah diperbarui yang tinggi. Kembali normal jika boot dengan kernel atau driver sebelumnya - Tidak cocok jika: Server yang sudah dan belum diperbarui sama lambatnya pada beban yang sama: bukan penyebab ini. Patch game juga dirilis di hari yang sama dan jumlah atau ukuran paket per pemain berubah: lebih mungkin “Pola trafik berubah akibat patch” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Status mitigasi diperiksa di file-file di bawah /sys/devices/system/cpu/vulnerabilities/. Nilai default (mitigations=auto) melakukan mitigasi dengan SMT tetap aktif, tetapi dengan auto,nosmt SMT dimatikan pada CPU yang rentan, sehingga setelah kernel diperbarui jumlah core logis bisa berkurang setengah. Jika OS diperbarui di hari yang sama dengan patch game, penyebabnya sulit dibedakan, jadi deploy keduanya secara terpisah. - Sumber: - [The kernel’s command-line parameters](https://docs.kernel.org/admin-guide/kernel-parameters.html) · Linux kernel · mitigations=: off mematikan semua mitigasi kerentanan CPU untuk menaikkan performa tetapi membuka celah kerentanan; default auto melakukan mitigasi dengan SMT tetap aktif; auto,nosmt mematikan SMT jika perlu - [MDS - Microarchitectural Data Sampling](https://docs.kernel.org/admin-guide/hw-vuln/mds.html) · Linux kernel · Mitigasi mengosongkan buffer CPU saat kembali dari kernel ke user space dan saat masuk ke virtual machine; status kerentanan dan mitigasi diperiksa lewat file di bawah /sys/devices/system/cpu/vulnerabilities/; pada banyak CPU, perlindungan penuh mengharuskan SMT dimatikan, dan mematikan SMT berdampak besar pada performa tergantung beban kerjanya - [Spectre Side Channels](https://docs.kernel.org/admin-guide/hw-vuln/spectre.html) · Linux kernel · Untuk mitigasi, buffer branch prediction dikosongkan saat context switching dan peralihan virtual machine; mitigasi yang kuat menambah overhead pada semua program - [EEVDF Scheduler](https://docs.kernel.org/scheduler/sched-eevdf.html) · Linux kernel · Sejak 6.6, Linux mulai beralih dari CFS ke scheduler EEVDF - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Nilai default somaxconn berubah dari 128 menjadi 4.096 sejak Linux 5.4 - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Melihat informasi driver perangkat jaringan dengan ethtool -i #### so-conntrack · Tabel conntrack server penuh · conntrack table full Jika tabel connection tracking (conntrack), tempat firewall Linux mencatat semua koneksi, mencapai batasnya, paket baru dibuang. - Mengapa → Akibatnya → Di layar: Catatan koneksi bertambah karena lonjakan koneksi atau koneksi pendek yang berulang → Tabel penuh sehingga koneksi baru dan sebagian paket dibuang → Tidak bisa masuk, teleport akibat packet loss tanpa sebab yang jelas - Gejala: Tidak bisa masuk / loading tanpa henti, Teleport / Faktor: Packet loss - Siapa: Seluruh server / Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kurangi koneksi pendek (pakai ulang koneksi untuk pemanggilan antarserver). Klien: jika koneksi gagal atau terputus, perpanjang interval percobaan ulang secara bertahap dan sebar secara acak. - Tugas Tim Infrastruktur: Perbesar ukuran tabel (nf_conntrack_max), kecualikan port game dari pelacakan (NOTRACK di tabel raw), pasang alert pemakaian. - Kisaran angka: Batas default sekitar 60.000–260.000 entri, tergantung memori server. Jika meluap, log kernel mencatat “nf_conntrack: table full, dropping packet”. - Di grafik: Mendatar di batas (Jumlah entri conntrack (nf_conntrack_count)) - Yang diperiksa: Tampilkan net.netfilter.nf_conntrack_count (jumlah entri saat ini) dari sysctl dalam satu grafik dengan nf_conntrack_max, lalu cari “nf_conntrack: table full, dropping packet” di dmesg - Cocok jika: nf_conntrack_count mendatar di nilai max, dan sejak saat itu log kernel mencatat table full - Tidak cocok jika: Jumlah entri masih jauh di bawah max: bukan penyebab ini. Batas connection tracking milik instance AWS itu sendiri diperiksa lewat conntrack_allowance_exceeded di “Batas PPS cloud terlampaui” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Nilai default nf_conntrack_max sama dengan jumlah hash bucket (nf_conntrack_buckets), dan jumlah bucket ditentukan oleh ukuran memori - [net/netfilter/nf_conntrack_core.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_core.c?h=v6.12) · Linux kernel · Ukuran default 65.536 jika memori lebih dari 1 GB, 262.144 jika lebih dari 4 GB (64-bit); jika penuh, paket dibuang dengan catatan “nf_conntrack: table full, dropping packet” - [iptables-extensions(8) — Linux manual page](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) · netfilter · Mengecualikan dari connection tracking dengan CT --notrack di tabel raw #### so-ports · Port ephemeral habis pada koneksi antarserver · Ephemeral port exhaustion (TIME_WAIT) Jika server game sering membuka dan menutup koneksi singkat ke DB atau server lain, koneksi yang sudah ditutup tetap menahan port untuk sementara sehingga koneksi baru tidak bisa dibuka. - Mengapa → Akibatnya → Di layar: Koneksi baru dibuka dan ditutup untuk setiap permintaan → Pihak yang menutup koneksi lebih dulu menahan port selama sekitar 60 detik (Linux) dalam status TIME_WAIT, sehingga port yang bisa dipakai habis → Permintaan internal gagal, sehingga penyimpanan data gagal dan fitur mengalami error - Gejala: Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Seluruh server, Fitur tertentu saja / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Pakai ulang koneksi (connection pool), jangan membuka dan menutup koneksi baru untuk setiap permintaan. - Tugas Tim Infrastruktur: Perluas rentang port (ip_local_port_range), pertimbangkan pemakaian ulang TIME_WAIT untuk koneksi keluar (tcp_tw_reuse di Linux), pantau jumlah TIME_WAIT. - Kisaran angka: Rentang port default Linux (32768–60999) berisi sekitar 28.000 port. Jika koneksi baru ke alamat tujuan yang sama dibuat lebih dari 470 kali per detik, port akan habis. Windows punya sekitar 16.000 port default (49152–65535) dan TIME_WAIT-nya juga lebih lama, sehingga lebih cepat habis. - Di grafik: Mendatar di batas (Jumlah socket TIME_WAIT, jumlah kegagalan koneksi internal) - Yang diperiksa: Hitung socket TIME_WAIT per alamat tujuan dengan ss -tan state time-wait, lalu cari kegagalan connect (EADDRNOTAVAIL) di log server game - Cocok jika: TIME_WAIT ke tujuan yang sama (misalnya DB) mendatar di dekat batas rentang port ephemeral (default sekitar 28.000), dan connect gagal dengan EADDRNOTAVAIL - Tidak cocok jika: TIME_WAIT sedikit tetapi hanya koneksi keluar yang gagal: lebih mungkin “Batas koneksi dan port NAT gateway cloud” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: TIME_WAIT 60 detik di Linux adalah nilai tetap di kernel. Menurunkan tcp_fin_timeout, yang namanya mirip, tidak memperpendek TIME_WAIT. - Sumber: - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · ip_local_port_range default 32768–60999, tcp_tw_reuse, tcp_fin_timeout adalah lama status FIN_WAIT_2 dipertahankan - [include/net/tcp.h (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_TIMEWAIT_LEN(60*HZ): TIME_WAIT sekitar 60 detik adalah konstanta kernel - [TCP/IP port exhaustion troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-port-exhaustion-troubleshooting) · Microsoft · Port dinamis Windows default 49152–65535; koneksi yang sudah ditutup menahan port dalam status TIME_WAIT selama 4 menit secara default - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · Filter status state time-wait hanya menampilkan socket TIME_WAIT - [connect(2) — Linux manual page](https://man7.org/linux/man-pages/man2/connect.2.html) · Linux man-pages · EADDRNOTAVAIL: koneksi tidak bisa dibuka karena semua port di rentang port ephemeral sedang dipakai ### L8 Socket dan protokol (14 penyebab) #### sk-hol · HOL blocking pada TCP · Head-of-line blocking Untuk menjaga urutan, TCP tidak menyerahkan paket yang datang belakangan ke game sampai satu paket yang hilang diterima ulang. - Mengapa → Akibatnya → Di layar: Satu paket hilang → Paket-paket sesudahnya sudah tiba, tetapi menunggu di buffer terima → Berhenti, lalu semuanya dilepas sekaligus sehingga terjadi fast forward - Gejala: Freeze, Fast forward / Faktor: Packet loss, Stall - Siapa: Hanya saya / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kirim posisi real-time lewat UDP, gunakan pengiriman reliable hanya untuk data yang benar-benar perlu, pecah menjadi beberapa stream. Klien: ubah pemrosesan jaringan ke cara yang sama dengan server (UDP, pemisahan channel). - Kisaran angka: Jika satu paket hilang, game berhenti minimal selama RTT + α; jika paket retransmisinya juga hilang, berhentinya bisa ratusan ms hingga beberapa detik. - Di grafik: Kosong lalu datang sekaligus (Jumlah data diterima per koneksi, jumlah retransmisi) - Yang diperiksa: Periksa paket retransmisi dan jeda kosong sebelum dan sesudahnya pada koneksi pemain tersebut lewat packet capture di sisi server (tcpdump, Wireshark); untuk seluruh server, periksa kenaikan TcpRetransSegs di nstat -az - Cocok jika: Bagian yang berhenti dimulai dengan retransmisi satu paket, dan tepat setelah paket retransmisi tiba, data yang tertahan diproses sekaligus (data diterima 0 lalu datang bertumpuk) - Tidak cocok jika: Game berkomunikasi lewat UDP: tidak berlaku. Tidak ada retransmisi tetapi tetap berhenti: periksa sisi tick server (“Tick melewati budget (tick overrun)”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · TCP adalah layanan byte stream yang reliable dan menjaga urutan - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Packet loss dideteksi dari 3 duplicate ACK lalu dilakukan fast retransmit; jika tidak, TCP menunggu timer retransmisi - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Backoff yang menggandakan timer retransmisi setiap kali timer habis - [net/ipv4/proc.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Nama counter yang ditampilkan nstat: RetransSegs di grup Tcp (jumlah segmen yang dikirim ulang) #### sk-rto · RTO TCP dan exponential backoff · RTO and exponential backoff Setiap kali retransmisi gagal lagi, waktu tunggu berlipat dua, sehingga koneksi yang putus sebentar berujung pada jeda yang lama. - Mengapa → Akibatnya → Di layar: Koneksi putus sebentar sehingga retransmisi pun gagal berturut-turut → Waktu tunggu sampai percobaan berikutnya berlipat dua: 0,3 → 0,6 → 1,2 → 2,4 detik (untuk ping 100 ms) → Koneksi hanya putus 1 detik, tetapi game freeze lebih dari 2 detik. Jika putusnya lebih lama, akhirnya disconnect - Gejala: Freeze, Disconnect / Faktor: Packet loss, Stall - Siapa: Hanya saya / Kapan: Sesekali secara acak, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: balas heartbeat dan putuskan koneksi lebih dulu jika tidak ada heartbeat dalam waktu tertentu (percepat titik menyerah dengan TCP_USER_TIMEOUT), lanjutkan sesi dengan token sesi, gunakan reliable UDP. Klien: kirim heartbeat dengan interval pendek, dan jika respons berhenti, segera reconnect tanpa menunggu retransmisi TCP. - Kisaran angka: RTO (waktu tunggu retransmisi) di Linux minimal “ping + 200 ms”, dan saat koneksi dibuat, RTO dimulai dari 1 detik. Dengan pengaturan default (tcp_retries2=15), walaupun retransmisi terus gagal, koneksi baru dilepas setelah sekitar 15 menit. - Di grafik: Kosong lalu datang sekaligus (RTO dan backoff per koneksi, jumlah RTO habis) - Yang diperiksa: Periksa rto (waktu tunggu retransmisi dalam ms) dan backoff (jumlah RTO habis berturut-turut) pada koneksi yang berhenti dengan ss -ti; untuk seluruh server, periksa kenaikan TcpExtTCPTimeouts (jumlah timer retransmisi habis) di nstat -az - Cocok jika: backoff pada koneksi yang berhenti bernilai 1 atau lebih, rto membesar hingga satuan detik, dan TCPTimeouts naik pada saat itu - Tidak cocok jika: Retransmisi selesai lewat fast retransmit dan tidak ada RTO yang habis: berhentinya singkat, dan dalam kasus itu lebih mungkin “HOL blocking pada TCP” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · RTO awal 1 detik, RTO digandakan setiap kali timer habis (exponential backoff) - [net/ipv4/tcp_input.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_input.c?h=v6.12) · Linux kernel · RTO di Linux = smoothed RTT + variasi RTT, dan batas bawah variasinya adalah tcp_rto_min (200 ms), sehingga RTO minimal RTT+200 ms - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_rto_min_us default 200 ms, RTO pertama untuk permintaan koneksi 1 detik, dengan tcp_retries2=15 waktu sampai menyerah minimal 924,6 detik (sekitar 15 menit) - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rto (timer retransmisi, ms) dan backoff (jumlah exponential backoff) pada -i - [net/ipv4/proc.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Nama counter yang ditampilkan nstat: TCPTimeouts di grup TcpExt - [net/ipv4/tcp_timer.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · Setiap kali timer retransmisi habis, TCPTimeouts naik, backoff bertambah satu, dan RTO digandakan (sampai nilai maksimum) #### sk-nagle · Algoritma Nagle + delayed ACK · Nagle + delayed ACK (TCP_NODELAY off) Algoritma Nagle yang mengumpulkan paket kecil sebelum dikirim dan delayed ACK yang menunda pengiriman ACK saling mengunci, sehingga setiap kali pesan ditulis terpisah-pisah terjadi keterlambatan 40–200 ms. - Mengapa → Akibatnya → Di layar: Pesan kecil ditulis terpisah-pisah tanpa mengaktifkan TCP_NODELAY → Pengirim menunggu ACK, sedangkan penerima menunda pengiriman ACK → Ping koneksi rendah, tetapi semua aksi terasa lamban secara konsisten (input lag) - Gejala: Input lag / Faktor: Latensi - Siapa: Seluruh server, Hanya saya / Kapan: Selalu, Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: aktifkan TCP_NODELAY, kumpulkan pesan selama satu tick lalu tulis sekaligus, jangan mengandalkan cara mematikan delayed ACK di sisi penerima (TCP_QUICKACK di Linux hanya bertahan sebentar, di Windows registry harus diubah di setiap PC) karena game tidak bisa mengendalikannya dengan pasti. Klien: aktifkan TCP_NODELAY, kumpulkan pesan selama satu frame lalu tulis sekaligus. - Kisaran angka: Delayed ACK di Linux biasanya 40 ms (hingga 200 ms tergantung situasi). Di Windows, versi lama memakai 200 ms dan versi sekarang 40 ms (template default Windows Server 2019: 40 ms). Delayed ACK ditentukan oleh OS penerima, jadi jika server mengirim pesan terpisah-pisah dengan Nagle aktif, keterlambatannya bisa 40–200 ms tergantung PC penerimanya. - Di grafik: Selalu tinggi sejak awal (Waktu respons aksi (RTT di dalam game)) - Yang diperiksa: Periksa jeda antara permintaan dan respons di packet capture sisi server (tcpdump, Wireshark), lalu pastikan kode server dan klien mengaktifkan TCP_NODELAY - Cocok jika: Ping koneksi rendah, tetapi jeda kosong sekitar 40 ms (200 ms di Windows versi lama) berulang di antara paket kecil, dan jeda itu berakhir tepat setelah ACK dari pihak lawan datang. Hilang setelah TCP_NODELAY diaktifkan - Tidak cocok jika: Jeda respons mirip dengan ping koneksi: bukan penyebab ini. Server game terlambat membuat respons: masalahnya di pemrosesan server (“Penumpukan antrean pesan”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Nagle menahan data kecil selama masih ada data yang belum mendapat ACK; harus bisa dimatikan per koneksi; delayed ACK kurang dari 0,5 detik; masalah saat keduanya saling mengunci - [include/net/tcp.h (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · Delayed ACK di Linux minimal TCP_DELACK_MIN (HZ/25 = 40 ms), maksimal TCP_DELACK_MAX (HZ/5 = 200 ms) - [TCP improvements in the Windows network stack (IETF 98 TCPM)](https://datatracker.ietf.org/meeting/98/materials/slides-98-tcpm-tcp-improvements-in-windows-01) · Microsoft · Timeout delayed ACK default di Windows diubah menjadi 40 ms (diumumkan tahun 2017) - [TCP Templates for Windows Server 2019 – How to tune your Windows Server Transports (Advanced users only 😉)](https://techcommunity.microsoft.com/blog/networkingblog/tcp-templates-for-windows-server-2019-8211-how-to-tune-your-windows-server-trans/339795) · Microsoft · Template Server 2019: DelayedAckTimeout 40 ms, MaxSynRetransmissions 2, InitialRto 3000 ms - [Design issues - Sending small data segments over TCP with Winsock](https://learn.microsoft.com/en-us/previous-versions/troubleshoot/windows/win32/data-segment-tcp-winsock) · Microsoft · TCP Windows versi lama memasang timer delayed ACK 200 ms setiap kali menerima data, dan Nagle aktif secara default sehingga paket kecil menunggu ACK; diatasi dengan TCP_NODELAY #### sk-block-send · Pengiriman blocking akibat klien lambat · Blocking send on a full socket Jika buffer kirim untuk satu pemain dengan koneksi lambat sudah penuh, lalu server mengirim dengan cara blocking (pemanggilan yang tidak kembali sampai buffer punya ruang), thread server ikut menunggu pemain itu. - Mengapa → Akibatnya → Di layar: Buffer kirim untuk klien yang lambat penuh → Karena pengirimannya blocking, thread server menunggu sampai buffer punya ruang → Semua pemain yang ditangani thread itu mengalami freeze atau slow motion - Gejala: Freeze, Slow motion / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Sesekali secara acak, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Gunakan pengiriman non-blocking, batasi antrean kirim per klien, buang update yang sudah lama. - Di grafik: Melonjak acak sesekali (Waktu tick server, Send-Q per koneksi) - Yang diperiksa: Cari koneksi yang Send-Q-nya (byte yang belum mendapat ACK atau belum terkirim) sudah sebesar buffer kirim dengan ss -tn, lalu periksa di thread dump (stack) server game saat tick melonjak apakah ada thread yang tertahan di pemanggilan send - Cocok jika: Saat ada koneksi lambat dengan Send-Q penuh, thread yang menangani koneksi itu tertahan di send, dan hanya pemain yang ditangani thread yang sama ikut berhenti - Tidak cocok jika: Thread yang berhenti menunggu di luar send (lock, pemanggilan DB): lebih mungkin “Perebutan lock” atau “Pemanggilan sinkron di thread game” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [send(2) — Linux manual page](https://man7.org/linux/man-pages/man2/send.2.html) · Linux man-pages · Jika buffer kirim tidak punya ruang, send() memblok; dalam mode non-blocking, send() langsung kembali dengan EAGAIN - [send function (winsock2.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-send) · Microsoft · Winsock juga memblok send jika ruang buffer tidak ada, kecuali dalam mode non-blocking - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK #### sk-slow-client · Kebijakan penanganan klien lambat (slow consumer) · Slow-consumer policy Untuk klien yang data kirimannya terus menumpuk, server membuang update lama atau memutus koneksinya. - Mengapa → Akibatnya → Di layar: Koneksi klien tidak sanggup mengimbangi jumlah data yang dikirim server → Server membuang update lama atau memutus koneksi saat batas terlampaui → Hanya pemain itu yang mengalami teleport atau disconnect - Gejala: Teleport, Disconnect / Faktor: Packet loss - Siapa: Hanya saya / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kurangi jumlah data yang dikirim (frekuensi update berdasarkan jarak), turunkan kualitas tetapi tetap kirim, kurangi data yang ditumpuk di kernel (TCP_NOTSENT_LOWAT di Linux). - Kisaran angka: Jika buffer kirim 256 KB, pada koneksi 30 KB/s data yang tertunda lebih dari 8 detik bisa menumpuk. Linux bahkan bisa membesarkan buffer ini secara otomatis hingga beberapa MB. - Di grafik: Hanya sebagian yang tinggi (Send-Q per koneksi, jumlah update yang dibuang per klien) - Yang diperiksa: Periksa panjang antrean kirim per klien, jumlah update yang dibuang, dan alasan putus yang dicatat server game, lalu di server periksa Send-Q dan cwnd koneksi itu dengan ss -tni - Cocok jika: Hanya koneksi pemain yang melonjak atau putus yang Send-Q-nya terus penuh, dan log game mencatat update pemain itu dibuang atau koneksinya diputus karena antrean kirim melewati batas - Tidak cocok jika: Send-Q kosong tetapi pemain teleport: masalahnya ada di luar sisi kirim server. Lebih mungkin packet loss pada koneksi pemain itu (“Packet loss di jalur nirkabel”) atau interpolasi di layar - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_wmem: batas maksimum buffer kirim yang diatur otomatis default 64 KB–4 MB (tergantung memori); jumlah data yang belum terkirim dibatasi dengan tcp_notsent_lowat dan TCP_NOTSENT_LOWAT - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK #### sk-keepalive · Nilai default keepalive 2 jam · TCP keepalive defaults Jika pihak lawan menghilang tanpa sinyal penutupan, TCP baru mendeteksinya lama kemudian. keepalive (fitur TCP untuk memeriksa apakah koneksi idle masih hidup) nonaktif secara default, dan walaupun diaktifkan, pemeriksaan baru dimulai setelah koneksi idle selama 2 jam. - Mengapa → Akibatnya → Di layar: Klien menghilang tanpa sinyal penutupan karena perangkat mati atau koneksi putus → Server menganggap koneksi masih hidup (keepalive default 7.200 detik; jika ada data yang sedang dikirim, sekitar 15 menit sampai retransmisi menyerah) → Karakter hantu tertinggal, dan saat login ulang muncul error “Sudah terhubung” - Gejala: Tidak bisa masuk / loading tanpa henti, Tidak terlihat / objek hantu / Faktor: Packet loss - Siapa: Hanya saya / Kapan: Setelah lama diam, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Server: balas heartbeat dan putuskan koneksi lebih dulu jika tidak ada heartbeat dalam waktu tertentu (sesuaikan TCP_KEEPIDLE dan TCP_USER_TIMEOUT), saat pemain reconnect ganti sesi lama lewat token sesi agar sesi berlanjut. Klien: kirim heartbeat di level game dengan interval beberapa hingga puluhan detik (maksimal setengah dari idle timeout terpendek), reconnect otomatis jika terputus. - Tugas Tim Infrastruktur: Turunkan nilai default kernel (tcp_keepalive_time dan lainnya) untuk socket yang tidak mengaturnya sendiri di kode (hanya berlaku untuk socket yang mengaktifkan SO_KEEPALIVE). - Kisaran angka: Default Linux: pemeriksaan dimulai setelah koneksi idle 7.200 detik, probe dikirim 9 kali dengan interval 75 detik, dan jika sampai akhir tidak ada respons, koneksi diputus. Totalnya sekitar 2 jam 11 menit. Windows juga secara default baru memulai pemeriksaan setelah koneksi idle 2 jam. - Di grafik: Hanya sebagian yang tinggi (Waktu berlalu sejak data terakhir diterima per koneksi) - Yang diperiksa: Periksa lastrcv (ms sejak data terakhir diterima) dan timer keepalive (timer:(keepalive,…)) per koneksi dengan ss -tnoi, lalu cocokkan dengan catatan penolakan “Sudah terhubung” di server game - Cocok jika: Masih ada koneksi ESTABLISHED dengan lastrcv beberapa menit hingga beberapa jam, dan reconnect akun tersebut ditolak dengan “Sudah terhubung” - Tidak cocok jika: Tidak ada koneksi yang lama diam tetapi “Sudah terhubung” tetap muncul: masalahnya di kode pembersihan sesi server game - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · Setelah idle 7.200 detik, probe dikirim 9 kali dengan interval 75 detik (tambahan sekitar 11 menit); hanya berlaku untuk socket yang mengaktifkan SO_KEEPALIVE; TCP_KEEPIDLE dan TCP_USER_TIMEOUT - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · keepalive harus nonaktif secara default, dan interval idle default minimal 2 jam - [SO_KEEPALIVE socket option](https://learn.microsoft.com/en-us/windows/win32/winsock/so-keepalive) · Microsoft · Timeout default TCP keepalive di Windows 2 jam - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · lastrcv pada -i (ms sejak data terakhir diterima), timer:(keepalive,…) pada -o #### sk-fragment · Fragmentasi IP pada paket UDP · IP fragmentation of large UDP Paket UDP yang melebihi MTU (ukuran maksimum yang bisa dikirim sekaligus) difragmentasi di lapisan IP, dan jika satu fragmen saja hilang, seluruh paket dibuang. - Mengapa → Akibatnya → Di layar: Snapshot di tempat ramai melebihi 1.500 byte → Paket dikirim terpecah menjadi beberapa fragmen; jika satu saja hilang, seluruhnya dibuang → Makin besar paketnya, tingkat packet loss naik beberapa kali lipat. Teleport hanya terjadi di tempat ramai - Gejala: Teleport / Faktor: Packet loss - Siapa: Lokasi/channel tertentu, Wilayah/ISP tertentu / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pecah sendiri paket menjadi maksimal 1.200 byte, kirim hanya bagian yang berubah. - Kisaran angka: Pada koneksi dengan packet loss 2%, paket yang terpecah menjadi 4 fragmen hilang sekitar 8%. Ada juga firewall dan ISP yang membuang semua paket terfragmentasi, sehingga pemain tersebut tidak menerima satu pun paket besar. - Di grafik: Naik mengikuti beban (Jumlah fragmentasi IP (IpFragCreates), ukuran snapshot) - Yang diperiksa: Periksa kenaikan IpFragCreates (jumlah fragmen yang dibuat saat mengirim) di nstat -az pada server, dan IpReasmFails (jumlah kegagalan penyusunan ulang fragmen) di sisi penerima. Periksa distribusi ukuran paket UDP dari log server game atau packet capture - Cocok jika: IpFragCreates naik di tempat ramai, ada paket UDP yang melebihi 1.500 byte, dan laporan teleport bertambah pada saat itu - Tidak cocok jika: IpFragCreates tidak naik: tidak ada fragmentasi di sisi kirim server - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Jika satu fragmen hilang, penyusunan ulang gagal dan seluruh paket hilang; aplikasi UDP harus menghindari fragmentasi IP - [RFC 8900: IP Fragmentation Considered Fragile](https://www.rfc-editor.org/rfc/rfc8900) · IETF · Contoh firewall dan sebagian jaringan yang membuang fragmen IP - [net/ipv4/proc.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Nama counter yang ditampilkan nstat: FragCreates (jumlah fragmen yang dibuat) dan ReasmFails (jumlah kegagalan penyusunan ulang) di grup Ip #### sk-reliable-udp · Pengaturan retransmisi reliable UDP · Reliable-UDP tuning (KCP, ENet…) Jika aturan retransmisi yang dibuat sendiri di atas UDP terlalu konservatif, pemulihan terlambat; jika terlalu agresif, jalur makin padat. - Mengapa → Akibatnya → Di layar: Pengaturan interval retransmisi, jumlah percobaan, dan ukuran window tidak sesuai dengan koneksi → Pemulihan terlambat, atau pengiriman duplikat memperparah kongesti → Skill tidak keluar, fast forward, lag yang makin parah saat jalur padat - Gejala: Aksi hilang / rollback, Fast forward / Faktor: Packet loss, Latensi - Siapa: Hanya saya / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: lakukan retransmisi berdasarkan round-trip time yang diukur, pisahkan channel menurut tingkat kepentingan. Klien: terapkan pengaturan retransmisi dan channel yang sama dengan server. - Di grafik: Melonjak acak sesekali (Rasio retransmisi reliable UDP, RTT di dalam game) - Yang diperiksa: Catat statistik per koneksi dari library yang dipakai (jumlah retransmisi, perkiraan round-trip time, waktu tunggu retransmisi) di server dan klien, lalu bandingkan dengan tingkat packet loss koneksi sebenarnya dari pemain yang sama (diukur dengan mtr) - Cocok jika: Rasio retransmisi beberapa kali lebih tinggi dari tingkat packet loss sebenarnya: pengaturan terlalu agresif. Waktu tunggu retransmisi beberapa kali lipat dari round-trip time terukur: pengaturan terlalu konservatif - Tidak cocok jika: Rasio retransmisi mirip dengan tingkat packet loss koneksi dan waktu tunggu sesuai round-trip time: masalahnya di luar pengaturan. Periksa packet loss pada koneksinya sendiri - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Retransmisi bisa memperparah kongesti sehingga harus tunduk pada congestion control; round-trip time diperkirakan dari rata-rata beberapa pengukuran (EWMA); nilai awal 1 detik; laju kirim diturunkan saat timer habis #### sk-slowstart · Slow start setelah idle · Slow start after idle Jika koneksi idle cukup lama, TCP kembali mengecilkan congestion window (jumlah data yang bisa dikirim sekaligus), sehingga data besar yang tiba-tiba dikirim harus dipecah menjadi beberapa kali kirim. - Mengapa → Akibatnya → Di layar: Data besar, misalnya saat masuk ke kota, dikirim lewat koneksi yang tadinya idle → Congestion window sedang kecil sehingga data dikirim terbagi dalam beberapa kali pulang-pergi → Tepat setelah masuk, karakter dan NPC di sekitar muncul terlambat beberapa kali waktu pulang-pergi (makin jauh servernya, makin terasa) - Gejala: Input lag, Tidak terlihat / objek hantu / Faktor: Latensi - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area, Setelah lama diam - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kurangi data saat masuk (kirim yang paling penting lebih dulu). - Tugas Tim Infrastruktur: Matikan tcp_slow_start_after_idle (Linux, pengaturan untuk seluruh server). - Kisaran angka: Jika koneksi idle lebih lama dari RTO, congestion window mulai mengecil, dan setelah idle lama bisa turun sampai sekitar 14 KB (10 paket). Akibatnya, 100 KB tidak bisa dikirim sekaligus dan harus dibagi dalam 3 kali pulang-pergi. - Di grafik: Hanya sebagian yang tinggi (Waktu kirim tepat setelah masuk (pemain dengan RTT panjang)) - Yang diperiksa: Periksa nilai sysctl net.ipv4.tcp_slow_start_after_idle, lalu saat pemain masuk ke suatu area setelah idle, periksa di ss -ti apakah cwnd (congestion window) koneksinya mengecil - Cocok jika: Nilainya 1 (default), dan saat masuk setelah idle cwnd turun ke sekitar 10 sehingga pengiriman terbagi dalam beberapa kali pulang-pergi. Makin panjang RTT pemain, makin lambat objek muncul, dan gejalanya hilang setelah nilainya diubah ke 0 - Tidak cocok jika: cwnd tetap besar tetapi objek tetap terlambat muncul: lebih mungkin pemrosesan masuk di sisi server (“Lonjakan spawn saat masuk area padat”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_slow_start_after_idle default aktif; jika idle selama RTO, congestion window dikecilkan (cara RFC 2861) - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Jika data tidak dikirim lebih lama dari RTO, congestion window dikecilkan ke restart window min(IW, cwnd) atau lebih kecil, lalu slow start - [RFC 6928: Increasing TCP's Initial Window](https://www.rfc-editor.org/rfc/rfc6928) · IETF · Initial window 10 segmen, maksimal 14.600 byte - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · cwnd (congestion window) dan ssthresh (ambang slow start) pada -i #### sk-congestion · Laju kirim anjlok akibat congestion control · Congestion control backoff TCP menganggap packet loss sebagai tanda kongesti dan menurunkan kecepatan kirim 30–50%. TCP bereaksi sama terhadap packet loss di Wi-Fi. - Mengapa → Akibatnya → Di layar: Saat data yang dikirim banyak, terjadi sedikit packet loss di Wi-Fi atau di jalur koneksi → TCP menurunkan kecepatan kirim secara drastis lalu pulih perlahan (CUBIC, default di Linux dan Windows, menurunkannya 30%) → Di tempat ramai, update tertunda sehingga terjadi fast forward atau input lag - Gejala: Fast forward, Input lag / Faktor: Latensi, Stall - Siapa: Hanya saya / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kurangi data yang dikirim (area of interest, hanya bagian yang berubah), kirim terbagi agar tidak menumpuk sekaligus. - Tugas Tim Infrastruktur: Ganti ke congestion control seperti BBR (tcp_congestion_control). - Di grafik: Naik perlahan lalu anjlok (Congestion window (cwnd) dan laju kirim per koneksi) - Yang diperiksa: Ambil ss -ti beberapa kali untuk koneksi pemain yang update-nya tertunda, lalu periksa perubahan cwnd dan ssthresh, nama congestion control (cubic, bbr), dan apakah Send-Q menumpuk - Cocok jika: Setelah packet loss, cwnd turun drastis lalu naik perlahan secara berulang, dan selama cwnd kecil Send-Q menumpuk, bertepatan dengan waktu laporan fast forward atau input lag - Tidak cocok jika: cwnd cukup besar tetapi tetap tertunda: lebih mungkin window di sisi penerima (“Zero window (jeda yang terlihat seperti retransmisi)”) atau sisi kirim server - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 9438: CUBIC for Fast and Long-Distance Networks](https://www.rfc-editor.org/rfc/rfc9438) · IETF · Saat packet loss, CUBIC mengecilkan window menjadi 0,7 kali (turun 30%), Reno 0,5 kali; CUBIC adalah default di Linux, Windows, dan Apple - [TCP BBR congestion control comes to GCP – your Internet just got faster](https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster) · Google Cloud · Congestion control berbasis packet loss menurunkan laju kirim secara drastis bahkan untuk packet loss yang tidak disebabkan kongesti; BBR menilai dari laju pengiriman (delivery rate) dan RTT - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Memilih algoritma congestion control untuk koneksi baru dengan tcp_congestion_control - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · cwnd, ssthresh, dan nama algoritma congestion control pada -i - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK #### sk-linger · Data terakhir hilang akibat penutupan paksa dengan RST · SO_LINGER, abrupt RST Jika server memutus koneksi secara mendadak, pesan pemberitahuan atau sinyal penyimpanan selesai yang dikirim terakhir ikut hilang. - Mengapa → Akibatnya → Di layar: Server menutup koneksi dengan penutupan paksa (RST). Terjadi jika SO_LINGER diatur ke 0 detik, atau socket ditutup sebelum semua data yang diterima dibaca → Alasan kick dan data terakhir yang masih dalam pengiriman dibuang → Muncul pesan “Koneksi terputus karena error yang tidak diketahui” tanpa alasan yang jelas - Gejala: Disconnect / Faktor: Packet loss - Siapa: Hanya saya / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Setelah mengirim alasan, tutup arah kirim lebih dulu (shutdown), baca semua data yang diterima sampai pihak lawan menutup koneksi, baru tutup socket, hindari SO_LINGER 0 detik. - Di grafik: Melonjak acak sesekali (Jumlah koneksi yang berakhir dengan RST) - Yang diperiksa: Periksa kenaikan TcpExtTCPAbortOnData (ditutup dengan RST saat masih ada data yang akan dikirim, SO_LINGER 0 detik) dan TcpExtTCPAbortOnClose (ditutup saat masih ada data yang belum dibaca) di nstat -az, lalu periksa di packet capture sisi server saat koneksi putus apakah server mengirim RST tanpa FIN - Cocok jika: Pada waktu laporan “Koneksi terputus karena error yang tidak diketahui”, server mengirim RST, dan AbortOnData serta AbortOnClose naik - Tidak cocok jika: Server menutup koneksi secara normal dengan FIN tetapi alasannya tidak terlihat: masalahnya di penanganan penutupan koneksi di klien - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [closesocket function (winsock.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-closesocket) · Microsoft · Jika SO_LINGER diaktifkan dengan waktu 0, penutupan menjadi paksa: koneksi langsung direset dan data yang belum terkirim hilang - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Jika socket ditutup saat masih ada data diterima yang belum dibaca, RST dikirim untuk memberi tahu bahwa data hilang - [Graceful Shutdown, Linger Options, and Socket Closure](https://learn.microsoft.com/en-us/windows/win32/winsock/graceful-shutdown-linger-options-and-socket-closure-2) · Microsoft · Urutannya: tutup arah kirim lebih dulu dengan shutdown, lalu tutup socket setelah menerima notifikasi penutupan dari pihak lawan - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPAbortOnData: ditutup dengan RST saat masih ada data yang akan dikirim, misalnya karena SO_LINGER 0 detik; TcpExtTCPAbortOnClose: RST dikirim karena socket ditutup saat masih ada data yang belum dibaca #### sk-blocking-io · Arsitektur I/O blocking · Blocking I/O model Pada arsitektur yang membuat thread tidak bisa mengerjakan hal lain selama menunggu satu socket, seluruh server makin lambat seiring bertambahnya pemain. - Mengapa → Akibatnya → Di layar: Cara kerja yang menunggu baca dan tulis untuk setiap koneksi → Keterlambatan satu koneksi merembet ke koneksi lain di thread yang sama → Makin banyak pemain online, seluruh server makin terasa slow motion dan input lag - Gejala: Slow motion, Input lag / Faktor: Stall - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Beralih ke I/O asinkron berbasis epoll, IOCP, atau io_uring. - Di grafik: Naik mengikuti beban (Waktu respons, jumlah thread) - Yang diperiksa: Periksa jumlah thread server game dan context switching voluntary per thread (cswch/s, jumlah thread berhenti karena menunggu sumber daya) dengan pidstat -w -t, lalu bandingkan dengan waktu respons menurut jumlah pemain online - Cocok jika: Makin banyak pemain online, waktu respons naik tajam, dan sebagian besar thread yang bertambah sebanyak jumlah koneksi hanya banyak melakukan context switching voluntary dan hampir tidak memakai CPU (menunggu socket) - Tidak cocok jika: Thread terus memakai CPU tanpa menunggu: lebih mungkin beban komputasi berlebih (“Tick melewati budget (tick overrun)”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [epoll(7) — Linux manual page](https://man7.org/linux/man-pages/man7/epoll.7.html) · Linux man-pages · Notifikasi event I/O yang dapat diskalakan untuk memantau banyak fd sekaligus - [I/O Completion Ports](https://learn.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports) · Microsoft · Cara Windows memproses banyak I/O asinkron dengan thread pool yang dibuat lebih dulu - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · cswch/s pada -w: context switching voluntary (thread berhenti sendiri karena menunggu sumber daya), -t untuk melihat per thread #### sk-reuseport · Distribusi SO_REUSEPORT tidak merata · SO_REUSEPORT imbalance, stuck worker Jika beberapa proses berbagi satu port, kernel menetapkan proses yang menangani setiap koneksi berdasarkan hash alamat dan tidak mengubahnya. Jika satu proses itu berhenti, hanya pemain yang dialokasikan ke proses tersebut yang menunggu. - Mengapa → Akibatnya → Di layar: Gateway atau server login menjalankan beberapa proses dengan SO_REUSEPORT → Walaupun satu proses berhenti karena GC atau kelebihan beban, koneksi baru dan paket UDP yang dialokasikan ke proses itu tidak dialihkan ke proses lain → Hanya sebagian pemain yang tidak bisa masuk atau freeze. Saat restart yang mengubah jumlah proses, sebagian sesi UDP terputus - Gejala: Tidak bisa masuk / loading tanpa henti, Freeze, Disconnect / Faktor: Stall, Packet loss - Siapa: Hanya saya, Seluruh server / Kapan: Tepat setelah login atau maintenance, Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Pastikan thread penerima tidak pernah tertahan, implementasikan prosedur serah terima sesi saat restart. - Tugas Tim Infrastruktur: Pantau antrean koneksi per proses (Recv-Q di ss), pastikan prosedur serah terima sesi diikuti jika jumlah proses diubah saat deploy. - Di grafik: Hanya sebagian yang tinggi (Antrean koneksi (Recv-Q) per socket listen) - Yang diperiksa: Periksa Recv-Q (jumlah koneksi yang menunggu accept) dan proses yang menangani setiap socket listen pada port yang sama dengan ss -ltnp, lalu bandingkan throughput per proses - Cocok jika: Di antara beberapa socket pada port yang sama, hanya satu yang Recv-Q-nya terus menumpuk, dan proses itu sedang berhenti atau throughput-nya mendekati 0 - Tidak cocok jika: Recv-Q semua socket menumpuk merata: lebih mungkin kelebihan beban secara keseluruhan (“Antrean koneksi (backlog) meluap”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · Dengan SO_REUSEPORT, beberapa socket bind ke alamat yang sama dan berbagi koneksi TCP serta paket UDP - [net/core/sock_reuseport.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/sock_reuseport.c?h=v6.12) · Linux kernel · Tanpa program BPF, socket yang menangani dipilih dengan membagi nilai hash paket sesuai jumlah socket dalam grup - [Why does one NGINX worker take all the load?](https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/) · Cloudflare · SO_REUSEPORT membagi antrean per worker dengan hash sederhana, sehingga jika satu worker tertahan, semua koneksi yang menumpuk di antreannya ikut berhenti - [net/ipv4/tcp_diag.c (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Nilai Recv-Q dan Send-Q di ss: pada socket listen berarti jumlah koneksi yang menunggu accept dan batas backlog; pada socket yang terhubung berarti byte yang belum dibaca aplikasi dan byte terkirim yang belum mendapat ACK #### sk-udp-connreset · Error WSAECONNRESET pada socket UDP Windows · WSAECONNRESET on a Windows UDP socket Jika server Windows mengirim UDP ke klien yang sudah pergi, notifikasi “port tidak ada” (ICMP) dikirim balik. Notifikasi itu membuat pemanggilan terima berikutnya berakhir dengan error. Jika kode server memperlakukan error ini sebagai kerusakan socket itu sendiri, semua pemain yang memakai socket tersebut ikut terdampak. - Mengapa → Akibatnya → Di layar: UDP terus dikirim ke alamat klien yang baru saja keluar, sehingga notifikasi “port tidak ada” (ICMP) dikirim balik → Windows mengakhiri pemanggilan terima berikutnya dengan error WSAECONNRESET (10054), lalu kode server berhenti menerima atau menutup socket → Semua pemain yang memakai socket itu freeze atau disconnect bersamaan - Gejala: Disconnect, Freeze / Faktor: Packet loss, Stall - Siapa: Seluruh server / Kapan: Sesekali secara acak, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Matikan SIO_UDP_CONNRESET dengan WSAIoctl agar notifikasi ini tidak diterima, dan jika terjadi error terima, cukup catat di log lalu lanjutkan menerima. - Di grafik: Koneksi putus serentak (Jumlah koneksi, log error terima) - Yang diperiksa: Cari kode error terima UDP (WSAECONNRESET, 10054) dan catatan loop terima berhenti atau socket ditutup di log server game, lalu periksa di packet capture sisi server apakah ICMP Port Unreachable tiba sesaat sebelumnya - Cocok jika: Sesaat sebelum koneksi putus serentak, error terima WSAECONNRESET tercatat, dan sebelumnya ICMP Port Unreachable datang dari alamat klien yang baru saja keluar - Tidak cocok jika: Server Linux, atau kode sudah mematikan SIO_UDP_CONNRESET: tidak berlaku - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Winsock IOCTLs](https://learn.microsoft.com/en-us/windows/win32/winsock/winsock-ioctls) · Microsoft · SIO_UDP_CONNRESET mengaktifkan dan menonaktifkan pelaporan notifikasi UDP “port tidak ada” (PORT_UNREACHABLE) - [recvfrom function (winsock.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-recvfrom) · Microsoft · WSAECONNRESET pada socket UDP berarti pengiriman sebelumnya menerima ICMP Port Unreachable - [Windows Sockets Error Codes](https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2) · Microsoft · Nomor error WSAECONNRESET adalah 10054 ### L9 Proses game di server (18 penyebab) #### sp-tick-overrun · Tick melewati budget (tick overrun) · Tick overrun Jika pekerjaan dalam satu tick melewati tick budget (batas waktu per tick), interval tick server memanjang, dan seluruh area itu berjalan lambat atau patah-patah. - Mengapa → Akibatnya → Di layar: Pekerjaan yang harus diproses dalam satu tick (misalnya 50 ms) melewati budget → State game yang seharusnya dihitung 20 kali per detik hanya dihitung 8 kali → Seluruh area itu slow motion (atau patah-patah, tergantung desain server), respons skill terlambat - Gejala: Slow motion, Input lag, Patah-patah / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Kurangi komputasi yang mahal, bagi tick ke beberapa thread, sebar pemain (channel), catat waktu pemrosesan tick sebagai metrik. - Tugas Tim Infrastruktur: Tambahkan waktu tick dan utilisasi CPU per core ke monitoring dan alert, pertimbangkan CPU atau instance dengan performa single-core (clock) tinggi. - Kisaran angka: Budget server 20 tick adalah 50 ms, server 30 tick 33 ms, dan server 60 tick 16,7 ms. Untuk berjaga-jaga saat beban tiba-tiba melonjak, lebih aman menyisakan ruang dengan hanya memakai sekitar separuh budget di waktu biasa. - Di grafik: Naik mengikuti beban (Waktu tick server, jumlah pemain per zona dan channel, CPU thread game) - Yang diperiksa: Tampilkan waktu pemrosesan tick (p99) dan jumlah tick overrun yang dicatat server dalam satu grafik dengan jumlah pemain per zona dan channel. Jika tidak ada metrik tick, periksa utilisasi CPU satu thread game dengan pidstat -t 1 - Cocok jika: Saat pemain berkumpul, waktu tick melewati budget (50 ms untuk server 20 tick), dan selama itu utilisasi CPU thread game menempel di dekat 100% - Tidak cocok jika: Tick melewati budget tetapi CPU thread game rendah: penyebabnya sesuatu yang ditunggu (jeda GC, lock, pemanggilan sinkron). Latensi run queue di bcc runqlat panjang: thread tidak mendapat jatah CPU, jadi lebih mungkin CPU kurang atau thread berlebihan - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Wujud tick yang terlambat berbeda menurut desain server. Server yang memajukan state game sebesar waktu tetap (misalnya 50 ms) setiap tick membuat waktu game itu sendiri melambat, sehingga terjadi slow motion. Server yang menggerakkan objek sekaligus sebesar waktu yang benar-benar berlalu tetap menjaga kecepatan jalannya game, tetapi paket menjadi jarang dan gerakannya melompat besar, sehingga terlihat patah-patah atau teleport. Pada kedua cara itu, respons input tetap terlambat. Jika satu thread game menangani seluruh server, seluruh server melambat; jika thread dibagi per area, hanya area itu yang melambat. Ada juga game seperti EVE Online yang sengaja memperlambat waktu game hingga 10 kali (Time Dilation) dalam pertempuran besar agar komputasi bisa mengejar. - Kasus nyata: eve-hedgp-2014 - Sumber: - [VALORANT's 128-Tick Servers](https://www.riotgames.com/en/news/valorants-128-tick-servers) · Riot Games · Server 128 tick harus menyelesaikan satu frame dalam 7,8125 ms; frame time server diukur per subsistem dan budget-nya dibagi lalu dikelola - [HED-GP Technical Retrospective: What a HED-ache](https://www.eveonline.com/news/view/what-a-hed-ache) · CCP Games · Saat kelebihan beban, EVE Online memperlambat waktu game dengan Time Dilation dengan batas bawah 10% (10 kali lebih lambat); di waktu biasa, CPU node di bawah 80% - [Handling variation in time](https://docs.unity3d.com/Manual/time-handling-variations.html) · Unity · Jika simulasi berinterval tetap tertinggal, langkah pengejaran dijalankan bertumpuk, dan waktu yang melewati batas dibuang sehingga waktu game berjalan lebih lambat dari waktu nyata - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -t menampilkan sekaligus statistik per thread milik proses (utilisasi CPU dan lainnya) - [Demonstrations of runqlat, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/runqlat_example.txt) · IO Visor · Menampilkan latensi run queue scheduler (waktu tunggu sampai tugas mendapat jatah CPU) dalam bentuk histogram #### sp-aoi · Lonjakan perhitungan jarak pandang (AOI, N²) · Area-of-interest explosion Jika siapa bisa melihat siapa dihitung dengan membandingkan semua pemain satu sama lain, saat jumlah pemain naik 10 kali, perhitungannya naik 100 kali. - Mengapa → Akibatnya → Di layar: Jarak dibandingkan antara semua karakter, atau walaupun sudah dibagi dengan grid, ratusan pemain berkumpul di dekat satu sel → 100 pemain berarti sekitar 10.000 perbandingan, 1.000 pemain sekitar 1 juta perbandingan → Di tempat ramai seperti world boss atau siege, waktu tick melonjak sehingga terjadi slow motion atau patah-patah - Gejala: Slow motion, Patah-patah / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Bagi dengan grid atau zona dan bandingkan hanya objek di sekitar, perbarui objek yang jauh lebih jarang, batasi jumlah pemain yang bisa dilihat satu pemain. - Kisaran angka: Jika perbandingan jarak dan pembaruan daftar terlihat/tidak terlihat dihitung 0,1 µs (sepersepuluh juta detik) per pasangan, 1.000 pemain (sekitar 1 juta pasangan) butuh 100 ms per tick. Itu dua kali budget server 20 tick (50 ms). - Di grafik: Naik mengikuti beban (Waktu tick server, jumlah pemain di satu tempat) - Yang diperiksa: Tampilkan jumlah pemain per zona dan channel dalam satu grafik dengan waktu tick, beserta waktu yang dipakai untuk perhitungan jarak pandang di dalam tick yang diukur terpisah. Jika tidak ada pengukuran terpisah, periksa porsi CPU per fungsi proses game dengan perf top -p - Cocok jika: Saat jumlah pemain di satu tempat naik 2 kali, waktu tick naik hampir 4 kali, dan fungsi perhitungan jarak pandang dan jarak memakan sebagian besar waktu CPU - Tidak cocok jika: Waktu tick naik sebanding dengan jumlah pemain, atau porsi fungsi pengiriman dan serialisasi besar: lebih mungkin lonjakan broadcast atau biaya serialisasi dan kompresi - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Comparing Interest Management Algorithms for Massively Multiplayer Games](https://www.sable.mcgill.ca/~clump/papers/boulanger-06-comparing.pdf) · ACM · Paper NetGames 2006 (versi yang dipublikasikan penulis). Cara mengukur jarak semua pasangan tidak sanggup menampung pemain yang bertambah; jika dibagi dengan grid persegi, cukup periksa 9 sel di sekitarnya - [Replication Graph in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/replication-graph-in-unreal-engine) · Epic Games · Cara dasar yang memeriksa semua koneksi untuk setiap actor menjadi bottleneck CPU server jika pemain dan actor banyak; MMORPG dan sejenisnya membagi dunia dengan grid dan memakai ulang daftar per sel - [perf-top(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-top.1.html) · perf · Menampilkan porsi pemakaian CPU per fungsi (simbol) secara real-time untuk proses (-p) atau thread (-t) yang sedang berjalan #### sp-broadcast · Lonjakan broadcast · Broadcast fan-out (N×N) Jika gerakan satu pemain dikirim ke semua yang melihatnya, jumlah update yang harus dikirim menjadi kuadrat dari jumlah pemain yang berkumpul. - Mengapa → Akibatnya → Di layar: Perubahan satu pemain dikirim ke semua yang bisa melihatnya → Jika 1.000 pemain saling melihat, ada 1 juta update setiap tick → Antrean kirim dan bandwidth jenuh sehingga terjadi keterlambatan dan packet loss (input lag, fast forward, teleport) - Gejala: Input lag, Teleport, Fast forward / Faktor: Latensi, Packet loss - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Turunkan frekuensi update menurut jarak dan tingkat kepentingan (musuh dekat setiap tick, pemain jauh beberapa kali per detik), batasi jumlah data yang dikirim ke satu pemain dan isi mulai dari yang paling penting, gabungkan beberapa update dalam satu paket, batasi jumlah pemain yang ditampilkan. - Tugas Tim Infrastruktur: Bandingkan bandwidth kirim dan jumlah paket per detik setiap server dengan batas jaringan NIC dan instance lalu pasang alert, pastikan ada ruang yang cukup sebelum event besar. - Kisaran angka: 1.000 pemain × 1.000 pemain × 20 tick = 20 juta update per detik. Jika satu update 40 byte, totalnya sekitar 6,4 Gbps untuk seluruh server dan sekitar 6,4 Mbps per penerima. Jika jumlah pemain yang terlihat dibatasi 150, totalnya sekitar 1 Gbps dan sekitar 1 Mbps per pemain. - Di grafik: Naik mengikuti beban (Paket dan byte yang dikirim server, jumlah pemain di satu tempat) - Yang diperiksa: Tampilkan txpck/s dan txkB/s (paket dan KB yang dikirim NIC server per detik) dari sar -n DEV 1 bersama grafik jumlah pemain. Untuk instance cloud, periksa counter batas terlampaui di ethtool -S (di AWS ENA: bw_out_allowance_exceeded dan pps_allowance_exceeded) - Cocok jika: Saat pemain yang berkumpul bertambah, paket dan byte kirim naik lebih tajam dari jumlah pemain (mendekati kuadrat), dan sejak menyentuh batas, counter batas terlampaui atau paket kirim yang dibuang bertambah - Tidak cocok jika: Volume kirim tidak berubah tetapi hanya waktu tick yang naik: lebih mungkin perhitungan jarak pandang atau logika game - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Kasus nyata: eve-hedgp-2014 - Sumber: - [HED-GP Technical Retrospective: What a HED-ache](https://www.eveonline.com/news/view/what-a-hed-ache) · CCP Games · Pengiriman O(n²), yaitu aksi n pemain harus dilihat oleh n pemain, adalah faktor pembatas yang tidak terhindarkan dalam pertempuran armada besar - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Jika bandwidth koneksi jenuh, setiap actor diberi prioritas (jarak, arah pandang, waktu sejak pengiriman terakhir) dan bandwidth dibagikan mulai dari yang paling penting - [Detailed Actor Replication Flow in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/detailed-actor-replication-flow-in-unreal-engine) · Epic Games · Frekuensi update per actor ditetapkan dengan NetUpdateFrequency; actor dikirim menurut urutan prioritas, dan jika koneksi jenuh, sisanya ditunda ke tick berikutnya - [sar(1) — Linux manual page](https://man7.org/linux/man-pages/man1/sar.1.html) · sysstat · rxpck/s dan txpck/s (paket diterima dan dikirim per detik), rxkB/s dan txkB/s (KB diterima dan dikirim per detik) pada sar -n DEV - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Jumlah paket yang masuk antrean atau dibuang karena bw_out_allowance_exceeded (batas bandwidth kirim terlampaui) dan pps_allowance_exceeded (batas PPS terlampaui) #### sp-hotzone · Kelebihan beban di area single-thread (hotspot) · Single-threaded hot zone Pada arsitektur yang menugaskan satu thread untuk setiap area, jika pemain berkumpul di satu tempat, hanya satu core itu yang mencapai 100%. - Mengapa → Akibatnya → Di layar: Satu area (channel) ditangani oleh satu thread → Jika pemain berkumpul di satu tempat, hanya core itu yang jenuh, sedangkan core lain masih longgar → Hanya area itu yang lag, area lain normal - Gejala: Slow motion, Input lag / Faktor: Stall - Siapa: Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Sebar ke beberapa channel, paralelkan pemrosesan di dalam area, batasi jumlah pemain. - Tugas Tim Infrastruktur: Tambahkan utilisasi CPU per core ke monitoring dan alert (satu core yang jenuh tertutup oleh rata-rata seluruh server). - Kisaran angka: Di server 16 core, walaupun satu core 100%, utilisasi CPU seluruh server hanya terlihat sekitar 6%. Masalah ini baru ketahuan jika utilisasi per core diperiksa. - Di grafik: Naik mengikuti beban (Utilisasi CPU per core, CPU per thread) - Yang diperiksa: Periksa utilisasi per core dengan mpstat -P ALL 1 dan CPU per thread proses game dengan pidstat -t 1, lalu bandingkan dengan jumlah pemain di zona yang ditangani thread tersibuk - Cocok jika: CPU seluruh server rendah, tetapi hanya satu thread (satu core) yang menempel di dekat 100%, dan pada saat itu pemain berkumpul di zona yang ditangani thread tersebut - Tidak cocok jika: Beberapa core tinggi secara merata: kelebihan beban seluruh server. Hanya %soft (pemrosesan paket masuk) di satu core yang tinggi: lebih mungkin interrupt NIC terpusat di satu core - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Area lain tetap normal hanya jika tick dijalankan terpisah per area. Jika thread-thread area saling menunggu setiap tick lalu bersama-sama maju ke tick berikutnya, satu area yang paling sibuk memperlambat tick seluruh server. - Kasus nyata: eve-hedgp-2014 - Sumber: - [Time Dilation – How’s That Going?](https://www.eveonline.com/news/view/time-dilation-hows-that-going) · CCP Games · Time Dilation di EVE Online berlaku per node, sehingga sistem bintang jauh yang berada di node yang sama ikut melambat; pertempuran besar diproses di node yang diperkuat yang hanya memuat 4 sistem bintang - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · Menampilkan utilisasi per prosesor dan rata-rata keseluruhan secara terpisah (-P ALL); %soft adalah persentase waktu untuk memproses software interrupt - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -t menampilkan sekaligus statistik per thread milik proses (utilisasi CPU dan lainnya) #### sp-lock · Perebutan lock · Lock contention Jika beberapa thread menunggu satu lock untuk menulis data yang sama, walaupun thread ditambah, hanya satu yang berjalan pada satu waktu. - Mengapa → Akibatnya → Di layar: Beberapa thread memakai data bersama secara bersamaan, misalnya balai lelang atau gudang guild → Thread lain menunggu sampai thread yang memegang lock selesai → Hanya fitur tertentu yang lambat; jika parah, tick seluruh server tertunda - Gejala: Input lag, Freeze / Faktor: Stall - Siapa: Fitur tertentu saja, Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pecah lock menjadi lebih kecil, kurangi pekerjaan di dalam lock, gunakan arsitektur berbasis pesan (tetapkan thread penanggung jawab untuk setiap data, thread lain hanya mengirim permintaan lewat pesan). - Kisaran angka: Jika pekerjaan di dalam lock 20% dari total, throughput maksimal hanya 5 kali throughput satu thread berapa pun thread ditambah; jika 40%, berhenti di 2,5 kali. - Di grafik: Naik mengikuti beban (Waktu pemrosesan permintaan, CPU dan context switching per thread) - Yang diperiksa: Periksa context switching voluntary per thread (cswch/s, jumlah thread berhenti karena menunggu sumber daya) dengan pidstat -w -t 1, dan di mana thread menunggu setelah meninggalkan CPU (waktu tunggu per call stack) dengan bcc offcputime -p. Untuk .NET, periksa jumlah lock contention di dotnet-counters (.NET 9 ke atas: dotnet.monitor.lock_contentions, 8 ke bawah: Monitor Lock Contention Count) - Cocok jika: Beban naik tetapi utilisasi CPU tetap rendah sementara waktu pemrosesan naik, sebagian besar waktu tunggu terkumpul di call stack yang mencoba mengambil lock, dan jumlah lock contention ikut naik - Tidak cocok jika: CPU penuh: masalah volume komputasi (tick melewati budget, kelebihan beban di area single-thread). Tempat menunggunya pemanggilan DB atau file: lebih mungkin pemanggilan sinkron di thread game - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Masalah ini muncul pada arsitektur yang membuat beberapa thread mengubah data game bersama-sama. Arsitektur yang menugaskan satu thread per area atau fitur dan hanya bertukar pesan hampir tidak memakai lock, tetapi harus waspada terhadap pekerjaan yang menumpuk di satu thread (kelebihan beban di area single-thread). Jika thread game menunggu lock yang dipegang oleh operasi penyimpanan yang lambat, seluruh tick itu berhenti. - Kasus nyata: roblox-2021 - Sumber: - [Amdahl's Law in the Multicore Era](https://research.cs.wisc.edu/multifacet/papers/ieeecomputer08_amdahl_multicore.pdf) · IEEE · Paper IEEE Computer 2008 (versi yang dipublikasikan penulis). Jika porsi yang tidak bisa diparalelkan adalah 1−f, berapa pun core ditambah, percepatannya tidak bisa melewati 1/(1−f) (hukum Amdahl) - [Request scheduling](https://learn.microsoft.com/en-us/dotnet/orleans/grains/request-scheduling) · Microsoft · Grain (actor) di Orleans memakai model eksekusi single-thread yang memproses permintaan satu per satu sampai selesai, sehingga state tidak diubah bersamaan; jika saling menunggu respons, deadlock bisa terjadi - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · cswch/s pada -w adalah jumlah context switching voluntary karena menunggu sumber daya, -t untuk menampilkan per thread - [Demonstrations of offcputime, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/offcputime_example.txt) · IO Visor · Menjumlahkan waktu thread berhenti dan meninggalkan CPU (off-CPU) per call stack, -p untuk menentukan proses - [Well-known EventCounters in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/available-counters) · Microsoft · Monitor Lock Contention Count (monitor-lock-contention-count): jumlah lock contention yang terjadi saat mencoba mengambil monitor lock - [.NET runtime metrics](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/built-in-metrics-runtime) · .NET · dotnet.monitor.lock_contentions sejak .NET 9: jumlah lock contention yang terjadi saat mencoba mengambil monitor lock sejak proses dimulai #### sp-deadlock · Deadlock · Deadlock Jika dua thread saling menunggu lock yang dipegang thread lainnya, keduanya berhenti selamanya. - Mengapa → Akibatnya → Di layar: Thread A memegang lock 1 dan menunggu lock 2, sedangkan thread B memegang lock 2 dan menunggu lock 1 → Keduanya berhenti selamanya, dan thread lain yang terkait ikut berhenti satu per satu → Seluruh server berhenti, lalu watchdog memulai ulang server sehingga semua pemain disconnect - Gejala: Freeze, Disconnect / Faktor: Stall - Siapa: Seluruh server, Fitur tertentu saja / Kapan: Sesekali secara acak, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Tetapkan aturan urutan pengambilan lock, pakai lock dengan timeout, pasang watchdog dan simpan thread dump pada saat server berhenti. - Di grafik: Koneksi putus serentak (Jumlah koneksi, volume kirim server) - Yang diperiksa: Ambil call stack semua thread selama server berhenti. Gunakan jstack untuk JVM (otomatis menemukan dan menandai deadlock), dotnet-stack untuk .NET, dan thread apply all bt di gdb untuk server native, atau ambil core file dengan gcore, mulai ulang server, lalu analisis - Cocok jika: Dua thread atau lebih berhenti dengan stack yang saling menunggu lock yang dipegang thread lainnya, dan selama itu utilisasi CPU proses mendekati 0 - Tidak cocok jika: Selama server berhenti, satu thread terus berputar dengan CPU 100%: infinite loop. Thread-thread menunggu respons DB atau layanan eksternal: lebih mungkin pemanggilan sinkron atau thread pool habis - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Runtime locking correctness validator](https://docs.kernel.org/locking/lockdep-design.html) · Linux kernel · Jika dua lock diambil dengan urutan yang berlawanan, terjadi penantian melingkar sehingga muncul deadlock (lock inversion deadlock); kernel Linux memeriksa urutan lock dan memberi peringatan lebih awal - [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) · Kubernetes · Kondisi deadlock, yaitu proses masih berjalan tetapi tidak bisa maju, dideteksi oleh liveness probe lalu container dimulai ulang - [Diagnostic Tools (Java SE 21 Troubleshooting Guide)](https://docs.oracle.com/en/java/javase/21/troubleshoot/diagnostic-tools.html) · Oracle · jstack mencetak stack semua thread di JVM yang sedang berjalan, sekaligus menemukan dan menandai deadlock (Found one Java-level deadlock) - [dotnet-stack diagnostic tool - .NET CLI](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-stack) · Microsoft · Menangkap dan mencetak managed stack semua thread di proses .NET - [Threads (Debugging with GDB)](https://sourceware.org/gdb/current/onlinedocs/gdb.html/Threads.html) · GNU Project · thread apply all menjalankan perintah yang sama (bt: mencetak call stack) di semua thread - [gcore(1) — Linux manual page](https://man7.org/linux/man-pages/man1/gcore.1.html) · gdb · Membuat core file dari program yang sedang berjalan; setelah itu program tetap berjalan seperti biasa #### sp-sync-call · Pemanggilan sinkron di thread game · Synchronous DB / file I/O on the game loop Jika di tengah tick server menunggu respons DB atau penulisan file, seluruh jalannya game di server berhenti selama waktu itu. - Mengapa → Akibatnya → Di layar: Di dalam tick, server menunggu query dan penyimpanan DB, penulisan log, atau pemanggilan API eksternal → Jika DB butuh 100 ms, tick juga berhenti 100 ms → Setiap kali DB atau disk melambat, seluruh field tersendat sesaat - Gejala: Freeze, Patah-patah / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Saat melakukan aksi tertentu, Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Alihkan semua pekerjaan lambat (query dan penyimpanan DB, penulisan log, pemanggilan API eksternal) ke pemrosesan asinkron dan terapkan hasilnya di tick berikutnya (jika hanya memasang timeout, server tetap berhenti selama menunggu). - Kisaran angka: Pulang-pergi ke DB di data center yang sama hanya 0,5 ms, tetapi jika dipanggil 100 kali dalam satu tick, totalnya 50 ms. Itu saja sudah menghabiskan seluruh budget server 20 tick. - Di grafik: Melonjak acak sesekali (Waktu tick server, latensi query DB) - Yang diperiksa: Tampilkan grafik waktu tick bersama latensi query DB (slow query log dan sebagainya) dan latensi disk pada sumbu waktu yang sama. Jika tidak ada metrik tick, periksa di mana thread game menunggu dengan bcc offcputime -p - Cocok jika: Waktu lonjakan tick bertepatan dengan waktu lonjakan latensi DB atau file, dan waktu tunggu thread game terkumpul di call stack penerimaan respons DB atau penulisan file - Tidak cocok jika: Latensi DB dan disk tenang tetapi tick melonjak: lebih mungkin jeda GC atau perebutan lock - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Designs, Lessons and Advice from Building Large Distributed Systems](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Keynote LADIS 2009 (Jeff Dean). Pulang-pergi di dalam data center yang sama sekitar 0,5 ms (500.000 ns) - [ASP.NET Core Best Practices](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices) · Microsoft · Akses data, I/O, dan pekerjaan yang lama dipanggil secara asinkron; pemanggilan blocking yang sinkron menyebabkan thread pool habis dan respons terlambat - [Demonstrations of offcputime, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/offcputime_example.txt) · IO Visor · Menjumlahkan waktu thread berhenti dan meninggalkan CPU (off-CPU) per call stack, -p untuk menentukan proses #### sp-queue · Penumpukan antrean pesan · Mailbox / job queue backlog Jika permintaan masuk lebih cepat daripada kecepatan pemrosesan dan menumpuk di antrean, permintaan di belakang baru diproses beberapa detik kemudian atau dibuang. - Mengapa → Akibatnya → Di layar: Permintaan datang lebih cepat daripada kecepatan pemrosesan → Antrean memanjang, dan permintaan dibuang begitu melewati batas → Respons skill dan trade terlambat, atau aksinya hilang - Gejala: Input lag, Aksi hilang / rollback / Faktor: Latensi, Packet loss - Siapa: Lokasi/channel tertentu, Fitur tertentu saja / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pantau panjang antrean, terapkan kebijakan membuang permintaan lama lebih dulu, paralelkan pemrosesan. - Di grafik: Mendatar di batas (Panjang antrean dan umur pesan tertua, jumlah yang diproses per detik) - Yang diperiksa: Periksa panjang setiap antrean, umur pesan tertua, serta jumlah pesan yang masuk, diproses, dan dibuang per detik yang dicatat server. Jika tidak ada metrik di kode, periksa Recv-Q socket game (data yang sudah diterima kernel tetapi belum dibaca proses) dengan ss (atau netstat) - Cocok jika: Selama jumlah yang masuk melebihi jumlah yang diproses, jumlah yang diproses tertahan di satu nilai dan tidak naik lagi, sedangkan panjang dan umur antrean serta jumlah yang dibuang terus bertambah - Tidak cocok jika: Antrean pendek dan umur pesan kecil tetapi respons tetap terlambat: lebih mungkin latensi koneksi atau keterlambatan tick itu sendiri - Sarana pemeriksaan: Log dan metrik server atau klien game - Kasus nyata: eve-hedgp-2014 - Sumber: - [Avoiding insurmountable queue backlogs](https://d1.awsstatic.com/builderslibrary/pdfs/avoiding-insurmountable-queue-backlogs.pdf) · AWS · Amazon Builders' Library. Penumpukan dipantau lewat umur pesan yang menunggu; sistem real-time memproses data baru lebih dulu (mendekati LIFO) dan kadang membuang pesan lama - [Site Reliability Engineering, Chapter 22: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) · Google · Jika permintaan datang lebih cepat daripada kecepatan pemrosesan, antrean penuh dan latensi naik; permintaan lama yang sudah tidak berguna dikurangi dengan LIFO atau CoDel sebagai pengganti FIFO - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · Tool untuk menampilkan statistik socket (informasinya mirip netstat); -p menampilkan proses yang memakai socket - [netstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/netstat.8.html) · net-tools · Recv-Q: jumlah byte di socket yang terhubung yang belum diambil oleh program pengguna #### sp-timer-burst · Timer terpicu serentak · Synchronized timers Jika respawn semua monster, berakhirnya semua buff, dan hadiah tepat di pergantian jam menumpuk di tick yang sama, tick itu saja menjadi puluhan kali lebih berat. - Mengapa → Akibatnya → Di layar: Timer respawn, kedaluwarsa, hadiah, dan simpan otomatis diatur ke waktu yang sama → Dalam satu tick itu, pekerjaannya puluhan kali lipat dari biasanya → Tersendat sesaat setiap kali waktu yang ditentukan tiba - Gejala: Freeze, Patah-patah / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Secara berkala - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Sebar waktu timer sedikit demi sedikit secara acak, bagi pemrosesannya ke beberapa tick. - Di grafik: Melonjak secara berkala (Waktu tick server) - Yang diperiksa: Kumpulkan waktu-waktu lonjakan tick dan periksa intervalnya (tepat di pergantian jam, setiap 5 menit, dan sebagainya). Cocokkan dengan daftar timer respawn, berakhirnya buff, hadiah, dan simpan otomatis yang berjalan pada waktu yang sama - Cocok jika: Tick selalu melonjak pada waktu yang sama atau dengan interval yang sama, dan pada waktu itu ada pekerjaan timer game yang terpicu bersamaan - Tidak cocok jika: Ada periodenya, tetapi bertepatan dengan waktu jeda di log GC atau waktu cron dan backup server: lebih mungkin jeda GC stop-the-world di server atau tugas terjadwal - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Timeouts, retries, and backoff with jitter](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf) · AWS · Amazon Builders' Library. Tambahkan jitter ke semua timer, pekerjaan berkala, dan pekerjaan tertunda untuk menyebar beban yang menumpuk di waktu yang sama; ada contoh kasus permintaan berperiode 1 menit dari banyak server yang menumpuk di beberapa detik pertama setiap menit #### sp-pathfinding · Lonjakan pathfinding · Pathfinding storms Jika ratusan monster mengejar pemain secara bersamaan sambil menghitung rute, pemakaian CPU menjadi sangat besar. - Mengapa → Akibatnya → Di layar: Monster mengejar secara bersamaan saat mob pulling (menarik banyak monster sekaligus) atau spawn besar-besaran → Pathfinding dihitung untuk setiap monster → Hanya area berburu itu yang slow motion - Gejala: Slow motion / Faktor: Stall - Siapa: Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Simpan rute di cache, batasi jumlah perhitungan, bagi ke beberapa tick. - Di grafik: Naik mengikuti beban (Waktu tick server, jumlah monster per zona) - Yang diperiksa: Periksa jumlah monster yang sedang mengejar pemain per zona dan waktu tick. Jika tidak ada hitungan terpisah, periksa porsi CPU per fungsi proses game dengan perf top -p - Cocok jika: Saat mob pulling atau spawn besar-besaran, waktu tick naik, dan fungsi pathfinding (pencarian rute) memakan porsi besar dari waktu CPU - Tidak cocok jika: Monster sedikit dan hanya pemain yang banyak, tetapi tick naik: lebih mungkin perhitungan jarak pandang atau broadcast - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [AI.NavMesh.pathfindingIterationsPerFrame](https://docs.unity3d.com/ScriptReference/AI.NavMesh-pathfindingIterationsPerFrame.html) · Unity · Pathfinding hanya diproses sebanyak jumlah node tertentu per frame sehingga terbagi ke beberapa frame; game tetap mulus walaupun rutenya panjang atau permintaannya banyak sekaligus - [perf-top(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-top.1.html) · perf · Menampilkan porsi pemakaian CPU per fungsi (simbol) secara real-time untuk proses (-p) yang sedang berjalan #### sp-serialize · Biaya serialisasi dan kompresi · Serialization / compression cost Mengubah data yang akan dikirim menjadi byte dan mengompresinya juga memakan CPU, dan biaya ini melonjak saat pemain banyak. - Mengapa → Akibatnya → Di layar: Setiap update, struct diubah menjadi byte lalu dikompresi → Biaya naik sebanding dengan kuadrat jumlah pemain → Pengiriman terlambat sehingga terjadi input lag - Gejala: Input lag / Faktor: Stall, Latensi - Siapa: Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pakai ulang paket yang sudah dibuat sekali untuk banyak pemain, gunakan format yang ringan. - Di grafik: Naik mengikuti beban (Utilisasi CPU server, CPU thread yang membuat paket) - Yang diperiksa: Dengan perf top -p, bandingkan porsi fungsi serialisasi, kompresi, dan enkripsi (termasuk fungsi library seperti zlib, LZ4, OpenSSL) dalam waktu CPU proses game saat pemain sedikit dan saat pemain berkumpul - Cocok jika: Makin banyak pemain berkumpul, makin besar porsi fungsi serialisasi, kompresi, dan enkripsi, dan CPU thread yang membuat paket jenuh lebih dulu - Tidak cocok jika: Porsi fungsi-fungsi ini kecil: lebih mungkin perhitungan jarak pandang atau logika game - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Pada koneksi yang mengenkripsi paket (TLS, DTLS, dan sebagainya), enkripsi dan dekripsi juga memakai CPU. Enkripsi dilakukan terpisah untuk setiap koneksi, jadi walaupun paket yang sudah dibuat sekali dipakai ulang untuk banyak pemain, biaya enkripsinya tetap sebanyak jumlah penerima. Cipher simetris seperti AES-GCM cukup cepat sehingga satu core bisa memproses beberapa GB per detik, dan porsinya biasanya kecil. Namun, kecepatannya sangat bergantung pada ukuran unit yang dienkripsi sekaligus (record), sehingga pada game dengan banyak paket kecil, biaya per byte menjadi besar. Pada handshake yang dilakukan sekali per koneksi, server menandatangani dengan kunci sertifikat dan menghitung pertukaran kunci (ECDHE). Satu core hanya sanggup melakukan sekitar 1.100 (RSA 2048) hingga 18.000 (ECDSA P-256) tanda tangan per detik dan sekitar 9.000 pertukaran kunci per detik, sehingga menjadi beban saat login menumpuk. - Sumber: - [Introduction to Iris in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/introduction-to-iris-in-unreal-engine) · Epic Games · State yang akan direplikasi disimpan sebagai satu salinan terkuantisasi sehingga pekerjaan yang mahal berkurang, dan hasil pekerjaan itu dipakai bersama oleh banyak koneksi - [VALORANT's 128-Tick Servers](https://www.riotgames.com/en/news/valorants-128-tick-servers) · Riot Games · Cara membandingkan variabel replikasi untuk setiap klien di setiap frame lalu mengemas nilai yang berubah adalah pekerjaan lambat yang membaca memori secara acak, sehingga memakan banyak CPU server - [How "expensive" is crypto anyway?](https://blog.cloudflare.com/how-expensive-is-crypto-anyway/) · Cloudflare · Pengukuran BoringSSL: AES-128-GCM sekitar 3,7 GB per detik (sangat bergantung pada ukuran record); per detik, satu core sanggup melakukan tanda tangan RSA 2048 sebanyak 1.120 kali, tanda tangan ECDSA P-256 sebanyak 18.477 kali, dan ECDHE P-256 sebanyak 9.394 kali; di server edge Cloudflare, CPU yang dipakai library TLS sekitar 1,8% - [perf-top(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-top.1.html) · perf · Menampilkan porsi pemakaian CPU per fungsi (simbol) secara real-time untuk proses (-p) yang sedang berjalan #### sp-crash · Crash di server · Server process crash Jika proses server mati karena error yang tidak tertangani, semua pemain di server itu disconnect bersamaan. - Mengapa → Akibatnya → Di layar: Error fatal seperti error yang menunjuk objek yang tidak ada (null reference), data yang salah, atau memori habis → Proses server (atau zona) mati → Semua pemain disconnect bersamaan, dan progres bisa kembali ke kondisi saat penyimpanan terakhir (rollback) - Gejala: Disconnect, Aksi hilang / rollback / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Sesekali secara acak, Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Analisis crash dump dan perbaiki penyebabnya, simpan lebih sering. - Tugas Tim Infrastruktur: Siapkan restart otomatis untuk proses, lingkungan untuk mengumpulkan dan menyimpan crash dump, alert segera saat server down. - Di grafik: Koneksi putus serentak (Jumlah koneksi, jumlah restart proses) - Yang diperiksa: Periksa catatan core dump di coredumpctl list (waktu, PID, sinyal terminasi) dan catatan terminasi abnormal serta restart di service manager (systemd). Untuk server Windows, periksa file dump yang ditinggalkan WER - Cocok jika: Pada saat jumlah koneksi sesaat anjlok hingga mendekati 0, ada terminasi abnormal proses server game dan core dump - Tidak cocok jika: Proses tetap hidup tetapi koneksi terputus: lebih mungkin perangkat jaringan atau idle timeout. Ada catatan restart oleh watchdog setelah server lama berhenti: lebih mungkin infinite loop atau deadlock - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Collecting User-Mode Dumps](https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps) · Microsoft · Konfigurasi Windows Error Reporting (WER) agar full dump atau mini dump dikumpulkan secara lokal saat program user mode crash - [systemd.service(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd.service.5.html) · systemd · Restart=on-failure memulai ulang service secara otomatis saat terjadi terminasi abnormal, terminasi oleh sinyal (termasuk core dump), atau timeout watchdog; dianjurkan untuk service yang berjalan lama - [coredumpctl(1) — Linux manual page](https://man7.org/linux/man-pages/man1/coredumpctl.1.html) · systemd · Menampilkan daftar core dump yang disimpan systemd-coredump dengan list, beserta waktu crash, PID, dan sinyal penyebab crash #### sp-threadpool · Thread pool habis · Thread pool starvation Jika semua worker thread tertahan oleh pekerjaan lambat, permintaan baru hanya bisa menunggu tanpa kepastian. - Mengapa → Akibatnya → Di layar: Worker thread tertahan karena menunggu respons API eksternal atau DB → Tidak ada thread yang bisa ditugaskan untuk permintaan baru → Fitur tertentu seperti login atau toko mengalami loading tanpa henti - Gejala: Tidak bisa masuk / loading tanpa henti, Input lag, Freeze / Faktor: Stall - Siapa: Fitur tertentu saja, Seluruh server / Kapan: Saat banyak pemain berkumpul, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pasang timeout pada pemanggilan yang lambat, pisahkan thread pool per fitur, ubah ke asinkron. - Di grafik: Mendatar di batas (Jumlah thread dan panjang antrean thread pool, waktu pemrosesan permintaan) - Yang diperiksa: Untuk .NET, periksa jumlah thread dan panjang antrean thread pool di dotnet-counters monitor (.NET 9 ke atas: dotnet.thread_pool.thread.count dan dotnet.thread_pool.queue.length, 8 ke bawah: ThreadPool Thread Count dan ThreadPool Queue Length), lalu cek di mana worker thread menunggu dengan dotnet-stack. Untuk JVM dan server native, cek hal yang sama dengan thread dump - Cocok jika: Utilisasi CPU jauh di bawah 100%, tetapi jumlah thread terus naik perlahan atau menempel di batas atas, antrean menumpuk, dan sebagian besar worker menunggu respons dari pemanggilan eksternal yang sama (DB, HTTP) - Tidak cocok jika: Antrean kosong tetapi tetap lambat: tujuan pemanggilannya sendiri yang lambat, jadi lebih mungkin kegagalan berantai atau ketergantungan pada layanan eksternal - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Pada arsitektur yang memakai worker thread pool yang sama untuk menerima paket dan menjalankan logika game, begitu beberapa pekerjaan lambat menahan semua worker, pemrosesan paket di seluruh server berhenti. - Kasus nyata: riot-euw-2021 - Sumber: - [Debug ThreadPool Starvation](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-threadpool-starvation) · Microsoft · Jika tidak ada thread tersisa di pool dan pekerjaan baru harus menunggu, respons melambat; penyebabnya kode blocking yang menahan thread. Di dotnet-counters, CPU jauh di bawah 100% tetapi dotnet.thread_pool.thread.count terus naik perlahan adalah tanda thread pool habis (dotnet.thread_pool.queue.length juga sering besar); tempat thread menunggu dicek dengan dotnet-stack - [Avoiding insurmountable queue backlogs](https://d1.awsstatic.com/builderslibrary/pdfs/avoiding-insurmountable-queue-backlogs.pdf) · AWS · Jumlah pemrosesan bersamaan = laju kedatangan × latensi (hukum Little). Pada 100 permintaan per detik, jika latensi naik dari 100 ms menjadi 10 detik, kebutuhan thread naik dari 10 menjadi 1.000 sehingga pool habis - [Bulkhead Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead) · Microsoft Azure · Jika connection pool dan thread pool dipisah untuk setiap tujuan pemanggilan, gangguan di satu tujuan hanya memblokir pool miliknya - [.NET runtime metrics](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/built-in-metrics-runtime) · .NET · dotnet.thread_pool.thread.count (jumlah thread di thread pool) dan dotnet.thread_pool.queue.length (jumlah pekerjaan yang menunggu) tersedia sejak .NET 9 - [Well-known EventCounters in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/available-counters) · Microsoft · ThreadPool Thread Count (threadpool-thread-count) dan ThreadPool Queue Length (threadpool-queue-length) untuk .NET 8 ke bawah #### sp-infinite-loop · Infinite loop dan logika lepas kendali · Infinite loop / runaway logic Jika satu tick tidak pernah selesai karena bug, server berhenti, lalu watchdog memulai ulang server secara paksa. - Mengapa → Akibatnya → Di layar: Perulangan tidak pernah selesai karena kondisi yang salah, atau rekursi lepas kendali → Tick tidak selesai sehingga server berhenti → Game freeze, lalu semua pemain disconnect - Gejala: Freeze, Disconnect / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Saat melakukan aksi tertentu, Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Batasi jumlah perulangan, pasang watchdog, buat tes yang mereproduksi input bermasalah. - Di grafik: Koneksi putus serentak (Jumlah koneksi, CPU per thread) - Yang diperiksa: Selama server berhenti, periksa CPU per thread dengan pidstat -t 1, lalu cek di fungsi mana thread yang berputar 100% itu berjalan dengan perf top -t (ID thread) atau gdb. Jika server sudah dimulai ulang, periksa catatan timeout watchdog (WatchdogSec di systemd, liveness probe Kubernetes yang gagal) - Cocok jika: Selama server berhenti, satu thread game menempel di CPU 100%, dan stack-nya terus berputar di dalam fungsi atau perulangan yang sama - Tidak cocok jika: Selama server berhenti CPU mendekati 0: lebih mungkin deadlock atau menunggu respons eksternal - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [systemd.service(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd.service.5.html) · systemd · WatchdogSec=: jika service tidak mengirim sinyal hidup (WATCHDOG=1) dalam waktu yang ditentukan, service dianggap gagal lalu dihentikan, dan dimulai ulang otomatis sesuai pengaturan Restart= - [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) · Kubernetes · Kondisi proses masih berjalan tetapi tidak bisa maju dideteksi oleh liveness probe lalu dimulai ulang; secara default, pemeriksaan dilakukan setiap 10 detik dan restart terjadi setelah 3 kali gagal berturut-turut - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -t menampilkan sekaligus statistik per thread milik proses (utilisasi CPU dan lainnya) - [perf-top(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-top.1.html) · perf · Menampilkan porsi pemakaian CPU per fungsi (simbol) secara real-time untuk thread (-t) atau proses (-p) yang sedang berjalan #### sp-hot-entity · Pertempuran terpusat pada satu target (world boss) · Hot entity / combat event fan-out Jika ratusan pemain menyerang satu boss secara bersamaan, perhitungan untuk boss itu terpusat di satu tempat, dan informasi setiap serangan dikirim ke semua yang melihatnya. - Mengapa → Akibatnya → Di layar: Ratusan pemain terus-menerus memakai skill, buff, dan debuff pada satu boss → Perhitungan HP, daftar aggro, dan debuff boss terpusat di satu tempat, dan setiap serangan mengirim paket angka damage dan efek ke semua yang melihat → Skill terlambat masuk dan angka damage muncul sekaligus, hanya area sekitar boss yang slow motion - Gejala: Input lag, Fast forward, Slow motion / Faktor: Stall, Latensi - Siapa: Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Gabungkan atau hilangkan angka damage dan efek milik pemain lain, batasi jumlah debuff pada satu target, bagi pemrosesan serangan ke beberapa tick. - Kisaran angka: Jika 800 pemain masing-masing menyerang 2 kali per detik, ada 1.600 serangan per detik. Jika semuanya diberitahukan ke 800 pemain yang melihat, jumlahnya 1,28 juta pesan per detik. - Di grafik: Naik mengikuti beban (Waktu tick server, jumlah pesan yang dikirim) - Yang diperiksa: Periksa waktu tick dan jumlah paket kirim pada saat pertarungan boss bersama jumlah pemain di sekitar boss, dan jika memungkinkan, jumlah event (serangan, buff, debuff) per detik untuk setiap target - Cocok jika: Saat pemain di sekitar boss bertambah, waktu tick dan volume kirim naik tajam, dan jumlah event per detik pada satu boss puluhan kali lebih banyak daripada target lain - Tidak cocok jika: Pemain yang hanya berkumpul di satu tempat tanpa boss pun melambat dengan cara yang sama: lebih mungkin perhitungan jarak pandang atau lonjakan broadcast - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [HED-GP Technical Retrospective: What a HED-ache](https://www.eveonline.com/news/view/what-a-hed-ache) · CCP Games · Satu serangan pun harus diberitahukan ke semua klien yang melihat, sehingga muncul beban O(n²), yaitu n pemain memberi tahu n pemain; serangan drone yang menghasilkan banyak pesan membuat beban ini membesar lebih cepat #### sp-spawn-burst · Lonjakan spawn saat masuk area padat · Spawn burst when entering a crowd Saat pemain memakai teleportasi ke kota yang ramai, server harus mengirim tampilan, perlengkapan, dan status ratusan pemain yang baru terlihat sekaligus. - Mengapa → Akibatnya → Di layar: Pemain tiba-tiba muncul di tempat ramai karena teleportasi, login, atau pindah channel → Server membuat dan mengirim informasi lengkap ratusan pemain sekaligus, dan PC Anda juga memuat semuanya sekaligus → Layar freeze sebentar tepat setelah tiba, karakter muncul satu per satu dengan terlambat, dan terjadi input lag - Gejala: Freeze, Input lag, Fast forward / Faktor: Stall, Latensi - Siapa: Hanya saya, Lokasi/channel tertentu / Kapan: Saat bergerak atau pindah area, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kirim bertahap ke beberapa tick mulai dari yang terdekat, simpan informasi tampilan di cache. Klien: terima data lebih dulu selama layar loading, buat karakter yang diterima secara bertahap di beberapa frame. - Kisaran angka: Jika informasi tampilan, perlengkapan, dan buff satu pemain 300 byte, 500 pemain berarti sekitar 150 KB. Dalam sekejap, data sebesar puluhan kali lipat volume kirim satu tick biasa (beberapa KB) menumpuk sekaligus. - Di grafik: Melonjak tepat setelah server dibuka (Byte kirim per koneksi, frame time klien) - Yang diperiksa: Periksa jumlah byte dan paket yang dikirim ke koneksi itu selama beberapa detik setelah tiba di tempat ramai (log server) serta frame time klien (net graph, log klien) - Cocok jika: Tepat setelah tiba, volume kirim koneksi itu melonjak hingga puluhan kali lipat satu tick biasa lalu turun kembali, dan pada saat yang sama frame time klien juga melonjak - Tidak cocok jika: Tetap freeze dengan cara yang sama walaupun pindah ke tempat sepi: lebih mungkin pindah zona (handoff antarserver) atau loading di klien - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Detailed Actor Replication Flow in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/detailed-actor-replication-flow-in-unreal-engine) · Epic Games · Saat actor channel pertama kali dibuka, informasi seperti posisi dan rotasi awal ikut dikirim; jika koneksi jenuh, actor sisanya ditunda ke tick berikutnya - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Prioritas ditentukan berdasarkan jarak dan arah pandang, lalu actor yang dekat dan terlihat dikirim lebih dulu #### sp-entity-buildup · Penumpukan objek (item dan summon yang tidak dibersihkan) · Entity / timer buildup over uptime Jika item di tanah, summon, dan timer yang sudah selesai tidak dibersihkan dan terus menumpuk, makin lama server menyala, makin banyak pekerjaan di setiap tick. - Mengapa → Akibatnya → Di layar: Item di tanah, summon, timer kedaluwarsa, dan data party kosong tidak dihapus tepat waktu → Daftar yang ditelusuri setiap tick makin panjang setiap hari → Normal tepat setelah maintenance, tetapi setelah beberapa hari hanya server atau area itu yang makin lamban - Gejala: Slow motion, Patah-patah, Input lag / Faktor: Stall - Siapa: Seluruh server, Lokasi/channel tertentu / Kapan: Makin lama menyala - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Catat jumlah objek per area sebagai metrik dan pantau trennya, tetapkan umur untuk setiap objek dan batas jumlahnya, bersihkan secara berkala. - Kisaran angka: Pada server yang menelusuri semua objek sekali setiap tick, jika jumlah objek naik dua kali lipat, waktu tick untuk bagian itu juga naik dua kali lipat. - Di grafik: Naik perlahan lalu anjlok (Jumlah objek per zona, waktu tick server) - Yang diperiksa: Tampilkan jumlah objek per zona dan server (item di tanah, summon, timer) serta waktu tick dalam rentang yang lebih panjang dari siklus maintenance (beberapa minggu) - Cocok jika: Jumlah objek dan waktu tick yang mulai rendah tepat setelah maintenance naik setiap hari, lalu anjlok saat maintenance atau restart, berulang terus, dan selama itu memori tetap longgar - Tidak cocok jika: Tick tidak berubah tetapi hanya memori yang terus naik: lebih mungkin kebocoran memori - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Seperti kebocoran memori, kondisinya makin buruk makin lama server menyala. Bedanya, memori masih longgar dan hanya waktu tick yang naik. Jika grafik jumlah objek berbentuk gigi gergaji mengikuti siklus maintenance, inilah penyebabnya. - Sumber: - [Actor Ticking in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-ticking-in-unreal-engine) · Epic Games · Actor dan component menjalankan tick sekali setiap frame jika intervalnya tidak ditetapkan, dan tick bisa dimatikan jika tidak diperlukan - [AActor::SetLifeSpan](https://dev.epicgames.com/documentation/en-us/unreal-engine/API/Runtime/Engine/AActor/SetLifeSpan) · Epic Games · Jika umur ditetapkan pada actor, actor itu otomatis dihancurkan saat umurnya habis #### sp-patch-traffic · Pola trafik berubah akibat patch · Patch changes traffic pattern Jika konten, efek, dan data sinkronisasi baru memperbesar ukuran dan frekuensi paket, server yang tadinya lancar mulai terbentur batas MTU, bandwidth, dan jumlah paket setelah patch. - Mengapa → Akibatnya → Di layar: Patch menambah efek skill, data sinkronisasi, dan informasi item baru sehingga paket menjadi lebih besar atau lebih sering → Paket besar melewati MTU sehingga terfragmentasi, dan volume yang bertambah terbentur bandwidth, batas PPS cloud, dan buffer kirim → Sejak tepat setelah patch, terjadi teleport, skill tidak keluar, dan input lag di tempat ramai. Infrastruktur tidak diubah sama sekali, tetapi packet loss bertambah - Gejala: Teleport, Aksi hilang / rollback, Input lag / Faktor: Packet loss, Latensi - Siapa: Seluruh server, Lokasi/channel tertentu, Wilayah/ISP tertentu / Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari, Selalu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Pecah sendiri paket menjadi maksimal 1.200 byte, kirim hanya perubahan untuk data sinkronisasi baru dan turunkan frekuensinya menurut jarak dan tingkat kepentingan, sebelum deploy bandingkan paket dan byte per detik per pemain serta ukuran paket terbesar dengan build sebelumnya di server uji, catat versi build di metrik trafik. - Tugas Tim Infrastruktur: Server/OS: tandai waktu deploy di grafik dan bandingkan paket dan byte per detik per pemain serta ukuran paket rata-rata sebelum dan sesudah deploy, pasang alert pada counter batas instance terlampaui, pindah ke instance yang lebih besar jika perlu. Jaringan: periksa batas pemrosesan firewall, load balancer, dan perangkat proteksi DDoS, serta apakah fragmen diblokir. - Kisaran angka: Paket UDP aman jika berukuran maksimal 1.200 byte. MTU jalur internet biasanya 1.500 byte dan lebih kecil jika melewati tunnel (1.476 byte untuk tunnel GRE). Paket yang melewati MTU jalur akan terfragmentasi atau dibuang, dan paket yang terfragmentasi hilang seluruhnya walaupun hanya satu fragmen yang hilang. Jika paket per detik per pemain naik 20%, total di server juga naik 20%, sehingga instance yang sudah dipakai mendekati batas langsung melewatinya. - Di grafik: Naik seperti anak tangga (Paket dan byte per detik per pemain, ukuran paket rata-rata) - Yang diperiksa: Bagi paket dan byte per detik di NIC server (rxpck/s, txpck/s, rxkB/s, txkB/s dari sar -n DEV; di EC2: NetworkPacketsOut dan NetworkOut) dengan jumlah pemain online bersamaan, lalu bandingkan sebelum dan sesudah waktu deploy. Hitung ukuran paket rata-rata dengan byte ÷ paket, dan lihat distribusi ukurannya dari packet capture lewat statistik Packet Lengths di Wireshark - Cocok jika: Sejak tepat setelah deploy, paket dan byte per pemain atau ukuran paket rata-rata naik satu tingkat lalu bertahan, dan sejak waktu yang sama jumlah fragmen yang dibuat server (fragcrt/s di sar -n IP) atau counter batas instance terlampaui (pps_allowance_exceeded dan bw_out_allowance_exceeded di AWS ENA) bertambah - Tidak cocok jika: Pola trafik sama sebelum dan sesudah deploy, tetapi hanya latensi dan packet loss yang naik: periksa perubahan infrastruktur pada waktu yang sama (konfigurasi, rute, perangkat, update OS dan kernel) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jika ada laporan “sebelum patch lancar-lancar saja”, inilah penyebab dari sisi game yang perlu diperiksa lebih dulu bersama perubahan infrastruktur. Walaupun catatan patch tidak menyebut perubahan jaringan, di tempat ramai satu efek atau data sinkronisasi baru dikalikan ratusan pemain. Titik tempat trafik tambahan itu benar-benar terbentur dibahas di entri “Fragmentasi IP pada paket UDP”, “Batas PPS cloud terlampaui”, “Bandwidth NIC penuh”, “Buffer socket kernel terlalu kecil”, dan “Batas pemrosesan perangkat perantara terlampaui (firewall, IPS, proteksi DDoS)”. Entri ini membahas kasus ketika titik awal yang membuat batas itu tersentuh adalah patch game, jadi kurangi dulu trafik yang bertambah akibat patch sebelum menaikkan batas. Jika OS dan kernel juga diperbarui pada waktu yang sama, bedakan dari “Perubahan performa setelah update OS, kernel, driver, atau firmware” dengan melihat apakah trafik per pemain berubah. - Sumber: - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Aplikasi UDP sebaiknya tidak mengirim datagram yang melewati MTU jalur (SHOULD NOT); jika satu fragmen hilang, seluruh paket yang terfragmentasi ikut hilang, dan sebagian NAT dan firewall membuang semua fragmen - [RFC 8899: Packetization Layer Path MTU Discovery for Datagram Transports](https://www.rfc-editor.org/rfc/rfc8899) · IETF · 1.200 byte disarankan sebagai ukuran aman dasar (BASE_PLPMTU) untuk transport datagram seperti UDP - [Maximum transmission unit and maximum segment size](https://developers.cloudflare.com/magic-transit/reference/mtu-mss/) · Cloudflare · MTU jalur internet 1.500, atau 1.476 jika melewati tunnel GRE - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · pps_allowance_exceeded dan bw_out_allowance_exceeded: jumlah paket yang masuk antrean atau dibuang karena melewati batas PPS atau bandwidth kirim instance - [sar(1) — Linux manual page](https://man7.org/linux/man-pages/man1/sar.1.html) · sysstat · rxpck/s dan txpck/s (paket per detik) serta rxkB/s dan txkB/s (KB per detik) di sar -n DEV; fragcrt/s (fragmen IP yang dibuat per detik, ipFragCreates) di sar -n IP - [CloudWatch metrics that are available for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · NetworkPacketsOut (jumlah paket yang dikirim instance lewat semua network interface) dan NetworkOut (jumlah byte yang dikirim) - [8.7. Packet Lengths](https://www.wireshark.org/docs/wsug_html_chunked/ChStatPacketLengths.html) · Wireshark · Membagi paket yang ditangkap ke dalam rentang panjang dan menampilkan jumlah, rata-rata, minimum, dan maksimumnya ### L10 Memori (9 penyebab) #### mem-gc · Jeda GC stop-the-world di server · Stop-the-world GC pause Selama server Java atau C# menghentikan semua thread untuk mengumpulkan garbage (stop-the-world), seluruh server berhenti. - Mengapa → Akibatnya → Di layar: Heap penuh, GC dimulai → Semua thread game dihentikan untuk pengumpulan garbage (makin banyak data hidup, makin lama) → Semua pemain di server berhenti bersamaan, lalu fast forward - Gejala: Freeze, Fast forward / Faktor: Stall - Siapa: Seluruh server / Kapan: Secara berkala, Makin lama menyala - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Tetapkan GC dengan jeda singkat (ZGC, Shenandoah, G1 dengan target jeda lebih kecil) secara eksplisit lewat opsi startup, kurangi alokasi, sesuaikan ukuran heap. - Tugas Tim Infrastruktur: Pilih instance dengan memori yang cukup untuk heap yang longgar, alokasikan minimal 2 CPU dan memori minimal sekitar 1,8 GB untuk container (JDK 26 dan versi sebelumnya memilih Serial GC sebagai default jika kurang dari itu), pantau waktu jeda GC. - Kisaran angka: Minor GC, yang hanya mengumpulkan objek baru (young generation), butuh beberapa hingga puluhan ms. Full GC yang mengumpulkan seluruh heap dengan data hidup beberapa GB bisa memakan lebih dari 1 detik. Jeda ZGC kurang dari 1 ms dan hampir tidak bergantung pada ukuran heap. Jeda Shenandoah juga singkat karena tidak sebanding dengan ukuran heap. - Di grafik: Melonjak secara berkala (Waktu tick server, waktu jeda GC) - Yang diperiksa: Aktifkan log GC, lalu tumpangkan waktu dan lama jeda di grafik waktu tick server. Java: baris Pause dari opsi startup -Xlog:gc* (JDK 8 ke bawah: -XX:+PrintGCDetails); .NET: metrik jeda GC di dotnet-counters (.NET 9 ke atas: dotnet.gc.pause.time, 8 ke bawah: % Time in GC since last GC); Go: baris yang ditulis GODEBUG=gctrace=1 setiap kali GC berjalan - Cocok jika: Lonjakan tick dan jeda GC terjadi di waktu yang sama, lama jeda kira-kira sama dengan lama lonjakan. Semua zona dan channel di server melonjak bersamaan - Tidak cocok jika: Tidak ada jeda panjang di log GC, tetapi tick tetap melonjak: lebih mungkin penyebab lain seperti lock, pemanggilan sinkron, atau penulisan disk. Hanya satu zona yang melonjak: lebih mungkin GC engine skrip (mem-script-gc) atau beban di zona itu - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Target jeda G1 di Java secara default 200 ms per jeda, setara dengan 4 tick di server 20 tick. Jika container diberi kurang dari 2 CPU atau memori kurang dari sekitar 1,8 GB, Java versi JDK 26 dan sebelumnya memilih Serial GC sebagai GC default. Serial GC mengumpulkan garbage dengan satu thread, sehingga jedanya jauh lebih panjang. Server C# (.NET) biasanya mengaktifkan server GC dan background GC, tetapi pengumpulan generasi 0 dan 1 (Gen0/1) yang menampung objek baru, serta Full GC yang disertai kompaksi, tetap menghentikan semua thread. Jeda GC di Go biasanya kurang dari 1 ms, tetapi jika alokasinya banyak, pihak yang meminta memori harus ikut mengerjakan sebagian tugas GC sehingga tick melambat. Apa pun mekanismenya, jika alokasi lebih cepat daripada pengumpulan, thread game akhirnya tetap berhenti. G1 beralih ke Full GC, sedangkan ZGC menghentikan thread yang meminta memori sampai pengumpulan selesai. - Kasus nyata: riot-euw-2021 - Sumber: - [Garbage-First (G1) Garbage Collector](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-first-g1-garbage-collector1.html) · Oracle · Target jeda G1 default 200 ms (MaxGCPauseMillis); jika memori habis saat pengumpulan, G1 beralih ke Full GC yang menghentikan semua thread dan melakukan kompaksi pada seluruh heap - [JEP 523: Make G1 the Default Garbage Collector in All Environments](https://openjdk.org/jeps/523) · OpenJDK · Selama ini Serial GC dipilih sebagai default jika CPU hanya 1 atau memori kurang dari 1.792 MB; mulai JDK 27, G1 menjadi default di semua lingkungan - [JEP 439: Generational ZGC](https://openjdk.org/jeps/439) · OpenJDK · Jeda ZGC maksimal 1 ms dan tidak bergantung pada ukuran heap, jeda G1 beberapa ms hingga beberapa detik. Jika alokasi lebih cepat daripada pengambilan kembali memori, ada risiko allocation stall - [JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)](https://openjdk.org/jeps/189) · OpenJDK · Waktu jeda Shenandoah kurang lebih sama, baik untuk heap 200 MB maupun 200 GB - [Background garbage collection](https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/background-gc) · .NET · Background GC hanya berlaku untuk pengumpulan generasi 2; pengumpulan generasi 0 dan 1 (foreground GC) menghentikan semua managed thread - [A Guide to the Go Garbage Collector](https://go.dev/doc/gc-guide) · Go · GC Go sebagian besar berjalan secara konkuren dan hanya punya jeda stop-the-world yang singkat; jika alokasinya banyak, goroutine ikut mengerjakan tugas GC (assist) sehingga timbul keterlambatan - [JEP 271: Unified GC Logging](https://openjdk.org/jeps/271) · OpenJDK · Sejak JDK 9, log GC diimplementasikan ulang dengan unified logging (-Xlog); -Xlog:gc menulis satu baris per GC seperti -XX:+PrintGC versi lama - [The java Command](https://docs.oracle.com/en/java/javase/25/docs/specs/man/java.html) · Oracle · Tabel padanan opsi log GC lama ke -Xlog: -XX:+PrintGCDetails menjadi -Xlog:gc* - [dotnet-counters diagnostic tool](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters) · .NET · .NET 9 ke atas menampilkan meter System.Runtime (dotnet.gc.pause.time dan lainnya), .NET 8 ke bawah menampilkan EventCounter lama (% Time in GC since last GC dan lainnya) - [runtime package](https://pkg.go.dev/runtime) · Go · GODEBUG=gctrace=1: satu baris per GC, berisi wall clock time per fase, ukuran heap di awal dan akhir GC, serta target heap #### mem-script-gc · Jeda GC di engine skrip · Scripting VM GC (Lua, etc.) Walaupun servernya ditulis dengan C++, jika quest, AI, dan skill dijalankan dengan skrip seperti Lua, zona itu berhenti selama GC engine skrip berjalan. - Mengapa → Akibatnya → Di layar: Engine skrip di setiap zona menjalankan quest, AI, dan event sambil membuat objek sementara dalam jumlah besar → Saat GC engine skrip mengumpulkan banyak garbage sekaligus, tick zona itu terhenti → Tersendat sesaat secara berkala, hanya di zona tertentu atau selama event tertentu - Gejala: Patah-patah, Freeze / Faktor: Stall - Siapa: Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul, Secara berkala - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Atur GC ke mode incremental atau generational, jalankan GC sedikit demi sedikit di setiap tick, kurangi objek sementara di skrip. - Kisaran angka: Jika heap skrip membesar hingga ratusan MB, pengumpulan sekaligus (saat pengumpulan incremental dimatikan, atau pengumpulan penuh di mode generational) bisa memakan puluhan hingga ratusan ms. - Di grafik: Melonjak secara berkala (Waktu tick per zona, memori engine skrip) - Yang diperiksa: Catat waktu tick per zona dan penggunaan memori engine skrip di zona itu (Lua: collectgarbage("count")) di setiap tick, lalu tumpangkan dalam satu grafik - Cocok jika: Memori skrip anjlok (pengumpulan sekaligus) tepat saat tick zona itu melonjak, sementara zona lain normal - Tidak cocok jika: Tick melonjak tanpa perubahan memori skrip: lebih mungkin beban atau lock di zona itu. Semua zona di server melonjak bersamaan: lebih mungkin GC server (mem-gc) atau swap (mem-swap) - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Lua 5.4 Reference Manual](https://www.lua.org/manual/5.4/manual.html) · Lua.org · Mode incremental membagi pengumpulan menjadi langkah-langkah kecil yang diselipkan di antara eksekusi program (jika langkahnya dibuat besar, menjadi stop-the-world); pengumpulan major di mode generational adalah stop-the-world yang menelusuri semua objek; collectgarbage("count") mengembalikan total memori yang dipakai Lua (KB) #### mem-alloc · Lonjakan alokasi · Allocation storms Jika objek sementara dibuat dalam jumlah besar selama event, GC berjalan jauh lebih sering daripada biasanya. - Mengapa → Akibatnya → Di layar: Objek sementara melonjak karena drop item, log pertempuran, dan hadiah event → GC berjalan beberapa kali lebih sering, dan objek yang belum sempat dibuang pindah ke old generation sehingga Full GC juga datang lebih cepat → Tersendat sesaat secara berkala, hanya saat event - Gejala: Patah-patah, Freeze / Faktor: Stall - Siapa: Seluruh server, Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Gunakan object pool, pakai ulang buffer, lakukan profiling alokasi. - Di grafik: Naik mengikuti beban (Jumlah GC, laju alokasi) - Yang diperiksa: Hitung jumlah GC per menit dari log GC (Java: -Xlog:gc, Go: GODEBUG=gctrace=1); untuk .NET, periksa volume alokasi dan jumlah GC di dotnet-counters (.NET 9 ke atas: dotnet.gc.heap.total_allocated dan dotnet.gc.collections, 8 ke bawah: Allocation Rate dan Gen 0 GC Count). Tumpangkan dengan jumlah pemain online bersamaan dan waktu event - Cocok jika: Begitu event dimulai, laju alokasi dan jumlah GC naik lebih tajam daripada kenaikan jumlah pemain, dan jeda singkat makin sering. Setelah event selesai, kembali normal - Tidak cocok jika: Jumlah GC tetap, tetapi setiap jeda makin panjang: mengarah ke data hidup yang bertambah (mem-gc-thrash, mem-leak) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Garbage Collector Implementation](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation.html) · Oracle · Saat young generation penuh terjadi minor GC; sebagian objek yang bertahan dipindahkan ke old generation, dan saat old generation penuh, seluruh heap dikumpulkan (jauh lebih lama daripada minor GC); -Xlog:gc mencatat satu baris per GC - [A Guide to the Go Garbage Collector](https://go.dev/doc/gc-guide) · Go · Makin tinggi laju alokasi, makin sering siklus GC; output trace GC dengan GODEBUG=gctrace=1 - [dotnet-counters diagnostic tool](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters) · .NET · .NET 9 ke atas menampilkan dotnet.gc.heap.total_allocated dan dotnet.gc.collections, .NET 8 ke bawah menampilkan Allocation Rate dan Gen 0 GC Count #### mem-leak · Kebocoran memori · Memory leak Memori yang tidak dibebaskan menumpuk sedikit demi sedikit, lalu beberapa hari kemudian berujung pada GC yang berjalan tanpa henti, swap, atau proses yang dihentikan paksa. - Mengapa → Akibatnya → Di layar: Data karakter yang sudah logout dan event handler tidak dibebaskan → Memori bebas berkurang selama beberapa hari → Normal tepat setelah maintenance, makin hari makin lag, akhirnya server down - Gejala: Slow motion, Freeze, Disconnect / Faktor: Stall - Siapa: Seluruh server / Kapan: Makin lama menyala, Jam sibuk malam hari - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Analisis heap dump, jalankan load test jangka panjang. - Tugas Tim Infrastruktur: Pantau tren penggunaan memori per proses dan pasang alert. - Di grafik: Naik perlahan (Memori proses (RSS), heap tepat setelah GC) - Yang diperiksa: Periksa memori proses server game (RSS di pidstat -r) dalam rentang beberapa hari, dan untuk server yang memakai GC, periksa heap yang tersisa tepat setelah GC. Java: nilai setelah GC dari pasangan penggunaan sebelum dan sesudah GC di baris -Xlog:gc; .NET: ukuran heap setelah GC di dotnet-counters (.NET 9 ke atas: dotnet.gc.last_collection.heap.size, 8 ke bawah: GC Heap Size) - Cocok jika: Heap yang tersisa tepat setelah GC (garis dasar) naik setiap hari sejak restart, dan tetap tidak turun pada dini hari saat pemain sedikit - Tidak cocok jika: Garis dasar heap datar tetapi hanya RSS yang naik: lebih mungkin fragmentasi (mem-fragment) atau native memory. Naik turun mengikuti jumlah pemain: penggunaan normal - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jika server dimulai ulang setiap minggu saat maintenance rutin, kebocoran tertutupi dan lama tidak ketahuan. Kebocoran sering baru muncul tiba-tiba saat maintenance tertunda sekali saja, atau saat jumlah pemain bertambah karena event. - Sumber: - [Troubleshoot Memory Leaks](https://docs.oracle.com/en/java/javase/25/troubleshoot/troubleshooting-memory-leaks.html) · Oracle · Jika eksekusi makin lambat, curigai kebocoran; akhirnya memori habis dan terjadi terminasi abnormal. Data utama untuk analisis kebocoran adalah heap dump - [Debug a memory leak in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-memory-leak) · .NET · Walaupun ada GC, objek yang tidak diperlukan tetapi terus direferensikan menjadi kebocoran, yang menyebabkan penurunan performa dan OutOfMemoryException. Memeriksa tren memori dan menganalisis dump - [Garbage Collector Implementation](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation.html) · Oracle · Baris -Xlog:gc berformat “penggunaan sebelum GC->penggunaan setelah GC (ukuran heap)” - [dotnet-counters diagnostic tool](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters) · .NET · .NET 9 ke atas menampilkan dotnet.gc.last_collection.heap.size, .NET 8 ke bawah menampilkan GC Heap Size - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -r: RSS per proses (memori yang benar-benar ada di RAM) dan page fault #### mem-gc-thrash · GC thrashing (heap hampir penuh) · GC thrashing (heap nearly full) Jika data hidup mendekati batas heap, GC hampir tidak bisa membebaskan memori setiap kali berjalan, sehingga GC berulang tanpa henti. - Mengapa → Akibatnya → Di layar: Data hidup memenuhi heap hingga mendekati batasnya karena jumlah pemain bertambah saat event atau karena kebocoran → GC hanya membebaskan sedikit memori sehingga Full GC langsung berjalan lagi, dan sebagian besar CPU terpakai untuk GC → Seluruh server berulang kali slow motion dan freeze selama beberapa menit, lalu mati karena kehabisan memori - Gejala: Slow motion, Freeze, Disconnect / Faktor: Stall - Siapa: Seluruh server / Kapan: Jam sibuk malam hari, Saat banyak pemain berkumpul, Makin lama menyala - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Atur heap jauh lebih besar daripada data hidup saat puncak (biasanya minimal 2 kali lipat), kurangi kebocoran dan data yang direferensikan dalam waktu lama. - Tugas Tim Infrastruktur: Pasang alert rasio waktu GC, jangan menunda dan segera lakukan restart, pilih instance dengan memori cukup agar heap bisa diperbesar. - Kisaran angka: Jika GC memakai lebih dari 10% waktu eksekusi, biasanya itu dianggap tanda bahaya. Sebagian GC di Java memunculkan error kehabisan memori jika 98% waktu sudah dipakai untuk GC tetapi hampir tidak ada memori yang berhasil dibebaskan. - Di grafik: Mendatar di batas (Heap tepat setelah GC, rasio waktu GC) - Yang diperiksa: Periksa seberapa dekat heap yang tersisa tepat setelah GC dengan heap maksimum, dan rasio waktu yang dipakai untuk GC. Java: bagian “setelah GC (ukuran heap)” di baris -Xlog:gc dan frekuensi baris Pause Full; .NET: dotnet-counters (.NET 8 ke bawah: % Time in GC since last GC, .NET 9 ke atas: kenaikan dotnet.gc.pause.time); Go: jarak antarbaris GODEBUG=gctrace=1 - Cocok jika: Heap tetap mendekati maksimum bahkan tepat setelah GC, Full GC berjalan beruntun, dan rasio waktu GC naik jauh di atas biasanya (umumnya lebih dari 10%). Selama itu tick seluruh server ikut melambat - Tidak cocok jika: Heap masih longgar tepat setelah GC, hanya jedanya yang panjang: lebih mungkin jenis atau pengaturan GC (mem-gc) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [The Parallel Collector](https://docs.oracle.com/en/java/javase/25/gctuning/parallel-collector1.html) · Oracle · Parallel GC memunculkan OutOfMemoryError jika lebih dari 98% total waktu dipakai untuk GC tetapi heap yang dibebaskan kurang dari 2% - [Garbage-First Garbage Collector Tuning](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-first-garbage-collector-tuning.html) · Oracle · Secara default (GCTimeRatio=12), G1 menentukan ukuran heap agar waktu GC sekitar 8% dari total waktu atau kurang; Full GC akibat okupansi heap yang terlalu tinggi ditemukan lewat Pause Full (G1 Compaction Pause) di log - [A Guide to the Go Garbage Collector](https://go.dev/doc/gc-guide) · Go · Dengan default GOGC=100, target heap sekitar 2 kali heap hidup; jika menempel di batas memori, terjadi thrashing, yaitu GC berjalan tanpa henti; output trace GC dengan GODEBUG=gctrace=1 - [Garbage Collector Implementation](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation.html) · Oracle · Baris -Xlog:gc berisi jenis GC (Pause Young, Pause Full), “penggunaan sebelum GC->penggunaan setelah GC (ukuran heap)”, dan lama jeda - [dotnet-counters diagnostic tool](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-counters) · .NET · .NET 9 ke atas menampilkan dotnet.gc.pause.time, .NET 8 ke bawah menampilkan % Time in GC since last GC #### mem-swap · Swap · Swapping Jika memori kurang dan OS memindahkan sebagiannya ke disk, setiap kali memori itu dipakai, proses harus menunggu disk yang lebih dari 1.000 kali lebih lambat. - Mengapa → Akibatnya → Di layar: Memori yang dipakai melebihi RAM fisik → OS memindahkan sebagian memori ke disk dan membacanya lagi saat dibutuhkan → Tick melonjak hingga ratusan ms, sehingga semua pemain di server mengalami slow motion dan freeze - Gejala: Slow motion, Freeze / Faktor: Stall - Siapa: Seluruh server / Kapan: Makin lama menyala, Jam sibuk malam hari - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Beri batas atas penggunaan memori proses (ukuran heap dan sebagainya), periksa kebocoran. - Tugas Tim Infrastruktur: Atur server game agar tidak memakai swap, tangani lewat alert memori, sediakan RAM yang lebih longgar daripada penggunaan puncak karena tanpa swap proses langsung dihentikan paksa (OOM) begitu memori kurang. - Kisaran angka: Baca RAM sekitar 100 ns, baca ulang dari SSD sekitar 100 µs (1.000 kali), disk cloud di seberang jaringan sekitar 1 ms (10.000 kali), HDD 10 ms (100.000 kali). - Di grafik: Naik perlahan (Penggunaan swap, swap in/out) - Yang diperiksa: Tumpangkan kolom si dan so di vmstat 1 (jumlah yang dibaca dari swap dan dikirim ke swap per detik), some dan full di /proc/pressure/memory (rasio waktu tertahan karena menunggu memori), serta majflt/s dari pidstat -r untuk proses server game (page fault yang harus dibaca dari disk) dengan waktu tick - Cocok jika: Saat lag terjadi, si lebih besar dari 0, dan majflt/s server game serta nilai full di PSI memory ikut naik - Tidak cocok jika: si dan so 0, dan tekanan memori (PSI memory) juga mendekati 0: swap bukan penyebabnya. Tidak ada swap tetapi majflt/s dan PSI naik: memori habis sehingga code page dibaca ulang, jadi tambah memori terlebih dahulu - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Server yang memakai GC membaca berbagai bagian heap saat pengumpulan, jadi walaupun hanya sebagian heap yang masuk swap, satu kali GC bisa memanjang menjadi beberapa hingga puluhan detik. Jika swap dimatikan, server langsung dihentikan paksa (OOM) tanpa melewati tahap melambat karena swap, jadi sediakan memori cadangan terlebih dahulu. Walaupun tanpa swap, jika memori hampir habis, OS juga mengeluarkan code page file executable dari memori lalu membacanya lagi, sehingga seluruh server bisa sangat lambat untuk beberapa waktu sebelum dihentikan paksa. - Sumber: - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · “Numbers Everyone Should Know”: referensi main memory 100 ns, seek disk 10 ms (data tahun 2009) - [Documentation for /proc/sys/vm/](https://docs.kernel.org/admin-guide/sysctl/vm.html) · Linux kernel · swappiness: biaya relatif antara swap dan pengambilan kembali file page; swap mahal karena berupa I/O acak - [Concepts overview](https://docs.kernel.org/admin-guide/mm/concepts.html) · Linux kernel · Kernel mengambil kembali page cache yang aslinya tersimpan di disk dan page yang bisa di-swap; jika masih kurang, OOM killer mematikan proses - [Solidigm™ D7-P5520 and D7-P5620 Product Brief](https://www.solidigm.com/products/data-center/product-briefs/d7-p5520-p5620-product-brief.html) · Solidigm · Latensi 99,99% (four-nines latency) SSD NVMe server 130 µs: dasar bahwa satu kali baca SSD sekitar 100 µs - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · Latensi disk standar cloud (gp3) dalam kisaran satu digit ms - [vmstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/vmstat.8.html) · procps-ng · si: memori yang dibaca dari swap per detik, so: memori yang dikirim ke swap per detik - [PSI - Pressure Stall Information](https://docs.kernel.org/accounting/psi.html) · Linux kernel · some (rasio waktu sebagian task tertahan) dan full (rasio waktu semua task tertahan bersamaan) di /proc/pressure/memory - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -r: majflt/s (jumlah fault yang mengharuskan page dibaca dari disk) #### mem-cache-miss · Cache miss · CPU cache misses Jika data tersebar di berbagai tempat di memori, CPU harus menunggu setiap kali mengambilnya dari RAM yang lambat. - Mengapa → Akibatnya → Di layar: Objek tersebar lewat pointer dan diakses tanpa urutan → Data tidak ada di cache CPU sehingga setiap kali harus dibaca dari RAM (sekitar 100 kali lebih lambat) → Untuk pekerjaan yang sama, biaya tick menjadi beberapa kali lipat; jika parah, terjadi slow motion - Gejala: Slow motion / Faktor: Stall - Siapa: Seluruh server / Kapan: Selalu, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Letakkan data yang sering dipakai bersama secara berurutan di memori (data-oriented design). - Di grafik: Selalu tinggi sejak awal (Waktu tick, utilisasi CPU) - Yang diperiksa: Jalankan perf stat -d -p PID pada proses server game untuk mengukur jumlah instruksi per siklus (insn per cycle) serta cache miss L1 dan LLC, lalu bandingkan dengan waktu tick dan utilisasi CPU - Cocok jika: CPU terus sibuk, tetapi insn per cycle rendah dan LLC miss banyak. Pasti penyebab ini jika build dengan tata letak data yang diubah menurunkan waktu tick secara drastis pada jumlah pemain yang sama - Tidak cocok jika: Utilisasi CPU rendah tetapi tick lambat: lebih mungkin penyebab yang menunggu di luar CPU, seperti lock atau menunggu I/O - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Cache L1 0,5 ns, cache L2 7 ns, main memory 100 ns (data tahun 2009): akses sampai RAM satu atau dua orde besaran lebih lambat daripada cache - [perf-stat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-stat.1.html) · perf · -p menghitung event hardware dari proses yang sedang berjalan dan menampilkan insn per cycle; -d menambahkan event data cache L1 dan LLC #### mem-fragment · Fragmentasi memori · Heap fragmentation Jika alokasi dan pembebasan yang berulang memecah ruang kosong menjadi potongan kecil, proses menahan memori jauh lebih banyak daripada yang benar-benar dipakai. - Mengapa → Akibatnya → Di layar: Banyak thread mengalokasikan dan membebaskan memori berukuran beragam dalam waktu lama → Ruang kosong tersebar dalam potongan kecil sehingga tidak bisa dikembalikan ke OS, dan penggunaan memori terus naik seperti kebocoran → Makin lama menyala, makin lambat karena swap atau kehabisan memori, lalu dihentikan paksa - Gejala: Slow motion, Disconnect / Faktor: Stall - Siapa: Seluruh server / Kapan: Makin lama menyala - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Gunakan memory pool per ukuran dan allocator yang tahan fragmentasi (jemalloc, mimalloc, dan lainnya). - Di grafik: Naik perlahan (Memori proses (RSS)) - Yang diperiksa: Jalankan dua server dengan build yang sama; pada salah satunya saja, kurangi jumlah arena glibc dengan environment variable MALLOC_ARENA_MAX atau ganti ke allocator lain seperti jemalloc, lalu bandingkan RSS di pidstat -r selama beberapa hari - Cocok jika: Jumlah pemain dan objek kurang lebih sama, tetapi hanya server yang diubah yang kenaikan RSS-nya berhenti atau turun drastis - Tidak cocok jika: RSS tetap naik dengan cara yang sama walaupun allocator diganti: mengarah ke memori yang tidak dibebaskan (mem-leak) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Polanya sama dengan kebocoran, tetapi analisis heap tidak menemukan titik kebocorannya. Allocator default Linux (glibc) sangat rentan pada server dengan banyak thread, sehingga mengganti allocator saja kadang sudah menurunkan penggunaan memori secara drastis. - Sumber: - [mallopt(3) — Linux manual page](https://man7.org/linux/man-pages/man3/mallopt.3.html) · Linux man-pages · glibc malloc membuat arena hingga kelipatan jumlah CPU untuk mengurangi perebutan di antara thread, dan makin banyak arena, makin besar penggunaan memori (dibatasi dengan M_ARENA_MAX, bisa juga diatur lewat environment variable MALLOC_ARENA_MAX) - [jemalloc memory allocator](https://jemalloc.net/) · jemalloc · Implementasi malloc serbaguna yang mengutamakan penghindaran fragmentasi dan skalabilitas konkurensi - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -r: RSS per proses (memori yang benar-benar ada di RAM) #### mem-numa · Akses memori NUMA remote · Remote NUMA access Pada server dengan dua CPU, akses memori melambat jika thread memakai memori yang terpasang pada CPU seberang. - Mengapa → Akibatnya → Di layar: Thread dan memori ditempatkan di socket CPU yang berbeda → Akses memori melambat (1,5–2 kali, tergantung perangkat) → Spesifikasi sama, tetapi performa berbeda di setiap proses - Gejala: Slow motion / Faktor: Stall - Siapa: Seluruh server / Kapan: Selalu - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Kunci proses dan memori di satu socket (numactl); jika ada dua socket, jalankan proses server game terpisah untuk setiap socket. - Di grafik: Hanya sebagian yang tinggi (Waktu tick per proses, memori per node) - Yang diperiksa: Dengan numastat -p PID, periksa di node NUMA mana memori proses server game berada dan apakah numa_miss dan other_node di numastat bertambah, lalu bandingkan dengan node CPU tempat proses itu berjalan - Cocok jika: Hanya proses yang lambat yang sebagian besar memorinya ada di node yang berbeda dari CPU tempatnya berjalan, dan perbedaannya hilang setelah proses dijalankan ulang dengan CPU dan memori dikunci di satu node menggunakan numactl - Tidak cocok jika: Penempatan node sama dengan proses yang cepat tetapi tetap lambat: lebih mungkin penyebab lain seperti noisy neighbor, CPU throttling, atau beban proses itu sendiri - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [What is NUMA?](https://docs.kernel.org/mm/numa.html) · Linux kernel · Memori di cell yang sama lebih cepat dan bandwidth-nya lebih besar, sedangkan akses ke memori di cell lain (remote) lebih lambat - [numactl(8) — Linux manual page](https://man7.org/linux/man-pages/man8/numactl.8.html) · numactl · --cpunodebind dan --membind mengunci CPU dan memori proses ke node NUMA tertentu - [numastat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/numastat.8.html) · numactl · Counter numa_miss (dialokasikan di node selain yang diinginkan) dan other_node (dialokasikan di node ini oleh proses yang berjalan di node lain); -p menampilkan memori proses per node ### L11 Disk (9 penyebab) #### dk-sync-log · Penulisan log sinkron · Synchronous logging Jika thread game menunggu disk selesai menulis untuk setiap baris log, jalannya game ikut berhenti saat disk sibuk. - Mengapa → Akibatnya → Di layar: Log pertempuran dan trade langsung ditulis ke file dari thread game → Jika penyimpanan pasti (fsync) diminta atau buffer tulis OS (page cache) mencapai batasnya, satu kali penulisan butuh puluhan ms saat disk sibuk → Tersendat sesaat dalam pertempuran yang menghasilkan banyak log - Gejala: Patah-patah, Freeze / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Gunakan logging asinkron (buffer memori + thread terpisah), kurangi volume log, jangan memanggil fsync di thread game. - Tugas Tim Infrastruktur: Jalankan rotasi dan kompresi log dengan prioritas I/O rendah, simpan log di disk yang terpisah dari data, pantau latensi tulis disk. - Di grafik: Melonjak acak sesekali (Waktu tick server, latensi tulis disk) - Yang diperiksa: Tumpangkan w_await dan aqu-sz di iostat -x 1 dengan waktu tick, lalu dengan perf trace -p PID --duration 10 cari pemanggilan write dan fsync di server game yang memakan lebih dari 10 ms beserta thread-nya - Cocok jika: Saat tick melonjak, pemanggilan write dan fsync di thread game memakan puluhan ms, dan latensi tulis disk juga melonjak di saat yang sama. Sering bertepatan dengan waktu rotasi atau kompresi log - Tidak cocok jika: Tidak ada system call yang lama di thread game tetapi tick melonjak: lebih mungkin penyebab lain seperti GC, lock, atau tick yang melewati budget. Hanya thread khusus log yang lama: tidak memengaruhi jalannya game - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Biasanya OS menampung penulisan di memori (page cache) lebih dulu dan baru menuliskannya ke disk belakangan, jadi satu baris log umumnya langsung selesai. Jeda terjadi saat penyimpanan pasti diminta dengan fsync, saat penulisan yang tertunda melewati batas sehingga OS memblokir pemanggilan write, dan saat file log dirotasi atau dikompresi. Karena itu, tick normal di waktu biasa dan baru melonjak saat disk sedang sibuk. - Sumber: - [fsync(2) — Linux manual page](https://man7.org/linux/man-pages/man2/fsync.2.html) · Linux man-pages · fsync menuliskan data yang berubah sampai ke disk (termasuk cache disk) dan memblokir sampai perangkat melaporkan selesai - [Documentation for /proc/sys/vm/](https://docs.kernel.org/admin-guide/sysctl/vm.html) · Linux kernel · Jika penulisan yang tertunda (dirty) mencapai dirty_ratio, proses yang menulis harus menuliskan data ke disk sendiri - [ionice(1) — Linux manual page](https://man7.org/linux/man-pages/man1/ionice.1.html) · util-linux · Tugas yang dijalankan dengan prioritas I/O idle hanya mendapat waktu disk saat program lain tidak memakai disk - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: w_await (rata-rata waktu pemrosesan permintaan tulis, termasuk waktu menunggu di antrean), aqu-sz (rata-rata panjang antrean, nama lamanya avgqu-sz) - [perf-trace(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-trace.1.html) · perf · -p melacak system call proses yang sedang berjalan; --duration hanya menampilkan pemanggilan yang lebih lama dari jumlah ms yang ditentukan #### dk-fsync · Lonjakan fsync · fsync storms Permintaan agar data ditulis ke disk secara “pasti” memakan 0,1 ms hingga puluhan ms per kali tergantung disknya, dan jika permintaan menumpuk, antreannya memanjang. - Mengapa → Akibatnya → Di layar: Permintaan penulisan pasti menumpuk karena penyimpanan berkala dan gelombang logout → Antrean disk memanjang → Lag setiap kali waktu penyimpanan tiba, logout dan pindah channel tertunda - Gejala: Patah-patah, Input lag / Faktor: Stall, Latensi - Siapa: Seluruh server / Kapan: Secara berkala, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Gabungkan penyimpanan (beberapa penyimpanan dengan satu fsync), sebar waktu penyimpanan. - Tugas Tim Infrastruktur: Server/OS: gunakan SSD server dengan power-loss protection, pantau panjang antrean disk dan latensi fsync. Server DB: jika penyimpanan masuk ke DB, gunakan SSD yang sama untuk disk log DB, pantau latensi commit. - Kisaran angka: Waktu per kali berbeda di setiap perangkat, tetapi kira-kira: SSD server (dengan power-loss protection) 0,1 ms, SSD biasa 1 hingga beberapa ms, disk cloud 1–2 ms, HDD minimal 10 ms. Jika satu thread menunggu satu per satu, HDD bahkan tidak sanggup 100 kali per detik. - Di grafik: Melonjak secara berkala (Panjang antrean disk, latensi flush dan tulis) - Yang diperiksa: Tumpangkan f/s dan f_await (jumlah flush yang diproses disk dan waktunya), serta w/s, aqu-sz, dan w_await di iostat -x 1 dengan waktu penyimpanan berkala dan logout. sysstat versi lama menampilkan aqu-sz sebagai avgqu-sz. Untuk disk cloud, periksa VolumeQueueLength dan VolumeAvgWriteLatency di EBS - Cocok jika: Setiap waktu penyimpanan dan gelombang logout, jumlah flush dan panjang antrean melonjak bersamaan, dan w_await serta f_await menjadi beberapa kali lipat dari biasanya. Saat itu penyimpanan dan pindah channel melambat - Tidak cocok jika: Antrean melonjak di waktu yang tidak berkaitan dengan penyimpanan atau logout: lebih mungkin backup dan kompresi (dk-backup) atau batas IOPS (dk-iops). Jumlah flush tetap tetapi melambat: lebih mungkin burst credit habis (dk-burst) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [fsync(2) — Linux manual page](https://man7.org/linux/man-pages/man2/fsync.2.html) · Linux man-pages · fsync juga mengosongkan cache disk dan memblokir sampai perangkat melaporkan selesai - [Reliability (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-reliability.html) · PostgreSQL · Disk SATA biasa dan banyak SSD punya cache tulis yang isinya hilang saat listrik padam, sehingga penyimpanan yang pasti membutuhkan cache dengan baterai atau power-loss protection - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · Latensi disk standar cloud (gp3) dalam kisaran satu digit ms, io2 Block Express rata-rata kurang dari 500 µs untuk I/O 16 KiB - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Satu kali seek HDD 10 ms - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: f/s dan f_await (jumlah permintaan flush yang diproses disk dan waktu rata-ratanya), w/s, w_await, aqu-sz (nama lamanya avgqu-sz) - [Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html) · AWS · VolumeQueueLength (jumlah permintaan yang menunggu selesai), VolumeAvgWriteLatency (rata-rata latensi tulis per 1 menit, instance Nitro) #### dk-burst · Burst credit disk cloud habis · Burst credit depletion Sebagian disk cloud dan spesifikasi server kecil punya burst credit yang memungkinkan kinerja di atas baseline untuk sementara. Jika masa sibuk berlangsung lama dan kreditnya habis, kecepatannya tiba-tiba turun. - Mengapa → Akibatnya → Di layar: Dipakai di atas performa baseline dalam waktu lama → Burst credit habis, performa anjlok ke baseline → Setiap malam, lag baru mulai setelah beberapa jam berlalu - Gejala: Patah-patah, Slow motion, Input lag / Faktor: Stall, Latensi - Siapa: Seluruh server / Kapan: Jam sibuk malam hari, Makin lama menyala - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Infrastruktur: Server/OS: gunakan disk dengan performa terjamin (gp3, tipe provisioned IOPS), pasang alert saldo kredit, periksa juga batas burst bandwidth disk instance dan CPU credit. Server DB: ganti juga disk DB, termasuk managed DB, ke tipe dengan performa terjamin, pasang alert saldo kredit. - Kisaran angka: Disk AWS gp2 100 GB biasanya 300 IOPS dan 3.000 IOPS saat burst, dan jika kreditnya penuh, burst bertahan sekitar 30 menit. gp3 selalu 3.000 IOPS tanpa kredit. Premium SSD Azure yang kecil juga bisa burst hingga 30 menit dengan kredit. - Di grafik: Mendatar di batas (IOPS, saldo burst credit) - Yang diperiksa: Periksa EBS BurstBalance (gp2, st1, sc1) di CloudWatch, EBSIOBalance% dan EBSByteBalance% milik instance (sebagian instance yang bisa burst), serta CPUCreditBalance pada instance burstable. Di Azure, periksa metrik persentase pemakaian burst credit seperti Data Disk Used Burst IO Credits Percentage - Cocok jika: Sejak saldo turun mendekati 0, IOPS (VolumeReadOps, VolumeWriteOps) mendatar di performa baseline, dan VolumeQueueLength serta lag ikut naik. Dimulai setelah jam sibuk berlangsung beberapa jam - Tidak cocok jika: Semua saldo masih banyak tetapi IOPS mendatar: lebih mungkin batas tetap volume atau instance (dk-iops) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Walaupun disknya baik-baik saja, VM kecil punya batas burst pada bandwidth disk instance itu sendiri (misalnya minimal 30 menit per hari), sehingga polanya sama. Server murah yang memakai CPU credit juga melambat sampai performa baseline jika kreditnya habis. - Sumber: - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · Performa baseline gp2 adalah 3 IOPS per GiB (minimal 100), bisa burst hingga 3.000 IOPS dengan I/O credit, dan 5,4 juta kredit cukup untuk minimal 30 menit. gp3 selalu 3.000 IOPS tanpa burst - [Managed disk bursting](https://learn.microsoft.com/en-us/azure/virtual-machines/disk-bursting) · Microsoft Azure · Premium SSD P20 ke bawah memakai burst berbasis kredit; jika kreditnya penuh, bisa berjalan 30 menit dengan kecepatan burst maksimum - [Amazon EBS-optimized instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) · AWS · Sebagian instance hanya mempertahankan performa EBS maksimum selama 30 menit sekali dalam 24 jam, lalu kembali ke performa baseline - [Standard mode for burstable performance instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-standard-mode.html) · AWS · Instance burstable dalam mode standar menurunkan utilisasi CPU ke level baseline secara bertahap (agar tidak anjlok) saat CPU credit habis - [Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html) · AWS · BurstBalance: saldo I/O credit gp2 dan saldo throughput credit st1 serta sc1 (%), VolumeReadOps, VolumeWriteOps, VolumeQueueLength - [CloudWatch metrics that are available for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · EBSIOBalance% dan EBSByteBalance%: saldo kredit EBS pada sebagian instance yang bisa burst 30 menit sekali dalam 24 jam; CPUCreditBalance: saldo CPU credit pada instance burstable - [Disk metrics](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-metrics) · Microsoft Azure · Persentase pemakaian burst credit disk dan VM, seperti Data Disk Used Burst IO Credits Percentage (interval 5 menit) #### dk-iops · Batas IOPS dan antrean jenuh · IOPS limit / queue saturation Jika permintaan melebihi jumlah yang bisa diproses disk per detik, antrean memanjang dan latensi melonjak tajam. - Mengapa → Akibatnya → Di layar: Permintaan baca dan tulis mendekati kemampuan proses disk → Antrean memanjang (biasanya melonjak tajam saat utilisasi 90% atau lebih) → Penyimpanan dan loading tertunda; jika pemanggilannya sinkron, terjadi freeze - Gejala: Input lag, Freeze / Faktor: Latensi, Stall - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Gabungkan permintaan, simpan data yang sering dibaca di cache, gunakan I/O asinkron agar thread game tidak menunggu disk. - Tugas Tim Infrastruktur: Server/OS: gunakan disk yang lebih cepat, periksa batas bandwidth disk dan IOPS per tipe instance, pasang alert utilisasi dan antrean disk, salin file besar di jam sepi. Server DB: pasang alert utilisasi IOPS dan throughput untuk disk DB juga, periksa batas disk pada spesifikasi instance DB. - Kisaran angka: HDD sekitar 150 IOPS, SSD SATA puluhan ribu, NVMe ratusan ribu IOPS. Disk standar cloud (AWS gp3) 3.000 IOPS dan 125 MiB per detik. Batas throughput per detik ini terpisah dari IOPS, dan jika salinan file besar menghabiskannya, penulisan kecil pun ikut tertahan. - Di grafik: Mendatar di batas (IOPS, panjang antrean disk) - Yang diperiksa: Periksa r/s dan w/s, rkB/s dan wkB/s, aqu-sz, serta r_await dan w_await di iostat -x 1. Di cloud, periksa VolumeReadOps, VolumeWriteOps, dan VolumeQueueLength di EBS, indikator pelampauan batas VolumeIOPSExceededCheck dan VolumeThroughputExceededCheck, serta InstanceEBSIOPSExceededCheck dan InstanceEBSThroughputExceededCheck di sisi instance - Cocok jika: Jumlah permintaan per detik atau throughput mendatar di nilai batas, dan aqu-sz serta await melonjak bersamaan. Di cloud, metrik pemeriksaan pelampauan bernilai 1 - Tidak cocok jika: %util 100% tetapi await rendah: mungkin masih ada ruang. Pada SSD dan RAID yang memproses permintaan secara paralel, %util tidak menunjukkan batas. Belum mencapai batas tetapi hanya await yang tinggi: lebih mungkin latensi disk itu sendiri (dk-hdd) atau fsync (dk-fsync) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Di cloud, selain batas disk, setiap spesifikasi server (tipe instance) juga punya batas bandwidth disk dan IOPS. Walaupun disk mahal dipasang, jika servernya kecil, kinerjanya tertahan di batas instance. - Sumber: - [Exos X18 Data Sheet](https://www.seagate.com/www-content/datasheets/pdfs/exos-x18-mango-DS2045-1N-2007US-en_US.pdf) · Seagate · Baca acak 4K pada HDD server 7.200 rpm: 170 IOPS (QD16) - [D3-S4520 SSD](https://www.solidigm.com/products/data-center/d3/s4520.html) · Solidigm · Baca/tulis acak 4 KB pada SSD SATA server: maksimal 92K/48K IOPS - [Solidigm™ D7-P5520 and D7-P5620 Product Brief](https://www.solidigm.com/products/data-center/product-briefs/d7-p5520-p5620-product-brief.html) · Solidigm · Baca/tulis acak pada SSD NVMe server: 1.000K/200K IOPS - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · Performa dasar gp3 3.000 IOPS dan 125 MiB/s; keduanya batas terpisah yang bisa dinaikkan masing-masing - [Amazon EBS-optimized instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) · AWS · Setiap tipe instance punya batas baseline dan maksimum tersendiri untuk bandwidth, throughput, dan IOPS EBS - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: r/s dan w/s, rkB/s dan wkB/s, aqu-sz (nama lamanya avgqu-sz), r_await dan w_await, %util. Pada RAID dan SSD modern yang memproses permintaan secara paralel, %util tidak menunjukkan batas performa - [Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html) · AWS · VolumeIOPSExceededCheck dan VolumeThroughputExceededCheck: bernilai 1 jika ada upaya melewati batas IOPS atau throughput volume (instance Nitro), VolumeQueueLength - [CloudWatch metrics that are available for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · InstanceEBSIOPSExceededCheck dan InstanceEBSThroughputExceededCheck: bernilai 1 jika ada upaya melewati batas IOPS atau throughput EBS instance #### dk-full · Disk penuh · Disk full Jika log dan dump menumpuk hingga disk penuh, penulisan gagal, dan tanpa penanganan, server crash. - Mengapa → Akibatnya → Di layar: Log, dump, dan file sementara menumpuk hingga 100% → Penulisan gagal. Tanpa penanganan error, server crash; dengan penanganan error, penyimpanan gagal → Disconnect, rollback progres - Gejala: Disconnect, Aksi hilang / rollback / Faktor: Stall - Siapa: Seluruh server / Kapan: Makin lama menyala - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Tangani kegagalan penulisan dengan mencoba ulang penyimpanan dan memicu alert agar server tidak crash, kurangi log dan dump yang tidak perlu. - Tugas Tim Infrastruktur: Server/OS: rotasi log, alert kapasitas, pisahkan disk log dan data. Server DB: pantau agar log transaksi DB (WAL, binlog) tidak menumpuk akibat replikasi terhenti atau backup log terlewat. - Di grafik: Naik perlahan (Penggunaan ruang disk) - Yang diperiksa: Periksa persentase penggunaan di df -h dan penggunaan inode di df -i, lalu cari error ENOSPC di log server dan DB. Untuk DB, periksa slot dengan active bernilai false di pg_replication_slots (PostgreSQL), jumlah dan ukuran file di SHOW BINARY LOGS (MySQL), log_reuse_wait_desc di sys.databases (SQL Server), dan FreeStorageSpace (RDS) - Cocok jika: Penggunaan naik terus selama beberapa hari, dan saat mencapai 100% bertepatan dengan waktu crash atau gagal simpan; ENOSPC tercatat di log - Tidak cocok jika: Ruang masih lega tetapi penulisan gagal: lebih mungkin penyebab lain seperti izin atau batas ukuran file - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Log transaksi DB (WAL, binlog, dan lainnya) tidak terhapus dan terus menumpuk jika replika berhenti atau backup log terlewat. Jika disk ini penuh, semua penulisan di DB berhenti sehingga penyimpanan dan trade gagal serentak. - Sumber: - [write(2) — Linux manual page](https://man7.org/linux/man-pages/man2/write.2.html) · Linux man-pages · Jika perangkat kehabisan ruang, penulisan gagal dengan error ENOSPC - [Monitoring Disk Usage (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/diskusage.html) · PostgreSQL · Jika disk WAL penuh, server DB bisa berhenti karena panic - [Log-Shipping Standby Servers (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/warm-standby.html) · PostgreSQL · Replication slot tidak menghapus WAL sampai replika menerimanya, sehingga bisa memenuhi ruang pg_wal (dibatasi dengan max_slot_wal_keep_size) - [Troubleshoot a full transaction log (SQL Server Error 9002)](https://learn.microsoft.com/en-us/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002) · Microsoft SQL Server · Jika log penuh, DB hanya bisa dibaca dan tidak bisa diubah; penyebab umum yang menghalangi pembersihan log adalah backup log yang terlewat, replication lag, dan transaksi panjang; penghalangnya bisa dilihat di log_reuse_wait_desc pada sys.databases - [df(1) — Linux manual page](https://man7.org/linux/man-pages/man1/df.1.html) · coreutils · Penggunaan per file system; -i menampilkan penggunaan inode sebagai pengganti blok - [pg_replication_slots (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/view-pg-replication-slots.html) · PostgreSQL · active: apakah slot sedang melakukan streaming; wal_status: apakah WAL yang ditahan slot sudah melewati max_wal_size - [SHOW BINARY LOGS Statement](https://dev.mysql.com/doc/refman/8.4/en/show-binary-logs.html) · MySQL · Daftar file binary log di server dan ukuran filenya (File_size) - [Amazon CloudWatch metrics for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html) · AWS · FreeStorageSpace: sisa ruang penyimpanan instance DB #### dk-backup · Tugas backup, kompresi, dan pemindaian · Backup / compression / scans Jika backup dini hari, kompresi log, dan pemindaian keamanan memonopoli disk, pembacaan dan penulisan server game tertunda. - Mengapa → Akibatnya → Di layar: Tugas backup dan kompresi terjadwal dimulai → Menghabiskan sebagian besar bandwidth disk dan IOPS → Lag di jam yang sama setiap hari - Gejala: Patah-patah, Input lag / Faktor: Stall, Latensi - Siapa: Seluruh server / Kapan: Secara berkala - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Infrastruktur: Server/OS: turunkan prioritas I/O untuk tugas backup, kompresi, dan pemindaian, sebar jadwalnya. Server DB: lakukan backup dari replika. - Di grafik: Melonjak secara berkala (Utilisasi disk, waktu tunggu disk) - Yang diperiksa: Tumpangkan %util, await, dan aqu-sz dari catatan beberapa hari terakhir di sar -d (file harian di /var/log/sa; sadc harus mengumpulkan data disk dengan -S DISK) per tanggal, lalu pada jam itu cari proses dengan kB_rd/s dan kB_wr/s terbesar menggunakan pidstat -d 1, dan cocokkan dengan jadwal cron dan systemd timer - Cocok jika: Setiap hari di jam yang sama await dan %util melonjak, dan saat itu proses backup, kompresi, atau pemindaian memakai sebagian besar pembacaan dan penulisan disk - Tidak cocok jika: Jam lonjakan berbeda setiap hari: kecil kemungkinan tugas terjadwal. Sebagian besar I/O pada jam itu berasal dari server game sendiri: lebih mungkin penyimpanan atau log (dk-fsync, dk-sync-log) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [ionice(1) — Linux manual page](https://man7.org/linux/man-pages/man1/ionice.1.html) · util-linux · Tugas yang dijalankan dengan kelas idle hanya mendapat waktu disk saat program lain tidak memakai disk - [Using Replication for Backups](https://dev.mysql.com/doc/refman/8.4/en/replication-solutions-backups.html) · MySQL · Backup dengan menghentikan replika tidak memengaruhi operasi DB primer - [sar(1) — Linux manual page](https://man7.org/linux/man-pages/man1/sar.1.html) · sysstat · -d: await, aqu-sz, dan %util per perangkat dari file catatan harian (default /var/log/sa); data disk harus dikumpulkan dengan opsi -S DISK di sadc - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -d: kB_rd/s dan kB_wr/s per proses (volume baca dan tulis disk per detik) #### dk-lazy-load · Lazy loading di server · Lazy loading on the server Jika server membaca data dungeon atau map dari disk saat pertama kali diminta, semua pemain berhenti selama tick itu. - Mengapa → Akibatnya → Di layar: Seseorang masuk ke dungeon atau area untuk pertama kali → Server membaca data dari disk di thread game → Semua pemain di server itu mengalami freeze sesaat - Gejala: Freeze / Faktor: Stall - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Muat data lebih dulu saat server dinyalakan, gunakan pemuatan asinkron. - Tugas Tim Infrastruktur: Untuk server yang baru dibuat dari snapshot, lakukan pemanasan disk sebelum melayani pemain (baca semua blok sekali) atau gunakan fitur fast snapshot restore. - Di grafik: Melonjak acak sesekali (Waktu tick server, pembacaan disk) - Yang diperiksa: Cocokkan waktu berhenti dengan catatan masuk pertama ke dungeon atau area di log server game, lalu periksa pembacaan disk server game saat itu (kB_rd/s di pidstat -d) dan pemanggilan read serta open yang lama dengan perf trace --duration. Untuk server cloud yang baru dinyalakan, bandingkan VolumeAvgReadLatency di EBS dengan server lama - Cocok jika: Berhenti hanya saat masuk pertama kali, dan tidak berhenti saat masuk ke tempat yang sama untuk kedua kalinya. Selama berhenti, thread game menunggu pembacaan file - Tidak cocok jika: Berhenti dengan cara yang sama juga di area yang sudah dimuat: lebih mungkin penyebab lain seperti tick yang melewati budget atau GC - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Di cloud, server yang baru dibuat dari snapshot (salinan disk) mengambil setiap blok yang pertama kali dibaca dari storage jarak jauh, sehingga jauh lebih lambat daripada biasanya. Jika masuk pertama kali terasa sangat lama hanya di server yang baru dinyalakan oleh autoscaling, curigai penyebab ini. - Sumber: - [Initialize Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html) · AWS · Volume yang dibuat dari snapshot mengalami latensi lebih tinggi dan performa lebih rendah selama bloknya diambil dari S3; inisialisasi lebih dulu dengan membaca semua blok menggunakan dd atau fio - [Amazon EBS fast snapshot restore](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-fast-snapshot-restore.html) · AWS · Fast snapshot restore memberikan volume yang sudah terinisialisasi sejak dibuat, sehingga latensi akses pertama hilang - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · -d: kB_rd/s per proses (volume baca disk per detik) - [perf-trace(1) — Linux manual page](https://man7.org/linux/man-pages/man1/perf-trace.1.html) · perf · Hanya menampilkan system call yang lebih lama dari jumlah ms yang ditentukan dengan --duration - [Amazon CloudWatch metrics for Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/using_cloudwatch_ebs.html) · AWS · VolumeAvgReadLatency: rata-rata latensi baca per 1 menit (instance Nitro) #### dk-coredump · Penulisan core dump · Core dump writing Saat server crash, memori sebesar beberapa GB ditulis ke disk, sehingga restart bisa tertunda beberapa menit. - Mengapa → Akibatnya → Di layar: Server crash, seluruh memori ditulis ke file → Restart tidak bisa dilakukan selama beberapa GB ditulis → Server crash sehingga pemain disconnect, lalu untuk waktu lama tidak bisa masuk - Gejala: Tidak bisa masuk / loading tanpa henti / Faktor: Stall - Siapa: Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pertimbangkan dump kecil yang hanya berisi memori yang diperlukan (minidump), perbaiki penyebab crash. - Tugas Tim Infrastruktur: Batasi ukuran dump (pengaturan core dump di OS), gunakan disk cepat, pisahkan restart dari dump (kompresi dan upload dump diproses terpisah setelah restart). - Di grafik: Koneksi putus serentak (Jumlah koneksi, waktu restart server) - Yang diperiksa: Jajarkan waktu crash, ukuran file core (coredumpctl list dan info, atau file di lokasi yang ditunjuk core_pattern), waktu file selesai ditulis, dan waktu service aktif kembali, lalu periksa wkB/s di iostat -x selama rentang itu - Cocok jika: Setelah crash, penulisan disk menempel di dekat batas selama file core berukuran beberapa GB ditulis, dan restart baru dimulai setelah penulisan selesai - Tidak cocok jika: Core dump nonaktif atau hasilnya kecil tetapi restart tetap lambat: lebih mungkin proses startup server, seperti loading map atau cold cache DB (db-cold-cache) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [core(5) — Linux manual page](https://man7.org/linux/man-pages/man5/core.5.html) · Linux man-pages · RLIMIT_CORE membatasi ukuran file core, coredump_filter memilih area memori yang disertakan, dan core dump bisa dikirim lewat pipe ke program untuk diproses terpisah - [Minidump Files](https://learn.microsoft.com/en-us/windows/win32/debug/minidump-files) · Microsoft · Minidump hanya memuat sebagian informasi crash dump yang berguna, sehingga cepat dibuat dan berukuran kecil - [coredumpctl(1) — Linux manual page](https://man7.org/linux/man-pages/man1/coredumpctl.1.html) · systemd · list: daftar core dump yang tercatat di journal (TIME adalah waktu crash yang dilaporkan kernel); info: detail tiap dump dan ukuran yang ditulis ke disk - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: wkB/s (volume tulis disk per detik) #### dk-hdd · Latensi seek HDD · HDD seek latency Pada HDD, head harus bergerak di atas piringan (platter) untuk mencari posisi data (seek), sehingga membaca atau menulis data yang tersebar memakan hampir 10 ms per kali. - Mengapa → Akibatnya → Di layar: Server lama atau storage murah memakai HDD → Sekitar 10 ms untuk setiap baca atau tulis yang tersebar → Penyimpanan dan loading melambat secara umum - Gejala: Input lag / Faktor: Latensi - Siapa: Seluruh server / Kapan: Selalu - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Rancang agar penulisan sebagian besar berurutan (sequential write). - Tugas Tim Infrastruktur: Server/OS: ganti ke SSD (mulai dari disk penyimpanan dengan banyak baca/tulis acak). Server DB: ganti lebih dulu disk DB dengan baca/tulis acak terbanyak ke SSD. - Di grafik: Selalu tinggi sejak awal (Latensi baca/tulis disk (r_await, w_await)) - Yang diperiksa: Periksa dengan lsblk -d -o NAME,ROTA apakah disk berputar (HDD), lalu periksa r/s dan w/s serta r_await dan w_await di iostat -x 1. Untuk VM, periksa jenis disk di spesifikasi cloud atau storage - Cocok jika: Disk berputar, dan walaupun permintaan per detik hanya puluhan hingga sekitar seratus, r_await dan w_await selalu beberapa hingga puluhan ms - Tidak cocok jika: SSD tetapi latensinya tinggi: lebih mungkin antrean jenuh (dk-iops) atau burst credit habis (dk-burst) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Satu kali seek disk 10 ms, baca berurutan 1 MB dari disk 20 ms - [Exos X18 Data Sheet](https://www.seagate.com/www-content/datasheets/pdfs/exos-x18-mango-DS2045-1N-2007US-en_US.pdf) · Seagate · Rata-rata latensi rotasi HDD 7.200 rpm 4,16 ms, baca acak 4K 170 IOPS - [lsblk(8) — Linux manual page](https://man7.org/linux/man-pages/man8/lsblk.8.html) · util-linux · -o memilih kolom output; kolom topologi perangkat mencakup ROTA (apakah perangkat berputar) - [ABI stable symbols](https://docs.kernel.org/admin-guide/abi-stable.html) · Linux kernel · /sys/block/(disk)/queue/rotational: menunjukkan apakah perangkat berputar atau tidak - [iostat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/iostat.1.html) · sysstat · -x: r/s dan w/s, r_await dan w_await (rata-rata waktu pemrosesan per permintaan, termasuk waktu menunggu di antrean) ### L12 Database (16 penyebab) #### db-no-index · Query tanpa indeks · Missing index / full table scan Tanpa indeks, DB harus membaca seluruh tabel untuk menemukan baris yang memenuhi kondisi (full table scan). - Mengapa → Akibatnya → Di layar: Deploy fitur baru menambahkan pencarian dengan kondisi yang tidak punya indeks → Jutaan baris dipindai semua, sehingga satu query butuh ratusan ms hingga beberapa detik → Loading mailbox dan riwayat trade tertunda, koneksi tertahan sehingga request lain ikut menunggu - Gejala: Input lag, Tidak bisa masuk / loading tanpa henti / Faktor: Latensi, Stall - Siapa: Fitur tertentu saja, Seluruh server / Kapan: Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Tinjau query plan setiap query baru sebelum deploy, tambahkan indeks, pastikan query yang mengubah data (UPDATE, DELETE) juga memakai indeks. - Tugas Tim Infrastruktur: Pantau slow query log, temukan query yang melakukan full table scan lalu bagikan ke Tim Pengembang Game, tambahkan indeks saat layanan berjalan dengan metode online yang lock-nya singkat. - Kisaran angka: Dengan indeks, beberapa ms. Tanpa indeks, query melambat sebanding dengan ukuran data, dan pada tabel besar bisa ratusan hingga puluhan ribu kali lebih lambat. - Di grafik: Naik seperti anak tangga (Latensi query DB, jumlah baris yang dibaca) - Yang diperiksa: MySQL: periksa Rows_examined dan Rows_sent di slow query log (jika log_queries_not_using_indexes diaktifkan, query yang tidak memakai indeks juga dicatat) serta SUM_NO_INDEX_USED dan SUM_ROWS_EXAMINED di performance_schema events_statements_summary_by_digest, lalu jalankan EXPLAIN. PostgreSQL: periksa seq_scan dan seq_tup_read di pg_stat_user_tables, lalu jalankan EXPLAIN - Cocok jika: Query yang baru muncul setelah deploy membaca baris (Rows_examined) ribuan kali lebih banyak daripada baris yang dikembalikan (Rows_sent), dan EXPLAIN menunjukkan full table scan (MySQL type ALL, PostgreSQL Seq Scan). seq_tup_read pada tabel besar naik tajam sejak waktu deploy - Tidak cocok jika: Sudah memakai indeks tetapi tetap lambat: lebih mungkin menunggu lock (db-hot-row, db-ddl-lock) atau query plan berubah (db-plan-flip). Full table scan pada tabel kecil bisa saja normal - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Dampaknya tidak terbatas pada pembacaan. Tergantung DB-nya, query pengubah data (UPDATE, DELETE) tanpa indeks ikut mengunci baris yang dipindai, sehingga penyimpanan pemain yang tidak terkait pun bisa terhalang. - Sumber: - [How MySQL Uses Indexes](https://dev.mysql.com/doc/refman/8.4/en/mysql-indexes.html) · MySQL · Tanpa indeks, DB membaca seluruh tabel mulai dari baris pertama, dan makin besar tabel, makin besar biayanya - [Locks Set by Different SQL Statements in InnoDB](https://dev.mysql.com/doc/refman/8.4/en/innodb-locks-set.html) · MySQL · Jika tidak ada indeks yang cocok dan seluruh tabel dipindai, semua baris terkunci sehingga pengguna lain bahkan tidak bisa menambah baris - [The Slow Query Log](https://dev.mysql.com/doc/refman/8.4/en/slow-query-log.html) · MySQL · Mencatat query yang melebihi long_query_time (default 10 detik); query yang tidak memakai indeks juga bisa dicatat terpisah - [CREATE INDEX (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/sql-createindex.html) · PostgreSQL · Dengan CONCURRENTLY, indeks dibuat tanpa memblokir penulisan; pembuatan biasa memblokir penulisan sampai selesai - [Statement Summary Tables](https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-summary-tables.html) · MySQL · events_statements_summary_by_digest: SUM_NO_INDEX_USED (jumlah eksekusi tanpa indeks) dan SUM_ROWS_EXAMINED per pola query yang sama - [EXPLAIN Output Format](https://dev.mysql.com/doc/refman/8.4/en/explain-output.html) · MySQL · type ALL berarti full table scan; biasanya dihindari dengan menambahkan indeks - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · seq_scan (jumlah sequential scan) dan seq_tup_read (jumlah baris yang dibaca lewat sequential scan) di pg_stat_user_tables - [Using EXPLAIN (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/using-explain.html) · PostgreSQL · Seq Scan: query plan yang membaca semua baris tabel secara berurutan #### db-hot-row · Perebutan lock pada hot row · Hot row lock contention Jika semua orang ingin mengubah baris yang sama (gudang guild, item populer di balai lelang, counter untuk seluruh server), lock hanya didapat satu per satu. - Mengapa → Akibatnya → Di layar: Perubahan menumpuk pada baris yang sama karena event atau item populer → Request menunggu sampai mendapat lock → Trade gagal, “Coba lagi nanti”, timeout - Gejala: Aksi hilang / rollback, Input lag / Faktor: Stall, Latensi - Siapa: Fitur tertentu saja / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Pecah barisnya (sharded counter), persingkat transaksi, kumpulkan perubahan di memori lalu terapkan sekaligus. - Tugas Tim Infrastruktur: Pantau waktu tunggu row lock dan jumlah kejadiannya, temukan baris yang paling diperebutkan, lalu bagikan. - Kisaran angka: Jika satu request memegang lock selama 10 ms, baris itu hanya bisa diubah maksimal 100 kali per detik. Jika di dalam transaksi ada round-trip ke server lain, angka itu makin kecil sebanding dengan lamanya. - Di grafik: Naik mengikuti beban (Jumlah dan waktu tunggu row lock) - Yang diperiksa: MySQL: periksa kenaikan Innodb_row_lock_waits dan Innodb_row_lock_time serta Innodb_row_lock_current_waits, lalu cari siapa menunggu siapa dengan sys.innodb_lock_waits. PostgreSQL: periksa sesi dengan wait_event_type Lock di pg_stat_activity dan request dengan granted bernilai false di pg_locks; jika log_lock_waits (default nonaktif) diaktifkan, lock yang ditunggu lama tercatat di log - Cocok jika: Jumlah request yang menunggu lock naik tajam mengikuti event dan jumlah pemain, dan sebagian besar request yang menunggu mengarah ke baris yang sama (key yang sama) di tabel yang sama - Tidak cocok jika: Request yang menunggu tersebar merata di banyak tabel dan baris: lebih mungkin disk atau CPU jenuh. Satu sesi memegang lock lama dan tidak melepasnya: lebih mungkin transaksi yang terbuka lama (db-long-tx) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [InnoDB Locking](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html) · MySQL · Jika satu transaksi mengunci sebuah baris (index record), transaksi lain tidak bisa mengubah baris itu dan harus menunggu - [How to Minimize and Handle Deadlocks](https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks-handling.html) · MySQL · Anjuran untuk menjaga transaksi tetap kecil dan singkat serta segera commit setelah perubahan terkait agar konflik berkurang - [Server Status Variables](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html) · MySQL · Innodb_row_lock_waits dan Innodb_row_lock_time menunjukkan jumlah dan waktu tunggu row lock; Innodb_row_lock_current_waits menunjukkan jumlah yang sedang menunggu - [The innodb_lock_waits and x$innodb_lock_waits Views](https://dev.mysql.com/doc/refman/8.4/en/sys-innodb-lock-waits.html) · MySQL · Query yang menunggu (waiting_query), sesi yang memblokir (blocking_pid), dan lama menunggu (wait_age) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · wait_event_type di pg_stat_activity: Lock berarti sedang menunggu heavyweight lock - [pg_locks (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/view-pg-locks.html) · PostgreSQL · granted bernilai false berarti proses itu sedang menunggu untuk mendapatkan lock - [Error Reporting and Logging (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-logging.html) · PostgreSQL · log_lock_waits: mencatat log jika menunggu lock lebih lama dari deadlock_timeout; default nonaktif #### db-deadlock · Deadlock DB · Database deadlock Jika dua transaksi (sekumpulan operasi DB yang diproses sebagai satu kesatuan) saling menunggu baris yang dikunci pihak lain, DB membatalkan salah satunya secara paksa. - Mengapa → Akibatnya → Di layar: Trade A mengunci dengan urutan item→mata uang game, trade B dengan urutan mata uang game→item → DB mendeteksi deadlock dan melakukan rollback pada salah satunya → Trade dan crafting sesekali gagal, item kembali seperti semula - Gejala: Aksi hilang / rollback, Input lag / Faktor: Packet loss, Stall - Siapa: Fitur tertentu saja / Kapan: Saat banyak pemain berkumpul, Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Samakan urutan penguncian, persingkat transaksi, coba ulang otomatis saat gagal. - Tugas Tim Infrastruktur: Biarkan deteksi deadlock aktif, kumpulkan catatan deadlock lalu bagikan, perpendek batas waktu tunggu lock (default 50 detik) di server MySQL yang deteksinya dimatikan. - Kisaran angka: Waktu sampai terdeteksi: MySQL (InnoDB) hampir seketika, PostgreSQL default 1 detik, SQL Server hingga sekitar 5 detik. Selama itu kedua request tertahan. Pada server MySQL yang deteksinya dimatikan karena request bersamaan sangat banyak, request menunggu sampai batas waktu tunggu lock (default 50 detik). - Di grafik: Melonjak acak sesekali (Jumlah deadlock, jumlah trade gagal) - Yang diperiksa: MySQL: periksa LATEST DETECTED DEADLOCK di SHOW ENGINE INNODB STATUS (hanya 1 yang terbaru), semua deadlock yang tercatat di error log jika innodb_print_all_deadlocks diaktifkan, dan lock_deadlocks di INFORMATION_SCHEMA.INNODB_METRICS. PostgreSQL: deadlocks di pg_stat_database. SQL Server: xml_deadlock_report di sesi system_health yang aktif secara default. Kode error di sisi server game: MySQL 1213, PostgreSQL 40P01, SQL Server 1205 - Cocok jika: Saat trade dan crafting gagal, jumlah deadlock naik, dan dua transaksi yang tercatat mengunci tabel yang sama dengan urutan saling berlawanan - Tidak cocok jika: Jumlah deadlock tidak berubah tetapi tetap gagal: lebih mungkin batas waktu tunggu lock terlampaui (error MySQL 1205) atau hot row (db-hot-row) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [InnoDB Startup Options and System Variables](https://dev.mysql.com/doc/refman/8.4/en/innodb-parameters.html) · MySQL · Jika deteksi aktif (default), InnoDB langsung mendeteksi deadlock dan melakukan rollback; innodb_lock_wait_timeout default 50 detik - [Deadlock Detection](https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlock-detection.html) · MySQL · Pada konkurensi sangat tinggi, deteksi itu sendiri bisa menjadi lambat, sehingga kadang dimatikan dan diserahkan ke batas waktu tunggu lock - [Lock Management (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-locks.html) · PostgreSQL · deadlock_timeout default 1 detik: pemeriksaan deadlock baru dilakukan setelah menunggu lock selama itu - [Deadlocks guide](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-deadlocks-guide) · Microsoft SQL Server · Interval default pemeriksaan deadlock 5 detik, dipersingkat hingga 100 ms jika deadlock sering terjadi; sesi system_health yang aktif secara default mengumpulkan xml_deadlock_report; pihak yang dikorbankan menerima error 1205 - [How to Minimize and Handle Deadlocks](https://dev.mysql.com/doc/refman/8.4/en/innodb-deadlocks-handling.html) · MySQL · Selalu ubah banyak baris dan tabel dengan urutan yang sama, coba lagi jika gagal, catat semua deadlock dengan innodb_print_all_deadlocks - [InnoDB Standard Monitor and Lock Monitor Output](https://dev.mysql.com/doc/refman/8.4/en/innodb-standard-monitor.html) · MySQL · LATEST DETECTED DEADLOCK: dua transaksi pada deadlock terbaru, lock yang dipegang dan ditunggu, serta transaksi yang dibatalkan (rollback) - [InnoDB INFORMATION_SCHEMA Metrics Table](https://dev.mysql.com/doc/refman/8.4/en/innodb-information-schema-metrics-table.html) · MySQL · Counter lock_deadlocks di INNODB_METRICS (aktif secara default) - [Server Error Message Reference](https://dev.mysql.com/doc/mysql-errors/8.4/en/server-error-reference.html) · MySQL · 1213 ER_LOCK_DEADLOCK (deadlock), 1205 ER_LOCK_WAIT_TIMEOUT (batas waktu tunggu lock terlampaui) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · deadlocks di pg_stat_database: jumlah deadlock yang terdeteksi di DB ini - [PostgreSQL Error Codes (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/errcodes-appendix.html) · PostgreSQL · 40P01 deadlock_detected #### db-pool · Connection pool habis · Connection pool exhaustion Jumlah koneksi yang dibuka ke DB terbatas, jadi jika query lambat menahan koneksi, request lainnya harus menunggu. - Mengapa → Akibatnya → Di layar: Semua koneksi terpakai karena query lambat atau lonjakan request → Request baru menunggu sampai ada koneksi yang kosong → Loading tanpa henti saat login, penyimpanan tertunda, timeout - Gejala: Tidak bisa masuk / loading tanpa henti, Input lag / Faktor: Stall, Latensi - Siapa: Seluruh server, Fitur tertentu saja / Kapan: Tepat setelah login atau maintenance, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Hilangkan query lambat, sesuaikan ukuran pool dan timeout tunggu (jangan asal memperbesar pool), pisahkan pool per fitur. - Tugas Tim Infrastruktur: Periksa batas koneksi maksimum DB serta sisa kapasitas CPU dan IOPS, pastikan jumlah server × ukuran pool masih di bawah batas koneksi maksimum sebelum menambah server atau autoscaling, tambahkan metrik waktu tunggu koneksi dan waktu tunggu lock ke monitoring. - Kisaran angka: Jumlah koneksi yang dibutuhkan diperkirakan dengan “request per detik × waktu satu request menahan koneksi”. Dengan 2.000 request per detik dan 5 ms per request, rata-rata 10 koneksi selalu sibuk. Untuk mengantisipasi lonjakan, biasanya disiapkan dua hingga tiga kali lipatnya. Jika query melambat menjadi 150 ms, request yang sama membutuhkan 300 koneksi. - Di grafik: Mendatar di batas (Jumlah koneksi DB yang terpakai, waktu tunggu koneksi) - Yang diperiksa: Hitung status koneksi per server game dari sisi DB. MySQL: periksa Host, Command (koneksi idle tampil sebagai Sleep), dan Time di SHOW PROCESSLIST, serta Threads_connected, Threads_running, dan jumlah koneksi yang ditolak Connection_errors_max_connections. PostgreSQL: kelompokkan pg_stat_activity per client_addr dan state lalu hitung. Jika library connection pool di server game mengekspor jumlah dan waktu tunggu, periksa juga - Cocok jika: Semua koneksi satu server game, sebanyak ukuran pool, sedang menjalankan query dan koneksi idle 0, dan selama itu login dan penyimpanan menunggu. Atau jumlah koneksi seluruh DB mencapai max_connections sehingga koneksi baru ditolak - Tidak cocok jika: Koneksi idle masih banyak tetapi tetap lambat: lebih mungkin latensi query itu sendiri (db-no-index, db-hot-row) atau resource DB jenuh - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jika pool diperbesar tanpa perhitungan, yang bertambah hanya beban CPU DB dan perebutan lock, sehingga semuanya ikut melambat. Selain itu, jika jumlah server × ukuran pool melebihi batas koneksi maksimum DB, server yang baru ditambahkan atau baru dimulai ulang bahkan tidak bisa membuka koneksi. Ini sering terjadi saat autoscaling atau tepat setelah maintenance. - Sumber: - [Number Of Database Connections](https://wiki.postgresql.org/wiki/Number_Of_Database_Connections) · PostgreSQL · Setelah resource DB habis terpakai, menambah koneksi justru menurunkan throughput; menyesuaikan jumlah koneksi aktif dengan resource dan menaruh sisanya di antrean memberi latensi dan throughput yang lebih baik - [Too many connections](https://dev.mysql.com/doc/refman/8.4/en/too-many-connections.html) · MySQL · Jika max_connections sudah terpakai semua, koneksi baru ditolak dengan error Too many connections - [Connections and Authentication (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-connection.html) · PostgreSQL · max_connections: batas atas jumlah koneksi bersamaan, dengan nilai default biasanya 100 - [SHOW PROCESSLIST Statement](https://dev.mysql.com/doc/refman/8.4/en/show-processlist.html) · MySQL · Host (alamat klien), Command (sesi idle tampil sebagai Sleep), Time, State - [Server Status Variables](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html) · MySQL · Threads_connected dan Threads_running, Connection_errors_max_connections (jumlah koneksi yang ditolak karena mencapai max_connections) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · pg_stat_activity: client_addr dan state (active, idle, idle in transaction, dan lainnya) untuk setiap koneksi #### db-replica-lag · Replication lag · Replication lag Penulisan dilakukan ke DB primer dan pembacaan dari replika. Jika replika tertinggal, data yang baru ditulis belum terlihat. - Mengapa → Akibatnya → Di layar: Penulisan menumpuk di DB primer sehingga replika tertinggal beberapa detik → Data yang baru disimpan belum ada saat dibaca dari replika → Item yang baru dibeli tidak terlihat, harga di market masih nilai lama, bug pemberian ganda - Gejala: Aksi hilang / rollback / Faktor: Latensi - Siapa: Fitur tertentu saja / Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari - Penanggung jawab utama: Infrastruktur DB (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Baca data yang baru ditulis dari DB primer, periksa status pemberian dan berikan item dalam satu transaksi di DB primer (cegah duplikasi dengan unique key atau UPDATE bersyarat). - Tugas Tim Infrastruktur: Pasang alert replication lag, beri replika spesifikasi minimal setara DB primer dan terapkan replikasi paralel, jalankan penghapusan massal dalam potongan kecil, kelola query agregasi yang berjalan lama di replika. - Di grafik: Naik mengikuti beban (Replication lag (detik)) - Yang diperiksa: MySQL: periksa Seconds_Behind_Source di SHOW REPLICA STATUS pada replika (versi sebelum 8.0.22: SHOW SLAVE STATUS). PostgreSQL: periksa write_lag, flush_lag, dan replay_lag di pg_stat_replication pada server primer. RDS: periksa ReplicaLag - Cocok jika: Pada waktu laporan “tidak terlihat”, replication lag mencapai beberapa detik atau lebih, dan setelah lag itu hilang, data terlihat normal. Lag membesar saat lonjakan penulisan, penghapusan massal, atau query agregasi panjang di replika - Tidak cocok jika: Replication lag mendekati 0 tetapi data tetap tidak terlihat: lebih mungkin cache atau sinkronisasi di server game - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Replika bisa tertinggal walaupun penulisan tidak banyak. Satu penghapusan massal yang memakan 10 menit di DB primer dijalankan ulang di replika, sehingga replika tertinggal selama itu. Query agregasi yang berjalan lama di replika juga memperlambat replika mengejar ketertinggalan. - Sumber: - [SHOW REPLICA STATUS Statement](https://dev.mysql.com/doc/refman/8.4/en/show-replica-status.html) · MySQL · Seconds_Behind_Source: selisih antara waktu event yang sedang diterapkan replika dan waktu event itu dicatat di DB primer (replication lag) - [Replica Server Options and Variables](https://dev.mysql.com/doc/refman/8.4/en/replication-options-replica.html) · MySQL · Dengan replica_parallel_workers, beberapa thread menerapkan transaksi secara paralel (default 4; jika 0, satu thread menerapkannya berurutan) - [Log-Shipping Standby Servers (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/warm-standby.html) · PostgreSQL · Streaming replication secara default asinkron, sehingga ada jeda antara commit dan penerapannya di replika (biasanya kurang dari 1 detik jika replika mampu mengikuti) - [MySQL 8.0 Reference Manual: SHOW REPLICA STATUS Statement](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) · MySQL · Mulai 8.0.22, SHOW REPLICA STATUS menggantikan SHOW SLAVE STATUS; versi sebelumnya memakai SHOW SLAVE STATUS - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · write_lag, flush_lag, dan replay_lag di pg_stat_replication: waktu sejak server primer menulis WAL sampai replika melaporkan bahwa WAL telah ditulis, disimpan ke disk (flush), dan diterapkan - [Amazon CloudWatch metrics for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html) · AWS · ReplicaLag: seberapa lama (detik) read replica tertinggal dari instance sumber #### db-checkpoint · Checkpoint dan log flush · Checkpoint / log flush stalls Query melambat saat DB secara berkala menulis sekaligus perubahan yang tersimpan di memori ke disk. - Mengapa → Akibatnya → Di layar: Perubahan menumpuk lalu ditulis ke disk secara berkala → Saat itu disk sibuk sehingga query melambat → Penyimpanan dan loading melambat secara berkala - Gejala: Input lag, Patah-patah / Faktor: Latensi - Siapa: Seluruh server, Fitur tertentu saja / Kapan: Secara berkala - Penanggung jawab utama: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Infrastruktur: Pecah checkpoint menjadi bagian kecil agar penulisannya merata, beri ukuran log transaksi (redo log, WAL) yang lega, gunakan disk yang cepat. - Di grafik: Melonjak secara berkala (Latensi query DB, volume tulis disk) - Yang diperiksa: PostgreSQL: periksa waktu checkpoint dan jumlah buffer yang ditulis di log log_checkpoints (aktif secara default di versi terbaru), jumlah checkpoint (versi 17 ke atas: num_timed dan num_requested di pg_stat_checkpointer; versi 16 ke bawah: checkpoints_timed dan checkpoints_req di pg_stat_bgwriter), serta peringatan checkpoint_warning. MySQL: periksa selisih Log sequence number dan Last checkpoint at di bagian LOG pada SHOW ENGINE INNODB STATUS. Tumpangkan juga volume tulis dan latensi tulis disk di server - Cocok jika: Waktu lonjakan latensi query bertepatan dengan waktu checkpoint, dan saat itu volume tulis serta latensi tulis disk melonjak. Di PostgreSQL, jika checkpoint atas permintaan (num_requested) jauh lebih banyak daripada checkpoint terjadwal (num_timed), artinya WAL sering mencapai max_wal_size sehingga checkpoint terjadi lebih awal - Tidak cocok jika: Melonjak dengan periode yang tidak terkait waktu checkpoint: lebih mungkin backup atau batch job (dk-backup, db-batch) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jika log transaksi yang menyimpan catatan perubahan (redo log di MySQL, WAL di PostgreSQL) diatur terlalu kecil, DB terpaksa menjalankan checkpoint sekaligus secara terburu-buru setiap kali log penuh, sehingga throughput penulisan berulang kali anjlok tajam untuk sesaat. - Sumber: - [WAL Configuration (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-configuration.html) · PostgreSQL · Secara default checkpoint terjadi setiap 5 menit atau setiap 1 GB WAL (max_wal_size) dan mahal karena menulis semua dirty page. checkpoint_completion_target menyebar penulisan untuk menghindari lonjakan I/O. Jika interval checkpoint lebih pendek dari checkpoint_warning, log mencatat peringatan agar max_wal_size dinaikkan - [Configuring Buffer Pool Flushing](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-flushing.html) · MySQL · Saat redo log penuh, sharp checkpoint (checkpoint mendadak) membuat throughput turun sesaat; adaptive flushing menyebar penulisan secara merata - [Error Reporting and Logging (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-logging.html) · PostgreSQL · log_checkpoints: mencatat jumlah buffer yang ditulis dan lama setiap checkpoint di log; default aktif - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · num_timed (checkpoint yang dijalankan karena waktunya tiba) dan num_requested (checkpoint yang diminta) di pg_stat_checkpointer - [PostgreSQL 17 Release Notes](https://www.postgresql.org/docs/release/17.0/) · PostgreSQL · pg_stat_checkpointer ditambahkan, kolom terkait checkpoint dipindahkan dari pg_stat_bgwriter - [The Cumulative Statistics System (PostgreSQL 16 Documentation)](https://www.postgresql.org/docs/16/monitoring-stats.html) · PostgreSQL · Sampai versi 16: checkpoints_timed dan checkpoints_req di pg_stat_bgwriter - [InnoDB Standard Monitor and Lock Monitor Output](https://dev.mysql.com/doc/refman/8.4/en/innodb-standard-monitor.html) · MySQL · Bagian LOG: log sequence number saat ini dan posisi checkpoint terakhir #### db-cold-cache · Cold cache (tepat setelah restart) · Cold buffer pool after restart Setelah DB dimulai ulang, cache di memori kosong, sehingga untuk sementara semua pembacaan data diambil dari disk. - Mengapa → Akibatnya → Di layar: DB dimulai ulang karena maintenance → Data yang sering dipakai tidak ada di memori sehingga dibaca dari disk → Login dan loading lambat untuk sementara tepat setelah maintenance - Gejala: Tidak bisa masuk / loading tanpa henti, Input lag / Faktor: Latensi - Siapa: Seluruh server / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Infrastruktur DB (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Buka server secara bertahap (gunakan antrean login untuk menambah jumlah pemain yang login sedikit demi sedikit). - Tugas Tim Infrastruktur: Lakukan warm-up cache setelah restart (periksa pengaturan simpan dan pulihkan buffer pool), untuk DB yang dipulihkan dari snapshot baca juga disknya lebih dulu. - Di grafik: Melonjak tepat setelah server dibuka (Pembacaan disk, hit rate buffer cache) - Yang diperiksa: MySQL: periksa rasio Innodb_buffer_pool_reads (jumlah pembacaan dari disk karena data tidak ada di buffer pool) terhadap Innodb_buffer_pool_read_requests, serta progres warm-up di Innodb_buffer_pool_load_status. PostgreSQL: periksa blks_read dan blks_hit di pg_stat_database. Periksa juga jumlah pembacaan disk di server DB - Cocok jika: Tepat setelah restart, pembacaan disk melonjak dan hit rate rendah, lalu pulih seiring waktu, dan selama rentang itu login dan loading lambat - Tidak cocok jika: Hit rate sama seperti biasa tetapi lambat tepat setelah maintenance: lebih mungkin lonjakan login dan N+1 (db-login-storm) atau connection pool (db-pool) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: MySQL menyimpan daftar page di buffer pool saat dimatikan, lalu membacanya kembali di latar belakang saat dinyalakan, tetapi butuh waktu sampai buffer pool terisi penuh. Jika DB di cloud dipulihkan dari snapshot (salinan disk), disk itu sendiri juga lambat pada setiap blok yang pertama kali dibaca, sehingga masa lambat ini berlangsung lebih lama. - Kasus nyata: roblox-2021 - Sumber: - [Saving and Restoring the Buffer Pool State](https://dev.mysql.com/doc/refman/8.4/en/innodb-preload-buffer-pool.html) · MySQL · Untuk mempersingkat waktu warm-up setelah restart, daftar page yang baru dipakai (default 25%) disimpan saat dimatikan dan dibaca kembali saat dinyalakan; keduanya aktif secara default - [pg_prewarm — preload relation data into buffer caches](https://www.postgresql.org/docs/current/pgprewarm.html) · PostgreSQL · Isi shared buffer dicatat secara berkala lalu dimuat kembali setelah restart (autoprewarm) - [Initialize Amazon EBS volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-initialize.html) · AWS · Volume yang dibuat dari snapshot mengalami latensi lebih tinggi dan performa lebih rendah sampai semua bloknya selesai diambil - [Server Status Variables](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html) · MySQL · Innodb_buffer_pool_reads (jumlah logical read yang harus dibaca langsung dari disk karena tidak ada di buffer pool), Innodb_buffer_pool_read_requests, Innodb_buffer_pool_load_status (progres warm-up) - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · blks_read (jumlah blok yang dibaca dari disk) dan blks_hit (jumlah blok yang ditemukan di buffer cache) di pg_stat_database #### db-login-storm · Lonjakan login dan N+1 query · Login storm, N+1 queries Jika memuat satu karakter butuh puluhan query terpisah, login bersamaan puluhan ribu pemain berubah menjadi jutaan query. - Mengapa → Akibatnya → Di layar: Saat memuat karakter, item, skill, dan quest diambil dengan query terpisah satu per satu → Tepat setelah maintenance, login bersamaan membuat jumlah query melonjak → Loading tanpa henti saat login, penyimpanan pemain yang sedang bermain pun ikut tertunda - Gejala: Tidak bisa masuk / loading tanpa henti, Input lag / Faktor: Stall, Latensi - Siapa: Seluruh server / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Gabungkan query agar data diambil sekaligus, gunakan antrean login dan cache, periksa jumlah query yang dihasilkan lazy loading ORM. - Tugas Tim Infrastruktur: Buat peringkat query dengan jumlah pemanggilan terbanyak lalu bagikan, pantau jumlah query dan koneksi pada jam login tepat setelah maintenance. - Di grafik: Melonjak tepat setelah server dibuka (Jumlah query DB per detik, jumlah login) - Yang diperiksa: Tumpangkan jumlah login tepat setelah maintenance dengan jumlah query DB per detik (MySQL: kenaikan Questions), lalu hitung jumlah query per satu login. Ambil query dengan jumlah pemanggilan teratas dari COUNT_STAR di events_statements_summary_by_digest (MySQL) atau calls di pg_stat_statements (PostgreSQL) - Cocok jika: Satu login menghasilkan puluhan query, dan query teratas adalah query pendek berpola sama yang mencari berdasarkan satu ID karakter. Jika jumlah query per login naik setelah patch, patch itulah titik awalnya - Tidak cocok jika: Jumlah query per login sedikit tetapi setiap query lambat: lebih mungkin cold cache (db-cold-cache) atau indeks (db-no-index) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Lazy loading pada ORM (library yang membuatkan query DB secara otomatis) menghasilkan query seperti ini tanpa disadari pengembang. Di server development hanya ada beberapa karakter sehingga tidak terasa, dan masalahnya baru muncul saat login bersamaan di server live. - Sumber: - [Efficient Querying](https://learn.microsoft.com/en-us/ef/core/performance/efficient-querying) · .NET · Lazy loading pada ORM menimbulkan masalah N+1, yaitu satu query tambahan untuk setiap item, sehingga performa turun drastis; dianjurkan memuat data sekaligus (eager loading) - [pg_stat_statements — track statistics of SQL planning and execution](https://www.postgresql.org/docs/current/pgstatstatements.html) · PostgreSQL · Mengumpulkan jumlah eksekusi (calls) dan total waktu eksekusi per statement untuk membuat peringkat query yang paling sering dipanggil - [Performance Schema Statement Digests and Sampling](https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-digests.html) · MySQL · events_statements_summary_by_digest mengelompokkan query berpola sama lalu menghitung jumlah dan waktunya - [Statement Summary Tables](https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-summary-tables.html) · MySQL · COUNT_STAR (jumlah eksekusi) dan SUM_TIMER_WAIT (total waktu) di tabel ringkasan - [Server Status Variables](https://dev.mysql.com/doc/refman/8.4/en/server-status-variables.html) · MySQL · Questions: jumlah statement yang dikirim klien #### db-batch · Batch job berskala besar · Batch jobs during service Agregasi ranking, pengiriman mail massal, dan pembersihan data lama yang dijalankan saat layanan berjalan menahan lock dan menyita kapasitas disk. - Mengapa → Akibatnya → Di layar: Pekerjaan berskala besar dijalankan pada jam layanan → Lock dengan cakupan luas, disk dan CPU tersita → Trade dan penyimpanan gagal pada jam tertentu, loading tertunda - Gejala: Input lag, Aksi hilang / rollback / Faktor: Latensi, Stall - Siapa: Fitur tertentu saja, Seluruh server / Kapan: Secara berkala - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Pecah pekerjaan menjadi potongan kecil dan jalankan sedikit demi sedikit, jalankan agregasi di replika. - Tugas Tim Infrastruktur: Sediakan replika khusus agregasi, jadwalkan batch job di jam sepi, pantau lock escalation dan waktu tunggu gap lock. - Di grafik: Melonjak secara berkala (Latensi query DB, waktu tunggu lock) - Yang diperiksa: Cari query panjang yang berjalan pada waktu lag. Periksa slow query log (MySQL) atau query_start dan query di pg_stat_activity (PostgreSQL), lalu cocokkan dengan metrik waktu tunggu lock pada waktu yang sama dan jadwal batch (cron, event scheduler DB). Di SQL Server, catat lock escalation dengan extended event lock_escalation - Cocok jika: UPDATE, DELETE, atau query agregasi berskala besar berjalan pada jam yang sama setiap kali, dan selama itu waktu tunggu lock serta utilisasi disk naik bersamaan - Tidak cocok jika: Tidak ada query panjang pada waktu itu: lebih mungkin checkpoint (db-checkpoint) atau backup server (dk-backup) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jika satu statement memegang lebih dari sekitar 5.000 row lock, SQL Server mengubahnya menjadi table lock (lock escalation). Saat itu semua request yang memakai tabel yang sama tertahan. Dengan pengaturan default, MySQL juga mengunci celah di antara baris (gap lock) saat data diubah dengan kondisi rentang, sehingga baris baru tidak bisa ditambahkan. - Sumber: - [Transaction Locking and Row Versioning Guide](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide) · Microsoft SQL Server · Jika satu statement memegang 5.000 lock atau lebih pada satu tabel (atau indeks), terjadi lock escalation; dicatat dengan extended event lock_escalation - [InnoDB Locking](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html) · MySQL · Pada isolation level default InnoDB, yaitu REPEATABLE READ, pencarian dan scan memakai next-key lock, sehingga gap lock mencegah penambahan baris baru di celah tersebut - [The Slow Query Log](https://dev.mysql.com/doc/refman/8.4/en/slow-query-log.html) · MySQL · Mencatat query yang melebihi long_query_time beserta waktu eksekusi (Query_time), waktu lock (Lock_time), dan jumlah baris yang dibaca - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · pg_stat_activity: query yang sedang berjalan (query) dan waktu mulainya (query_start) untuk setiap sesi #### db-failover · Failover DB · Database failover Selama DB primer mati dan layanan dialihkan ke DB cadangan, penulisan tidak bisa dilakukan, dan data terakhir yang belum sempat direplikasi bisa hilang. - Mengapa → Akibatnya → Di layar: DB primer mengalami gangguan sehingga DB cadangan dipromosikan → Selama peralihan, penulisan tidak bisa dilakukan selama beberapa detik hingga beberapa menit; dengan replikasi asinkron, data yang belum direplikasi bisa hilang → Semua penyimpanan gagal sesaat, item dan EXP kembali ke kondisi sebelumnya (rollback) - Gejala: Aksi hilang / rollback, Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti / Faktor: Stall, Packet loss - Siapa: Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur DB (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Buat penyimpanan yang bisa dicoba ulang, atur agar koneksi yang terputus cepat dibuang lalu dibuka ulang ke alamat baru (connection pool, cache DNS), pastikan koneksi ulang berjalan saat latihan failover. - Tugas Tim Infrastruktur: Gunakan replikasi sinkron atau semi-sinkron (dengan konsekuensi latensi tulis bertambah), lakukan latihan failover, pantau waktu failover dan replication lag. - Kisaran angka: Failover otomatis pada DB terkelola biasanya memakan puluhan detik hingga 2 menit. Dengan replikasi asinkron, penyimpanan terbaru bisa hilang sebanyak replication lag (kurang dari 1 detik hingga beberapa detik). - Di grafik: Koneksi putus serentak (Jumlah koneksi DB, jumlah error penulisan) - Yang diperiksa: Letakkan catatan failover di sisi DB (RDS: event RDS-EVENT-0013 failover dimulai dan RDS-EVENT-0049 failover selesai; DB yang dikelola sendiri: log promosi) bersama jumlah koneksi DB dan jumlah error koneksi server game dalam satu grafik. Jika memakai replikasi asinkron, periksa juga replication lag sesaat sebelum gangguan (RDS ReplicaLag, replay_lag di pg_stat_replication PostgreSQL) - Cocok jika: Kegagalan penyimpanan terkumpul di satu rentang waktu yang bertepatan dengan periode antara mulai dan selesainya failover. Banyaknya data yang kembali ke kondisi lama kira-kira sama dengan replication lag sesaat sebelum gangguan. Server game yang masih error setelah failover selesai berarti terus memakai koneksi yang dibuka ke alamat lama - Tidak cocok jika: Koneksi terputus pada waktu tanpa catatan failover: lebih mungkin masalah jaringan atau DB kelebihan beban - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Kasus nyata: riot-euw-2021 - Sumber: - [Failing over a Multi-AZ DB instance for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.html) · AWS · Failover Multi-AZ biasanya 60–120 detik; setelah failover koneksi harus dibuka ulang, dan TTL cache DNS JVM dianjurkan maksimal 60 detik - [High availability for Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html) · AWS · Selama gangguan, pembacaan dan penulisan gagal; biasanya pulih dalam 60 detik (sering dalam 30 detik) - [Semisynchronous Replication](https://dev.mysql.com/doc/refman/8.4/en/replication-semisync.html) · MySQL · Dengan replikasi asinkron, transaksi yang sudah di-commit bisa tidak ada di replika jika DB primer mati; replikasi semi-sinkron menguranginya dengan menunggu konfirmasi terima dari satu replika, dengan konsekuensi latensi bertambah - [Log-Shipping Standby Servers (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/warm-standby.html) · PostgreSQL · Log shipping berjalan asinkron, sehingga transaksi yang belum terkirim hilang jika server primer mati; lag streaming replication biasanya kurang dari 1 detik - [Amazon RDS event categories and event messages](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html) · AWS · RDS-EVENT-0013: failover Multi-AZ dimulai, RDS-EVENT-0049: failover Multi-AZ selesai - [Amazon CloudWatch metrics for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html) · AWS · ReplicaLag: seberapa lama (detik) read replica tertinggal dari instance sumber - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · replay_lag di pg_stat_replication: waktu sejak server primer menulis WAL sampai replika melaporkan bahwa WAL telah diterapkan #### db-save-interval · Progres hilang karena interval penyimpanan yang panjang · Periodic save window Jika data hanya disimpan beberapa menit sekali untuk mengurangi beban, progres akan hilang saat server mati di antara dua penyimpanan. - Mengapa → Akibatnya → Di layar: State karakter disimpan sekali setiap beberapa menit → Di sela waktu itu server crash atau mengalami gangguan → Setelah login ulang, karakter kembali ke kondisi beberapa menit sebelumnya (rollback) - Gejala: Aksi hilang / rollback / Faktor: Packet loss - Siapa: Seluruh server, Lokasi/channel tertentu / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Simpan event penting (trade, perolehan item langka) saat itu juga, catat log perubahan. - Tugas Tim Infrastruktur: Pastikan DB punya sisa kapasitas IOPS dan CPU untuk menanggung penulisan yang bertambah saat interval penyimpanan diperpendek. - Di grafik: Koneksi putus serentak (Jumlah koneksi, jumlah laporan rollback) - Yang diperiksa: Bandingkan waktu crash atau gangguan dengan waktu penyimpanan terakhir karakter yang melaporkan rollback (log penyimpanan di server game atau kolom waktu perubahan di DB) - Cocok jika: Titik kembalinya karakter sama dengan waktu penyimpanan terakhir sesaat sebelum crash, dan waktu yang hilang lebih pendek dari interval penyimpanan - Tidak cocok jika: Log server game mencatat penyimpanan sudah selesai tetapi data tetap kembali ke kondisi lama: lebih mungkin data hilang saat failover DB (db-failover) atau nilai lama dibaca dari replika (db-replica-lag) - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Asynchronous Commit (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-async-commit.html) · PostgreSQL · Mengumpulkan catatan lalu menuliskannya ke disk belakangan menaikkan throughput, dengan konsekuensi transaksi terbaru bisa hilang saat terjadi gangguan (trade-off yang sama) - [Redis persistence](https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/) · Redis · Jika snapshot RDB dibuat setiap beberapa menit, kehilangan data beberapa menit terakhir saat terminasi abnormal adalah risiko yang harus diterima #### db-cache-stampede · Cache stampede · Cache stampede / thundering herd Jika cache data populer kedaluwarsa bersamaan, ribuan request menyerbu DB sekaligus. - Mengapa → Akibatnya → Di layar: Data populer yang disimpan di Redis dan sejenisnya kedaluwarsa bersamaan → Request yang ingin membuat ulang data yang sama menyerbu DB sekaligus → DB kelebihan beban sehingga banyak fitur satu per satu melambat atau berhenti merespons - Gejala: Input lag, Freeze, Tidak bisa masuk / loading tanpa henti / Faktor: Stall, Latensi - Siapa: Seluruh server / Kapan: Secara berkala, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Sebar waktu kedaluwarsa secara acak, biarkan hanya satu request yang memperbarui cache sementara sisanya memakai nilai lama. - Tugas Tim Infrastruktur: Siapkan replika dan failover otomatis agar cache tidak kosong total saat Redis dimulai ulang atau mengalami gangguan, pastikan DB punya sisa kapasitas untuk bertahan walaupun cache kosong. - Di grafik: Melonjak secara berkala (Hit rate cache, jumlah query DB per detik) - Yang diperiksa: Tumpangkan keyspace_hits dan keyspace_misses (hit rate), expired_keys, dan tanda restart (uptime_in_seconds) dari INFO Redis dengan jumlah query DB per detik, lalu hitung berapa banyak query yang sama berjalan bersamaan di DB pada saat itu (MySQL SHOW PROCESSLIST, PostgreSQL pg_stat_activity) - Cocok jika: Saat cache miss tiba-tiba melonjak, jumlah query DB ikut melonjak, dan sebagian besar query yang berjalan bersamaan adalah query yang sama yang membaca data yang sama. Waktunya bertepatan dengan periode kedaluwarsa key populer atau waktu restart Redis - Tidak cocok jika: Cache miss sama seperti biasa tetapi hanya query DB yang bertambah: lebih mungkin lonjakan login (db-login-storm) atau batch job (db-batch) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Hal yang sama terjadi jika cache kosong total karena Redis dimulai ulang atau mengalami gangguan. Risikonya makin besar pada arsitektur yang mengandalkan cache sehingga DB-nya disiapkan dengan kapasitas kecil. - Sumber: - [Scaling Memcache at Facebook (NSDI '13)](https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/nishtala) · USENIX · Thundering herd: saat key yang sering dipakai diinvalidasi, banyak pembacaan menyerbu DB; dicegah dengan lease (hanya satu klien yang memperbarui) dan mengembalikan nilai lama; warm-up untuk cluster yang cache-nya kosong dilakukan terpisah - [Optimal Probabilistic Cache Stampede Prevention](https://www.vldb.org/pvldb/vol8/p886-vattani.pdf) · VLDB Endowment · Cache stampede: saat item populer kedaluwarsa, banyak request membuatnya ulang bersamaan; dicegah dengan memperbarui lebih awal secara probabilistik sebelum kedaluwarsa - [High availability with Redis Sentinel](https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/) · Redis · Failover otomatis yang mempromosikan replika saat server primer mati - [INFO](https://redis.io/docs/latest/commands/info/) · Redis · keyspace_hits dan keyspace_misses (jumlah lookup key yang berhasil dan gagal), expired_keys (jumlah key yang kedaluwarsa), uptime_in_seconds (waktu sejak dijalankan) - [SHOW PROCESSLIST Statement](https://dev.mysql.com/doc/refman/8.4/en/show-processlist.html) · MySQL · Statement yang sedang dijalankan (Info) dan lama berada di status saat ini (Time, dalam detik) untuk setiap sesi - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · pg_stat_activity: query yang sedang berjalan (query) untuk setiap sesi #### db-long-tx · Transaksi yang terbuka lama · Long-running transaction / MVCC purge lag Transaksi yang terbuka lama terus memegang lock, dan DB tidak bisa membersihkan data versi lama (purge), sehingga seluruh DB makin lama makin lambat. - Mengapa → Akibatnya → Di layar: Menunggu respons server lain sambil membiarkan transaksi terbuka, atau menjalankan query agregasi panjang di DB primer saat layanan berjalan → Lock yang dipegang tidak dilepas, dan data versi lama yang harus dibersihkan terus menumpuk → Fitur yang memakai baris itu timeout, penyimpanan dan pembacaan data melambat secara umum selama beberapa jam - Gejala: Input lag, Aksi hilang / rollback / Faktor: Latensi, Stall - Siapa: Fitur tertentu saja, Seluruh server / Kapan: Makin lama menyala, Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Jangan menunggu pemanggilan jaringan atau input pengguna di dalam transaksi, jalankan query agregasi di replika. - Tugas Tim Infrastruktur: Pasang alert untuk transaksi yang terbuka lama dan hentikan paksa, sediakan replika khusus agregasi, pantau pertambahan undo log dan baris mati. - Di grafik: Naik perlahan (Panjang undo log (History list length), jumlah baris mati) - Yang diperiksa: MySQL: cari transaksi tertua dengan trx_started di INFORMATION_SCHEMA.INNODB_TRX, lalu periksa History list length (jumlah undo log yang belum dibersihkan) di bagian TRANSACTIONS pada SHOW ENGINE INNODB STATUS. PostgreSQL: periksa xact_start dan sesi dengan state idle in transaction di pg_stat_activity, serta n_dead_tup di pg_stat_user_tables - Cocok jika: Ada transaksi yang sudah berumur beberapa menit hingga beberapa jam, dan selama itu History list length atau n_dead_tup terus naik, lalu turun setelah transaksi itu diakhiri dan pembersihan (purge, VACUUM) berjalan - Tidak cocok jika: Tidak ada transaksi lama tetapi DB lambat secara umum: lebih mungkin checkpoint (db-checkpoint) atau disk - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: DB menyimpan versi lama data agar pihak yang membaca bisa melihat kondisi sebelum diubah (MVCC). Catatan ini baru bisa dihapus setelah transaksi tertua selesai, sehingga jika satu transaksi terbuka selama beberapa jam, undo log menumpuk di MySQL, dan di PostgreSQL menumpuk baris mati (dead tuple) yang tidak bisa dibersihkan VACUUM. Di SQL Server, log transaksi tidak bisa menyusut dan kadang sampai memenuhi disk. - Sumber: - [InnoDB Multi-Versioning](https://dev.mysql.com/doc/refman/8.4/en/innodb-multi-versioning.html) · MySQL · Selama masih ada transaksi yang bisa melihat versi lama, update undo log tidak bisa dibuang sehingga rollback segment membesar; transaksi yang hanya membaca pun dianjurkan sering di-commit - [Routine Vacuuming (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/routine-vacuuming.html) · PostgreSQL · Versi baris lama tidak bisa dihapus selama transaksi lain masih bisa melihatnya; transaksi yang terbuka lama harus diakhiri atau sesinya dihentikan - [Client Connection Defaults (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-client.html) · PostgreSQL · idle_in_transaction_session_timeout: memutus sesi yang idle dengan transaksi masih terbuka agar lock tidak dipegang terlalu lama - [Troubleshoot a full transaction log (SQL Server Error 9002)](https://learn.microsoft.com/en-us/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002) · Microsoft SQL Server · Transaksi aktif yang berjalan lama menghalangi pembersihan log transaksi - [The INFORMATION_SCHEMA INNODB_TRX Table](https://dev.mysql.com/doc/refman/8.4/en/information-schema-innodb-trx-table.html) · MySQL · TRX_STARTED: waktu mulai transaksi - [Purge Configuration](https://dev.mysql.com/doc/refman/8.4/en/innodb-purge-configuration.html) · MySQL · Purge membersihkan daftar undo log transaksi yang sudah di-commit (history list); jumlah yang tertunda ditampilkan sebagai History list length di bagian TRANSACTIONS pada SHOW ENGINE INNODB STATUS - [The Cumulative Statistics System (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/monitoring-stats.html) · PostgreSQL · xact_start (waktu mulai transaksi) dan state (idle in transaction) di pg_stat_activity, n_dead_tup (perkiraan jumlah baris mati) di pg_stat_user_tables #### db-redis-block · Perintah lambat di Redis · Redis blocking commands (single-threaded) Redis memproses perintah satu per satu, sehingga satu perintah lambat menahan semua request di belakangnya. - Mengapa → Akibatnya → Di layar: Saat layanan berjalan, seluruh key dicari dengan KEYS, atau ranking dan list berisi jutaan elemen dibaca atau dihapus sekaligus → Semua request lain menunggu sampai perintah itu selesai (puluhan ms hingga beberapa detik) → Fitur yang memakai sesi, ranking, dan cache tersendat sesaat secara bersamaan, login tertunda - Gejala: Freeze, Input lag, Tidak bisa masuk / loading tanpa henti / Faktor: Stall, Latensi - Siapa: Seluruh server, Fitur tertentu saja / Kapan: Sesekali secara acak, Secara berkala - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Gunakan SCAN sebagai pengganti KEYS, pecah key besar, hapus dengan UNLINK (penghapusan di latar belakang), sebar waktu kedaluwarsa yang menumpuk di detik yang sama. - Tugas Tim Infrastruktur: Pantau log perintah lambat (SLOWLOG), blokir perintah berbahaya seperti KEYS di server produksi, periksa key besar secara rutin, matikan THP dan sisakan memori yang cukup untuk fork, jalankan penyimpanan RDB dan AOF di replika. - Kisaran angka: Perintah biasa butuh kurang dari 1 ms. Jika jutaan elemen ditangani sekaligus, waktunya bisa mencapai ratusan ms hingga beberapa detik. - Di grafik: Melonjak acak sesekali (Latensi respons Redis, jumlah perintah lambat) - Yang diperiksa: Periksa perintah yang melebihi slowlog-log-slower-than dengan SLOWLOG GET, aktifkan latency monitor (default nonaktif) dengan CONFIG SET latency-monitor-threshold, lalu periksa latensi per event seperti fork dan expire-cycle dengan LATENCY LATEST dan LATENCY DOCTOR. Periksa juga waktu fork dan key besar dengan latest_fork_usec di INFO dan redis-cli --bigkeys - Cocok jika: Pada waktu Redis berhenti, SLOWLOG mencatat KEYS atau perintah yang menangani key besar sekaligus, atau LATENCY mencatat event fork atau expire-cycle pada waktu yang sama dengan durasi puluhan ms atau lebih - Tidak cocok jika: SLOWLOG dan LATENCY kosong tetapi lambat hanya di sisi server game: lebih mungkin jaringan atau waktu tunggu di dalam server game (SLOWLOG hanya mengukur waktu eksekusi perintah, tanpa waktu kirim-terima dengan klien) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Redis juga berhenti sesaat ketika menduplikasi prosesnya (fork) untuk membuat file simpanan (snapshot RDB) atau menulis ulang AOF. Di server modern, jedanya sekitar 10 ms per 1 GB memori, jadi sekitar 300 ms untuk 30 GB. Jika halaman besar (THP) diaktifkan, setiap penulisan setelah fork menyalin satu halaman besar secara utuh (copy-on-write), sehingga jeda dan pemakaian memori melonjak. Karena itu THP biasanya dimatikan dan memori disisakan dengan lega. Redis juga berhenti sesaat untuk menghapus key jika sangat banyak key kedaluwarsa pada detik yang sama. - Sumber: - [Diagnosing latency issues](https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/latency/) · Redis · Satu thread memproses request secara berurutan sehingga perintah lambat menahan semua yang di belakangnya; gunakan SCAN sebagai pengganti KEYS; hasil pengukuran fork di server fisik dan VM modern sekitar 9–13 ms per 1 GB; THP membuat latensi dan memori melonjak karena penyalinan setelah fork; Redis berhenti jika banyak key kedaluwarsa pada detik yang sama - [KEYS](https://redis.io/docs/latest/commands/keys/) · Redis · Gunakan dengan sangat hati-hati di lingkungan produksi karena bisa merusak performa pada DB besar (40 ms untuk 1 juta key di laptop kelas entry-level) - [UNLINK](https://redis.io/docs/latest/commands/unlink/) · Redis · Penghapusan asinkron: key langsung dilepas, sedangkan pengambilan kembali memori dilakukan di thread lain - [SLOWLOG](https://redis.io/docs/latest/commands/slowlog/) · Redis · Log perintah lambat yang mencatat perintah yang melebihi slowlog-log-slower-than; waktu eksekusinya tidak mencakup I/O kirim-terima dengan klien - [Redis latency monitoring](https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/latency-monitor/) · Redis · latency-monitor-threshold default 0 (nonaktif); LATENCY LATEST dan LATENCY DOCTOR; mencatat latensi per event seperti fork dan expire-cycle - [INFO](https://redis.io/docs/latest/commands/info/) · Redis · latest_fork_usec: waktu yang dibutuhkan fork terakhir (mikrodetik) - [Redis CLI](https://redis.io/docs/latest/develop/tools/cli/) · Redis · --bigkeys: memindai keyspace untuk menemukan key besar #### db-plan-flip · Query melambat karena query plan berubah · Query plan regression (stats, parameter sniffing) Walaupun kodenya tidak berubah, jika DB mengganti cara memproses query yang sama (query plan), query yang kemarin 2 ms bisa menjadi ratusan ms hari ini. - Mengapa → Akibatnya → Di layar: Pembaruan statistik otomatis, restart DB, atau perubahan distribusi data membuat DB menyusun query plan baru → Plan yang tidak memakai indeks terpilih, sehingga query yang sama menjadi puluhan hingga ratusan kali lebih lambat dan koneksi tertahan → Tanpa ada deploy, loading fitur tertentu tiba-tiba melambat dan request lain ikut menunggu - Gejala: Input lag, Tidak bisa masuk / loading tanpa henti / Faktor: Latensi, Stall - Siapa: Fitur tertentu saja, Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur DB (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pisahkan query yang jumlah hasilnya sangat berbeda tergantung nilainya atau pertimbangkan plan hint, rancang query yang pasti memakai indeks. - Tugas Tim Infrastruktur: Pantau query lambat dan riwayat query plan, kunci plan yang baik (Query Store SQL Server dan sejenisnya), atur waktu pembaruan statistik. - Di grafik: Naik seperti anak tangga (Rata-rata waktu eksekusi per query) - Yang diperiksa: Kumpulkan rata-rata waktu query berpola sama secara berkala dan periksa trennya. MySQL: AVG_TIMER_WAIT di events_statements_summary_by_digest. PostgreSQL: mean_exec_time di pg_stat_statements (versi 12 ke bawah: mean_time). Bandingkan query plan sebelum dan sesudah melambat dengan EXPLAIN atau auto_explain PostgreSQL; di SQL Server, gunakan tampilan Regressed Queries di Query Store - Cocok jika: Pada waktu tanpa deploy, rata-rata waktu satu query naik seperti anak tangga hingga puluhan kali lipat, waktunya bertepatan dengan pembaruan statistik atau restart DB, dan query plan-nya sudah berubah - Tidak cocok jika: Query plan tidak berubah tetapi query melambat: lebih mungkin pertambahan data, menunggu lock (db-hot-row), atau disk - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: SQL Server memakai ulang plan yang disusun berdasarkan nilai yang pertama kali masuk (parameter sniffing). Jika plan yang disusun untuk karakter baru dengan beberapa item saja dipakai untuk karakter lama dengan puluhan ribu item, query menjadi sangat lambat, dan kasus sebaliknya juga sering terjadi. Saat plan terhapus karena restart, query kembali normal, lalu bisa memburuk lagi. - Sumber: - [Query Processing Architecture Guide](https://learn.microsoft.com/en-us/sql/relational-databases/query-processing-architecture-guide) · Microsoft SQL Server · Parameter sniffing: query plan disusun berdasarkan nilai parameter yang masuk saat kompilasi atau rekompilasi - [Parameter Sensitive Plan Optimization](https://learn.microsoft.com/en-us/sql/relational-databases/performance/parameter-sensitive-plan-optimization) · Microsoft SQL Server · Jika distribusi data tidak merata, satu plan yang disimpan di cache tidak cocok untuk semua nilai parameter - [Monitor performance by using the Query Store](https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store) · Microsoft SQL Server · Plan berubah karena perubahan statistik, skema, atau indeks, dan plan cache hanya menyimpan plan terbaru; plan forcing di Query Store mengunci plan yang baik; tampilan Regressed Queries membandingkan query yang melambat beserta plan-nya - [Statement Summary Tables](https://dev.mysql.com/doc/refman/8.4/en/performance-schema-statement-summary-tables.html) · MySQL · events_statements_summary_by_digest: COUNT_STAR dan AVG_TIMER_WAIT (waktu rata-rata) per pola query yang sama - [pg_stat_statements — track statistics of SQL planning and execution](https://www.postgresql.org/docs/current/pgstatstatements.html) · PostgreSQL · calls, total_exec_time, dan mean_exec_time (rata-rata waktu eksekusi) per statement - [pg_stat_statements (PostgreSQL 12 Documentation)](https://www.postgresql.org/docs/12/pgstatstatements.html) · PostgreSQL · Sampai versi 12, nama kolomnya total_time dan mean_time - [auto_explain — log execution plans of slow queries](https://www.postgresql.org/docs/current/auto-explain.html) · PostgreSQL · Mencatat query plan dari query yang berjalan lebih lama dari auto_explain.log_min_duration ke log #### db-ddl-lock · Lock akibat perubahan skema (DDL) saat layanan berjalan · Schema change lock (DDL / metadata lock) Jika kolom atau indeks ditambahkan ke tabel saat layanan berjalan, satu lock yang dibutuhkan sesaat bisa membuat semua request yang memakai tabel itu menunggu. - Mengapa → Akibatnya → Di layar: Hotfix menambahkan kolom atau indeks ke tabel yang sedang dipakai layanan → Perubahan skema menunggu transaksi panjang yang sudah terbuka lebih dulu, dan semua request yang datang sesudahnya menunggu perubahan skema itu → Fitur yang memakai tabel itu (inventory, mail, dan sebagainya) berhenti total lalu timeout - Gejala: Input lag, Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti / Faktor: Stall - Siapa: Fitur tertentu saja, Seluruh server / Kapan: Sesekali secara acak, Tepat setelah login atau maintenance - Penanggung jawab utama: Infrastruktur DB (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Untuk hotfix yang berisi perubahan skema, sepakati jadwalnya dengan Infrastruktur DB, deploy lebih dulu kode yang tetap berjalan walaupun kolom baru belum ada. - Tugas Tim Infrastruktur: Pasang batas waktu tunggu lock yang pendek dan coba lagi jika gagal, jalankan saat tidak ada transaksi panjang, gunakan tools perubahan skema online, ubah tabel besar saat maintenance. - Di grafik: Naik seperti anak tangga (Jumlah sesi yang menunggu lock, latensi query pada tabel itu) - Yang diperiksa: MySQL: hitung sesi dengan State Waiting for table metadata lock di SHOW PROCESSLIST, lalu cari sesi yang memblokir (blocking_pid) dengan sys.schema_table_lock_waits. PostgreSQL: periksa request dengan granted bernilai false dan AccessExclusiveLock di pg_locks, lalu cari sesi yang memblokir dengan pg_blocking_pids() - Cocok jika: Sejak perubahan skema dimulai, semua query yang memakai tabel itu menumpuk menunggu lock, dan di posisi paling depan ada transaksi yang belum selesai atau statement perubahan skema - Tidak cocok jika: Request yang menunggu hanya terpusat di baris tertentu, sedangkan baris lain di tabel yang sama diproses dengan lancar: lebih mungkin hot row (db-hot-row) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Saat skema diubah, MySQL memegang metadata lock sesaat, sedangkan PostgreSQL memegang table lock terkuat sesaat. Walaupun perubahannya sendiri selesai dalam sekejap, jika di depannya ada satu transaksi yang belum selesai, semua request di belakangnya menunggu. - Sumber: - [Online DDL Performance and Concurrency](https://dev.mysql.com/doc/refman/8.4/en/innodb-online-ddl-performance.html) · MySQL · Online DDL pun membutuhkan exclusive metadata lock sesaat di tahap akhir; jika ada transaksi panjang, DDL menunggu, dan permintaan lock yang menunggu itu menahan semua transaksi di belakangnya - [Server System Variables](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html) · MySQL · lock_wait_timeout: batas waktu tunggu metadata lock, default 31.536.000 detik (1 tahun) - [ALTER TABLE (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/sql-altertable.html) · PostgreSQL · ALTER TABLE tanpa keterangan khusus memegang lock ACCESS EXCLUSIVE yang paling kuat - [Client Connection Defaults (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/runtime-config-client.html) · PostgreSQL · lock_timeout: statement dibatalkan jika menunggu lock lebih lama dari waktu ini - [General Thread States](https://dev.mysql.com/doc/refman/8.4/en/general-thread-states.html) · MySQL · Waiting for table metadata lock: status thread yang sedang menunggu metadata lock - [The schema_table_lock_waits and x$schema_table_lock_waits Views](https://dev.mysql.com/doc/refman/8.4/en/sys-schema-table-lock-waits.html) · MySQL · Sesi yang menunggu metadata lock (waiting_query) dan sesi yang memblokir (blocking_pid) - [pg_locks (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/view-pg-locks.html) · PostgreSQL · granted bernilai false berarti sedang menunggu lock; mode berisi jenis lock seperti AccessExclusiveLock - [System Information Functions and Operators (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/functions-info.html) · PostgreSQL · pg_blocking_pids(): daftar sesi yang menghalangi sesi tertentu mendapatkan lock ### L13 Arsitektur dan operasional server (13 penyebab) #### in-gateway · Rute lewat gateway atau proxy · Gateway / proxy hop Jika ada server perantara di antara klien dan server game, setiap kali paket melewatinya ada tambahan waktu pemrosesan, dan server itu menjadi single point of failure. - Mengapa → Akibatnya → Di layar: Arsitektur klien ↔ gateway ↔ server game → Ada tambahan pemrosesan dan antrean di server perantara; saat kelebihan beban, semua pemain terdampak → Ping semua pemain naik; saat gateway mengalami gangguan, semua pemain yang melewatinya disconnect - Gejala: Input lag, Disconnect / Faktor: Latensi, Stall - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul, Selalu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: rancang agar gateway bisa ditambah menjadi beberapa unit, dan agar karakter tetap berlanjut saat tersambung ulang ke gateway lain ketika satu gateway mati (penyambungan ulang sesi). Klien: reconnect otomatis saat koneksi ke gateway terputus. - Tugas Tim Infrastruktur: Scale out gateway secara horizontal (tambah unit), pantau CPU, jumlah koneksi, dan latensi pemrosesan per gateway. - Kisaran angka: Karena masih di dalam data center yang sama, biasanya kurang dari 1 ms setiap kali lewat. Jika gateway kelebihan beban, waktunya naik menjadi puluhan hingga ratusan ms. - Di grafik: Naik mengikuti beban (Latensi pemrosesan gateway, CPU dan jumlah koneksi gateway) - Yang diperiksa: Periksa CPU dan jumlah koneksi gateway, Recv-Q socket gateway (ss, netstat), serta selisih latensi sebelum dan sesudah melewati gateway. Untuk pemanggilan HTTP atau gRPC yang lewat service mesh, bandingkan metrik standar Istio istio_request_duration_milliseconds yang dipisah antara sisi pengirim (reporter=source) dan sisi penerima (reporter=destination) - Cocok jika: Waktu pemrosesan server game tetap, tetapi hanya latensi di segmen gateway yang naik, dan pada saat itu CPU gateway jenuh atau Recv-Q menumpuk - Tidak cocok jika: Rute yang tidak lewat gateway (koneksi langsung, gateway lain) juga sama lambatnya: lebih mungkin koneksi atau server game - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jika memakai service mesh (misalnya Istio), sidecar proxy (Envoy) yang menempel di samping setiap server juga menambah satu langkah. Permintaan antarlayanan melewati sidecar di sisi pengirim lalu sidecar di sisi penerima, dan makin banyak fitur yang ditambahkan ke proxy, seperti pengumpulan log dan metrik, makin panjang waktu pemrosesan dan waktu tunggunya. - Kasus nyata: riot-edge-2020 - Sumber: - [The Unique Architecture behind Amazon Games’ Seamless MMO New World](https://aws.amazon.com/blogs/gametech/the-unique-architecture-behind-amazon-games-seamless-mmo-new-world/) · AWS · Di New World, klien terhubung ke salah satu dari 4 server pintu masuk (REP) yang memiliki alamat publik, lalu berkomunikasi dengan server simulasi (hub) di belakangnya - [Designs, Lessons and Advice from Building Large Distributed Systems](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Keynote LADIS 2009 (Jeff Dean). Round trip di dalam data center yang sama sekitar 0,5 ms - [Site Reliability Engineering, Chapter 22: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) · Google · Jika antrean memanjang akibat kelebihan beban, waktu tunggu naik menjadi beberapa kali waktu pemrosesan (pemrosesan 100 ms dan antrean 10 kali jumlah thread berarti 1,1 detik) - [Performance and Scalability](https://istio.io/latest/docs/ops/deployment/performance-and-scalability/) · Istio · Dalam mode sidecar, permintaan melewati proxy sidecar di sisi pengirim lalu di sisi penerima; makin banyak fitur ditambahkan, makin panjang jalur pemrosesan di dalam proxy, dan pengumpulan telemetri menambah waktu tunggu permintaan berikutnya - [What is Envoy](https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy) · Envoy · Envoy adalah proses terpisah yang berjalan di samping setiap server aplikasi, dan aplikasi berkomunikasi lewat Envoy di localhost - [Istio Standard Metrics](https://istio.io/latest/docs/reference/config/metrics/) · Istio · istio_request_duration_milliseconds (distribusi waktu pemrosesan permintaan HTTP dan gRPC); label reporter membedakan proxy sisi pengirim (source) dan sisi penerima (destination) - [netstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/netstat.8.html) · net-tools · Recv-Q: jumlah byte di socket yang terhubung yang belum diambil oleh program pengguna #### in-zone-transfer · Pindah zona (handoff antarserver) · Zone / server handoff Saat masuk ke area atau dungeon lain, keterlambatan dan kegagalan bisa terjadi dalam proses memindahkan data karakter ke server lain. - Mengapa → Akibatnya → Di layar: Server yang menangani karakter berganti saat masuk dungeon atau pindah benua → Simpan → kirim → muat; jika server tujuan padat atau tidak ada instance dungeon yang kosong, harus menunggu → Loading lama, gagal masuk, disconnect saat berpindah - Gejala: Tidak bisa masuk / loading tanpa henti, Freeze, Disconnect, Rubber banding / Faktor: Latensi, Stall - Siapa: Hanya saya, Lokasi/channel tertentu / Kapan: Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Kurangi data yang dipindahkan, pesan server tujuan lebih dulu, kembalikan karakter ke posisi semula jika gagal. - Tugas Tim Infrastruktur: Pantau sisa instance kosong di server dungeon dan zona, siapkan jumlah server yang cukup sebelum jam sibuk. - Di grafik: Naik mengikuti beban (Waktu pindah zona dan jumlah kegagalan) - Yang diperiksa: Periksa waktu per tahap pemindahan yang dicatat server (simpan, kirim, muat) dan alasan kegagalannya, serta jumlah pemain dan jumlah instance kosong di server tujuan - Cocok jika: Pada waktu laporan loading lama atau gagal masuk, waktu pemindahan naik atau kegagalan menumpuk, dan server tujuan padat atau instance kosongnya habis - Tidak cocok jika: Pemindahan selesai cepat, tetapi game berhenti setelah karakter tiba: lebih mungkin lonjakan spawn saat masuk area padat atau loading di klien - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Seamless world yang tersambung tanpa loading pun mengganti server yang menangani karakter saat karakter melewati batas server. Di dekat batas itu bisa terjadi tersendat sesaat atau rubber banding yang menarik karakter ke belakang. - Sumber: - [The Unique Architecture behind Amazon Games’ Seamless MMO New World](https://aws.amazon.com/blogs/gametech/the-unique-architecture-behind-amazon-games-seamless-mmo-new-world/) · AWS · World tanpa loading dibagi menjadi grid yang ditangani beberapa server (hub), dan saat pemain bergerak state-nya dipindahkan dari hub ke hub; mode berbasis sesi mengambil server yang menganggur dari pool bersama #### in-cascade · Kegagalan berantai · Cascading failure Jika satu layanan melambat, server yang memanggilnya ikut tertahan menunggu respons, dan fitur yang tidak berhubungan pun ikut berhenti. - Mengapa → Akibatnya → Di layar: Satu layanan, seperti DB atau autentikasi, melambat → Thread dan koneksi server pemanggil tertahan menunggu respons, dan retry dari permintaan yang gagal menambah beban → Fitur yang tampak tidak berhubungan pun ikut melambat atau berhenti - Gejala: Freeze, Input lag, Tidak bisa masuk / loading tanpa henti / Faktor: Stall - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul, Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Pasang timeout di setiap pemanggilan, circuit breaker, isolasi per fitur (bulkhead), retry dengan interval yang makin panjang dan jumlah yang dibatasi, pisahkan respons health check dari pekerjaan yang berat. - Tugas Tim Infrastruktur: Beri kelonggaran pada jumlah kegagalan dan interval health check load balancer agar server yang lambat sesaat tidak langsung dikeluarkan, batasi jumlah server yang dikeluarkan sekaligus. - Di grafik: Mendatar di batas (Waktu respons dan tingkat error per layanan, jumlah thread dan koneksi yang terpakai) - Yang diperiksa: Tampilkan waktu respons, tingkat error, dan jumlah retry per layanan dalam satu layar dengan sumbu waktu yang disamakan, lalu cari bagian yang paling dulu melambat. Jika di belakang load balancer, periksa waktu respons target (di AWS ALB: TargetResponseTime), jumlah 5xx dari target (HTTPCode_Target_5XX_Count), dan jumlah target yang dikeluarkan karena tidak sehat (UnHealthyHostCount) - Cocok jika: Latensi satu layanan naik lebih dulu, lalu jumlah thread dan koneksi yang terpakai di pihak pemanggil layanan itu menempel di batas, error merambat ke layanan lain, dan jumlah retry serta jumlah target yang dikeluarkan ikut naik - Tidak cocok jika: Beberapa layanan melambat bersamaan pada saat yang sama: periksa dulu gangguan pada sumber daya bersama (DB, jaringan, host) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Health check (pemeriksaan apakah server masih hidup) juga memperbesar efek berantai. Jika server yang sibuk terlambat menjawab pemeriksaan, load balancer mengeluarkan server yang sebenarnya normal, trafiknya membanjiri server yang tersisa, dan server berikutnya pun ikut terlambat. - Kasus nyata: riot-edge-2020, riot-euw-2021, roblox-2021, aws-2021, aws-2025 - Sumber: - [Site Reliability Engineering, Chapter 22: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) · Google · Jika server yang kelebihan beban gagal health check dan dikeluarkan, beban menumpuk di server yang tersisa dan retry memperbesar beban; disarankan membatasi jumlah retry, exponential backoff acak, dan deadline - [Circuit Breaker Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker) · Microsoft Azure · Permintaan yang tertahan sampai timeout menahan thread dan koneksi DB sehingga fitur yang tidak berhubungan pun gagal; jika kegagalan menumpuk dalam waktu tertentu, pemanggilan langsung ditolak - [Timeouts, retries, and backoff with jitter](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf) · AWS · Amazon Builders' Library. Pada rantai pemanggilan 5 tingkat, jika setiap tingkat melakukan retry 3 kali, beban DB menjadi 243 kali lipat; lakukan retry di satu tempat saja dan batasi dengan token bucket - [CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) · AWS · TargetResponseTime (waktu sejak permintaan meninggalkan load balancer sampai target mulai merespons), HTTPCode_Target_5XX_Count (jumlah 5xx yang dihasilkan target), UnHealthyHostCount (jumlah target yang tidak sehat) #### in-subservice · Gangguan server pendukung · Auxiliary service outage Jika server yang berjalan terpisah dari server game, seperti server chat, party, atau balai lelang, mengalami gangguan, hanya fitur itu yang tidak berfungsi. - Mengapa → Akibatnya → Di layar: Server khusus fitur melambat atau mati → Hanya permintaan untuk fitur itu yang tidak mendapat respons → Chat tidak jalan, undangan party tidak direspons, market loading tanpa henti (pertempuran tetap normal) - Gejala: Aksi hilang / rollback, Tidak bisa masuk / loading tanpa henti / Faktor: Stall, Packet loss - Siapa: Fitur tertentu saja / Kapan: Sesekali secara acak, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Rancang agar game tetap berjalan meskipun fitur itu gagal, tampilkan status per fitur, jangan memusatkan banyak fitur di satu server pusat. - Tugas Tim Infrastruktur: Pasang health check dan alert per server pendukung, siapkan redundansi dan restart otomatis. - Di grafik: Koneksi putus serentak (Tingkat keberhasilan permintaan per fitur, jumlah koneksi dan health check server pendukung) - Yang diperiksa: Periksa health check, status proses, dan jumlah koneksi per server pendukung seperti chat, party, dan balai lelang, serta tingkat keberhasilan dan waktu respons permintaan per fitur. Jika di belakang load balancer, periksa UnHealthyHostCount pada target group - Cocok jika: Hanya server yang menangani fitur yang dilaporkan yang menunjukkan health check gagal atau koneksi anjlok, sedangkan tick dan pertempuran di server game normal - Tidak cocok jika: Banyak fitur berhenti bersamaan: lebih mungkin server pusat yang menjadi perantara fitur-fitur itu, atau kegagalan berantai - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jika satu server pusat (server world atau server manager) menjadi perantara untuk party, guild, whisper, dan perpindahan antarserver sekaligus, banyak fitur berhenti bersamaan saat server itu saja melambat. - Sumber: - [Bulkhead Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead) · Microsoft Azure · Jika komponen diisolasi ke dalam pool masing-masing, saat satu komponen gagal sisanya tetap berjalan dan gangguan tidak merambat - [REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) · AWS · AWS Well-Architected. Rancang agar fungsi inti tetap berjalan dengan data yang agak lama atau data pengganti meskipun layanan yang diandalkan sedang mengalami gangguan - [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) · AWS · UnHealthyHostCount: jumlah target yang dinilai tidak sehat oleh health check #### in-deploy · Deploy dan restart · Deploy / rolling restart Jika koneksi tidak dipindahkan saat server dimulai ulang untuk update, pemain di server itu disconnect, lalu penyimpanan data menjelang shutdown dan reconnect membanjir sekaligus. - Mengapa → Akibatnya → Di layar: Server dimulai ulang satu per satu untuk deploy hotfix → Server dimatikan tanpa memindahkan koneksi ke server lain, penyimpanan data semua pemain di server itu membanjiri DB → Disconnect tanpa pengumuman, lonjakan reconnect - Gejala: Disconnect, Tidak bisa masuk / loading tanpa henti, Input lag / Faktor: Stall - Siapa: Seluruh server, Lokasi/channel tertentu / Kapan: Sesekali secara acak, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Sediakan fitur drain (blokir koneksi baru saja dan tunggu sampai pemain yang ada keluar), pindahkan karakter ke server lain, cicil penyimpanan sebelum shutdown, umumkan status siap setelah pemuatan cache dan JIT warm-up selesai sesudah restart, untuk hot reload baca data lebih dulu di thread terpisah lalu ganti sekaligus di antara tick. - Tugas Tim Infrastruktur: Buat tools deploy menunggu drain selesai per server sebelum restart, biarkan server yang baru dimulai ulang menerima trafik setelah status siap (pemanasan selesai) dipastikan, umumkan jadwal deploy. - Kisaran angka: Jika satu server menampung 5.000 pemain, 5.000 penyimpanan membanjiri DB dalam beberapa detik menjelang shutdown. - Di grafik: Koneksi putus serentak (Jumlah koneksi per server, jumlah penulisan DB) - Yang diperiksa: Tumpangkan catatan kerja tools deploy (waktu restart per server) sebagai garis vertikal (anotasi) di grafik jumlah koneksi, jumlah disconnect, penulisan DB, dan permintaan login - Cocok jika: Jumlah koneksi per server anjlok satu per satu secara berurutan pada waktu restart, dengan penulisan DB melonjak tepat sebelumnya dan permintaan login melonjak tepat sesudahnya - Tidak cocok jika: Waktu putusnya koneksi tidak bertepatan dengan catatan deploy atau restart: lebih mungkin crash server atau perangkat jaringan - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Beberapa menit setelah dinyalakan ulang pun server masih lambat. Cache kosong sehingga query DB membanjir, dan server Java atau C# belum selesai mengoptimalkan kode selama berjalan (JIT warm-up), sehingga pekerjaan yang sama butuh waktu lebih lama. Cara membaca ulang script dan tabel data tanpa mematikan server (hot reload) juga membuat tick berhenti selama pembacaan sehingga terjadi jeda singkat. - Sumber: - [Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter](https://sre.google/sre-book/load-balancing-datacenter/) · Google · Server yang menerima SIGTERM masuk status lame duck, mengalihkan permintaan baru ke server lain, dan hanya menyelesaikan permintaan yang sedang berjalan; beberapa menit setelah restart kode belum dioptimalkan JIT sehingga butuh lebih banyak sumber daya, jadi server baru menerima trafik setelah pemanasan - [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) · Kubernetes · Readiness probe menahan trafik sampai pembuatan koneksi, pemuatan file, dan pemanasan cache selesai - [Edit target group attributes for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/edit-target-group-attributes.html) · AWS · Jika pendaftaran target dicabut, koneksi baru tidak lagi dikirim ke target itu dan koneksi yang ada dibiarkan selesai (drain, default 300 detik) #### in-autoscale · Keterlambatan autoscaling · Autoscaling lag Saat pemain membanjir, server ditambah secara otomatis, tetapi persiapannya butuh beberapa menit, dan selama itu server yang ada kelebihan beban. - Mengapa → Akibatnya → Di layar: Koneksi melonjak saat event dimulai → Butuh beberapa menit sampai server baru menyala dan siap → Slow motion dan tidak bisa masuk selama beberapa menit tepat setelah event dimulai - Gejala: Slow motion, Tidak bisa masuk / loading tanpa henti / Faktor: Stall - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul, Tepat setelah login atau maintenance - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Sebar pemain ke beberapa channel (pemain yang sudah ada di channel padat tidak bisa dipindahkan ke server baru), percepat waktu startup dan pemuatan data server baru. - Tugas Tim Infrastruktur: Lakukan scaling lebih dulu sebelum event, siapkan server cadangan yang sudah dipanaskan, saat mengurangi server matikan setelah pemain yang tersisa keluar. - Kisaran angka: Mendeteksi beban butuh 1 hingga beberapa menit (karena metrik dilihat sebagai rata-rata beberapa menit), lalu menyalakan server baru, membaca data game, dan mengisi cache butuh beberapa menit lagi. - Di grafik: Melonjak tepat setelah server dibuka (Jumlah instance, utilisasi CPU, antrean masuk) - Yang diperiksa: Tumpangkan catatan aktivitas autoscaling (waktu keputusan scale out, waktu instance baru mulai melayani) di grafik utilisasi CPU dan jumlah koneksi. Di AWS, gunakan metrik grup Auto Scaling (baru terlihat jika diaktifkan) GroupDesiredCapacity (jumlah target), GroupPendingInstances (sedang disiapkan), dan GroupInServiceInstances (sedang melayani) - Cocok jika: Selama beberapa menit setelah koneksi melonjak, hanya jumlah target dan instance yang sedang disiapkan yang naik, sementara CPU server yang ada menempel di batas, lalu beban mereda sejak instance yang melayani bertambah - Tidak cocok jika: Masih lambat setelah instance baru masuk: lebih mungkin penyebab di luar jumlah server (sumber daya bersama seperti DB, kegagalan berantai) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Autoscaling umumnya dipakai di bagian yang cukup menerima pemain baru di server baru, seperti login, gateway, dan dungeon. Mengurangi server juga bisa menimbulkan masalah. Jika server dikurangi pada dini hari saat pemain sepi dan dimatikan tanpa menunggu pemain yang tersisa keluar, pemain itu disconnect. - Kasus nyata: aws-2021, aws-2025 - Sumber: - [Target tracking scaling policies for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) · AWS · Metrik dasar EC2 berinterval 5 menit (1 menit jika detailed monitoring diaktifkan), jadi untuk bereaksi cepat disarankan metrik berinterval 1 menit atau kurang - [Amazon CloudWatch metrics for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-metrics.html) · AWS · Metrik grup baru dipublikasikan per 1 menit jika diaktifkan: GroupDesiredCapacity (jumlah yang ingin dipertahankan), GroupPendingInstances (jumlah instance yang belum melayani), GroupInServiceInstances (jumlah instance yang sedang melayani) - [Scheduled scaling for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) · AWS · Menambah dan mengurangi kapasitas lebih dulu pada waktu yang ditentukan, sesuai perubahan beban yang bisa diprediksi - [Decrease latency for applications with long boot times using warm pools](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) · AWS · Untuk aplikasi yang lama booting, keterlambatan scaling dikurangi dengan pool instance yang sudah diinisialisasi lebih dulu (warm pool) #### in-monitoring · Beban berlebih akibat log dan monitoring · Logging / monitoring overhead Saat terjadi gangguan, log melonjak, dan server yang mengirim log secara sinkron menjadi makin lambat karena log itu sendiri. - Mengapa → Akibatnya → Di layar: Error terjadi, volume kirim log dan metrik melonjak → Pengumpul log tertinggal, dan server yang mengirim secara sinkron ikut menunggu → Saat gangguan, patah-patah dan freeze menjadi lebih parah karena log - Gejala: Patah-patah, Freeze / Faktor: Stall - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul, Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Kirim secara asinkron, lakukan sampling, buang log jika buffer penuh, kirim log error yang sama secara digabung. - Tugas Tim Infrastruktur: Siapkan kapasitas pengumpul log berdasarkan lonjakan volume saat gangguan, pasang alert untuk penumpukan di pengumpul. - Di grafik: Melonjak acak sesekali (Volume kirim log, antrean pengumpul log) - Yang diperiksa: Periksa jumlah baris dan byte log per detik di server serta antrean dan jumlah log yang dibuang oleh agen pengumpul log, bersama waktu tick. Jika ada thread yang berhenti, periksa dengan bcc offcputime -p apakah thread itu menunggu di penulisan atau pengiriman log - Cocok jika: Saat tick melonjak, volume log melonjak menjadi puluhan kali lipat dari biasanya, dan waktu tunggu thread game terpusat pada call stack penulisan atau pengiriman log - Tidak cocok jika: Volume log sama seperti biasa, atau thread game tidak menunggu di bagian log: lonjakan log hanya akibat dari gangguan, jadi cari terpisah penyebab yang pertama kali memicu error - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Logging in C#](https://learn.microsoft.com/en-us/dotnet/core/extensions/logging) · Microsoft · Metode logging .NET bersifat sinkron, jadi jika storage lambat disarankan menulis dulu ke storage yang cepat lalu memindahkannya kemudian - [Asynchronous loggers](https://logging.apache.org/log4j/2.x/manual/async.html) · Apache Software Foundation · Logging asinkron menyerap lonjakan singkat dengan antrean, tetapi jika output terus lambat, antrean penuh dan kecepatannya turun ke kecepatan output yang paling lambat, atau log dibuang sesuai kebijakan (Discard) - [Demonstrations of offcputime, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/offcputime_example.txt) · IO Visor · Menjumlahkan waktu thread berhenti dan meninggalkan CPU (off-CPU) per call stack, -p untuk menentukan proses #### in-clock-skew · Selisih jam antarserver · Clock skew between servers Jika jam di setiap server sedikit berbeda, keputusan cooldown, buff, dan waktu mulai event tidak sama antarserver. - Mengapa → Akibatnya → Di layar: Jam server yang sinkronisasi waktunya berhenti selisih ratusan ms hingga beberapa detik dengan server lain → Jika waktu absolut, seperti waktu berakhirnya buff, dikirim antarserver, keputusannya meleset → Setelah berpindah, buff hilang atau cooldown mulai lagi dari awal - Gejala: Aksi hilang / rollback / Faktor: Latensi - Siapa: Hanya saya / Kapan: Saat bergerak atau pindah area - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Untuk komunikasi antarserver, kirim sisa waktu sebagai pengganti waktu absolut. - Tugas Tim Infrastruktur: Pantau sinkronisasi waktu (NTP, chrony), pasang alert untuk selisih jam antarserver. - Kisaran angka: Jika sinkronisasi waktu (NTP, chrony) normal, selisih antarserver di data center yang sama biasanya hanya beberapa ms. Jika sinkronisasi berhenti, atau server virtual lama berhenti lalu berjalan lagi, selisihnya melebar menjadi ratusan ms hingga beberapa detik. - Di grafik: Naik perlahan (Offset jam per server) - Yang diperiksa: Kumpulkan dan bandingkan System time (selisih jam sistem dengan jam NTP), Last offset, dan Ref time (waktu terakhir nilai ukur dari sumber waktu diterapkan) dari chronyc tracking di setiap server - Cocok jika: Offset server bermasalah selisih ratusan ms atau lebih dibandingkan server lain, atau Ref time-nya sudah lama berhenti, dan keputusan yang meleset hanya terjadi saat berpindah dari atau ke server itu - Tidak cocok jika: Offset semua server masih dalam beberapa ms: lebih mungkin perhitungan waktu di sisi game atau kesalahan sinkronisasi jam di klien - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jam satu server yang melompat maju atau mundur sekaligus dibahas di “Lompatan jam sistem (NTP step)” pada lapisan OS server. - Sumber: - [RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification](https://www.rfc-editor.org/rfc/rfc5905) · IETF · Klien NTP di LAN yang cepat biasanya akurat hingga beberapa ratus µs - [chrony – Frequently Asked Questions](https://chrony-project.org/faq.html) · chrony · Drift jam komputer biasa umumnya kurang dari 100 ppm, tetapi pada virtual machine bisa lebih besar; virtual machine yang dijeda lalu dilanjutkan bisa mengalami jam yang meleset sehingga perlu koreksi step - [clock_gettime(2) — Linux manual page](https://man7.org/linux/man-pages/man2/clock_gettime.2.html) · Linux man-pages · CLOCK_REALTIME bisa melompat tidak kontinu akibat perubahan manual atau koreksi NTP, sedangkan CLOCK_MONOTONIC tidak terpengaruh lompatan seperti itu - [chronyc(1)](https://chrony-project.org/doc/4.6/chronyc.html) · chrony · System time di chronyc tracking (selisih jam NTP dengan jam sistem), Last offset (offset yang diperkirakan saat koreksi terakhir), Ref time (waktu nilai ukur terakhir dari sumber waktu diterapkan) #### in-bots · Terlalu banyak macro dan bot · Bots and macros Bot mengirim permintaan jauh lebih sering daripada manusia sehingga menggerogoti throughput server. - Mengapa → Akibatnya → Di layar: Banyak bot terhubung dan mengulang berburu, berpindah, dan trade tanpa henti → Throughput server dan beban DB naik → Area berburu tertentu atau seluruh server melambat (slow motion, input lag) - Gejala: Slow motion, Input lag / Faktor: Stall - Siapa: Seluruh server, Lokasi/channel tertentu / Kapan: Selalu, Jam sibuk malam hari - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Deteksi bot, batasi frekuensi permintaan per akun dan karakter. - Tugas Tim Infrastruktur: Batasi frekuensi koneksi dan permintaan per IP (beri kelonggaran untuk warnet dan jaringan seluler karena banyak orang memakai satu IP), blokir rentang IP bot dengan firewall atau WAF. - Di grafik: Hanya sebagian yang tinggi (Permintaan per detik per akun dan IP) - Yang diperiksa: Periksa distribusi dan daftar teratas jumlah permintaan per detik per akun dan karakter dari log server game. Jika tidak ada metrik di kode, periksa jumlah permintaan per IP di firewall atau WAF - Cocok jika: Segelintir akun atau IP mengirim permintaan tanpa henti dengan frekuensi yang mustahil dicapai manusia, dan setelah dibatasi beban server turun dengan jelas - Tidak cocok jika: Permintaan tersebar merata di semua akun: lebih mungkin kenaikan jumlah pemain yang wajar (tick melewati budget, keterlambatan autoscaling) - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Using rate-based rule statements in AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html) · AWS · Menghitung jumlah permintaan per kriteria seperti IP, lalu membatasi kecepatan jika terlalu banyak dalam jendela waktu yang ditentukan - [RFC 6269: Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) · IETF · Jika banyak pelanggan berbagi satu IP, pemblokiran atau pembatasan berbasis IP ikut menghalangi pengguna lain #### in-external · Ketergantungan pada layanan eksternal · External dependencies (auth, billing, platform) Jika layanan eksternal seperti login platform, pembayaran, atau verifikasi identitas lambat atau berhenti, proses tertahan di tahap itu. - Mengapa → Akibatnya → Di layar: Gangguan atau keterlambatan di layanan autentikasi atau pembayaran eksternal → Tahap itu menunggu respons → Tidak bisa login, pembayaran gagal. Pemain yang sudah di dalam game baik-baik saja - Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback / Faktor: Stall - Siapa: Seluruh server, Fitur tertentu saja / Kapan: Tepat setelah login atau maintenance, Saat melakukan aksi tertentu - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pasang timeout dan pesan yang ramah untuk pemanggilan eksternal, simpan hasil autentikasi di cache, siapkan prosedur retry dan kompensasi pembayaran. - Tugas Pihak Eksternal: Minta penyedia autentikasi, pembayaran, dan platform untuk memastikan gangguan dan memulihkannya, beri tahu pemain bahwa gangguan ada di layanan eksternal. - Di grafik: Naik seperti anak tangga (Waktu respons dan tingkat error pemanggilan eksternal, jumlah login berhasil) - Yang diperiksa: Periksa waktu respons, tingkat error, dan jumlah timeout per pemanggilan eksternal seperti login platform, pembayaran, dan verifikasi identitas, serta halaman status penyedia - Cocok jika: Sejak kegagalan login atau pembayaran menumpuk, hanya error dan timeout pemanggilan eksternal tertentu yang naik satu tingkat lalu bertahan, dan halaman status penyedia mencatat gangguan pada waktu yang sama - Tidak cocok jika: Pemanggilan eksternal normal tetapi login tertahan: lebih mungkin server login itu sendiri (thread pool habis, DB) atau antrean koneksi (backlog) di sistem operasi - Sarana pemeriksaan: Log dan metrik server atau klien game - Kasus nyata: fastly-2021, aws-2021, aws-2025 - Sumber: - [Timeouts, retries, and backoff with jitter](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf) · AWS · Amazon Builders' Library. Selama menunggu respons, sumber daya seperti thread dan koneksi tertahan, jadi pasang timeout, dan lakukan retry pada API yang punya efek samping hanya jika idempotensinya terjamin - [Circuit Breaker Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker) · Microsoft Azure · Pemanggilan yang kemungkinan besar gagal langsung ditolak tanpa menunggu timeout agar waktu respons tetap terjaga - [REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) · AWS · AWS Well-Architected. Pertahankan fungsi inti saat layanan yang diandalkan mengalami gangguan, meskipun dengan data yang agak lama (dasar untuk menyimpan hasil autentikasi di cache) #### in-region-match · Kesalahan matchmaking dan penempatan region · Wrong region assignment (matchmaking / GeoDNS) Jika pemain ditempatkan di server region yang jauh padahal ada region yang dekat, ping pemain itu selalu tinggi walaupun koneksinya baik-baik saja. - Mengapa → Akibatnya → Di layar: Data GeoIP salah, VPN, seluruh party ditempatkan berdasarkan rata-rata ping anggotanya, aturan yang memperluas pencarian ke region jauh saat pemain kurang, penempatan berdasarkan lokasi DNS resolver → Terhubung ke server region di seberang laut padahal ada region yang dekat → Di game yang punya server di beberapa region, hanya Anda (atau hanya party Anda) yang ping-nya selalu tinggi, disertai input lag, rubber banding, dan skill tidak keluar - Gejala: Input lag, Rubber banding, Aksi hilang / rollback / Faktor: Latensi - Siapa: Hanya saya, Wilayah/ISP tertentu / Kapan: Selalu, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur), Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Server: tempatkan pemain berdasarkan ping per region yang diukur klien sebagai pengganti GeoIP, pasang batas ping pada aturan perluasan ke region jauh, untuk party lihat juga ping anggota tertinggi selain rata-ratanya, catat region yang dipilih dan ping saat itu di log. Klien: ukur ping per region lewat UDP dan sertakan dalam permintaan matchmaking, tampilkan region yang tersambung dan ping-nya di layar, sediakan pilihan untuk memilih region sendiri. - Tugas Tim Infrastruktur: Jika region dipilih lewat DNS, pastikan DNS otoritatif mendukung EDNS Client Subnet (jika resolver yang dipakai pemain tidak mengirimkannya, penempatan mengikuti lokasi resolver), perbarui database GeoIP secara berkala, tambahkan negara dan ASN GeoIP ke log koneksi server per region untuk menemukan negara dan ISP yang diarahkan ke region jauh. - Tugas Pihak Eksternal: Imbau pemain untuk mematikan VPN atau game booster lalu terhubung kembali, imbau pemain yang memakai DNS kantor atau DNS luar negeri untuk beralih ke DNS ISP, minta penyedia GeoIP mengoreksi lokasi yang salah. - Kisaran angka: Jika pemain di Seoul ditempatkan di region US West padahal seharusnya di Tokyo, ping naik dari sekitar 30 ms menjadi sekitar 130 ms. GeoIP akurat sekitar 99,8% pada tingkat negara, tetapi pada tingkat kota, bahkan di Amerika Serikat, hanya sekitar 66% yang jatuh dalam radius 50 km, dan jika memakai VPN, yang terdeteksi adalah lokasi server VPN. - Di grafik: Hanya sebagian yang tinggi (RTT (ping) per pemain, distribusi region yang dipilih) - Yang diperiksa: Tambahkan negara dan ASN GeoIP ke IP klien yang tercatat di log koneksi server per region (log akses load balancer, VPC Flow Logs), lalu hitung region yang dituju per negara dan ISP. Untuk satu pemain, bandingkan region yang benar-benar dituju pemain itu dengan ping ke region terdekat (diukur oleh pemain, atau dengan mtr dari server region itu ke IP pemain) - Cocok jika: Pemain atau negara dengan RTT tinggi terhubung ke region jauh padahal ada region dekat, dan ping yang diukur ke region dekat rendah - Tidak cocok jika: Sudah ditempatkan dengan benar di region dekat tetapi ping tetap tinggi: lebih mungkin routing memutar, atau koneksi atau Wi-Fi pemain itu - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Cara memilih region lewat DNS (DNS berbasis geolokasi atau latensi) menebak lokasi pemain dari alamat DNS resolver yang dipakainya. Jika resolver tidak mendukung EDNS Client Subnet, yang meneruskan sebagian alamat pemain, pemain yang memakai DNS kantor atau DNS yang jauh ditempatkan berdasarkan lokasi resolver. Sistem matchmaking juga bisa menilai party dari rata-rata ping anggotanya, atau memperlonggar batas ping saat antrean lama sehingga menempatkan party di region jauh. AWS GameLift Servers pun memakai rata-rata sebagai kriteria default ping party, dan mencontohkan pengaturan yang memperlebar batas ping dari 50 ms ke 100 ms lalu 200 ms. Pada pemain yang menyalakan VPN, latensi tambahan karena lewat server relay (“Rute lewat VPN atau game booster”) bisa bertumpuk dengan penempatan di region jauh, jadi bedakan keduanya dengan melihat apakah region yang dipilih berubah saat VPN dimatikan lalu pemain terhubung kembali. Kasus terhubung ke region jauh karena memang tidak ada region yang dekat dibahas di “Latensi propagasi (jarak fisik)”. - Sumber: - [RFC 7871: Client Subnet in DNS Queries](https://www.rfc-editor.org/rfc/rfc7871) · IETF · DNS yang menjawab berbeda menurut lokasi menebak lokasi dari alamat resolver yang mengirim query, dan jika pengguna memakai resolver pusat yang jauh dari dirinya, jawabannya tidak tepat. EDNS Client Subnet (fitur opsional) meneruskan sebagian alamat pengguna - [How Amazon Route 53 uses EDNS0 to estimate the location of a user](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html) · AWS · Jika resolver tidak mendukung edns-client-subnet, lokasi pengguna ditebak dari alamat resolver dan jawabannya mengikuti lokasi resolver (berlaku untuk routing berbasis geolokasi maupun latensi) - [Geolocation accuracy](https://support.maxmind.com/knowledge-base/articles/maxmind-geolocation-accuracy) · MaxMind · Tingkat negara sekitar 99,8%, tingkat kota di AS (dalam 50 km) sekitar 66%; dengan VPN yang terlihat adalah lokasi server VPN; IP jaringan seluler dipakai di wilayah luas sehingga lokasi rinci tidak bisa diketahui; database harus terus diperbarui; koreksi bisa diminta - [FlexMatch rule types](https://docs.aws.amazon.com/gameliftservers/latest/flexmatchguide/match-rules-reference-ruletype.html) · AWS · Aturan latensi (maxLatency) melihat latensi pemain per lokasi, party secara default memakai rata-rata anggota (partyAggregation avg), dan queue bisa menempatkan game di region yang tidak memenuhi aturan latensi - [Create a player latency policy](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/queues-design-latency.html) · AWS · Menempatkan game di lokasi dengan rata-rata latensi semua pemain paling rendah, tetapi pemain dengan latensi ekstrem pun ikut ditempatkan; contoh kebijakan yang memperlebar batas ping dari 50 ms ke 100 ms lalu 200 ms - [Amazon GameLift Servers UDP ping beacons](https://docs.aws.amazon.com/gameliftservers/latest/developerguide/reference-udp-ping-beacons.html) · AWS · Klien game mengukur latensi ke endpoint UDP di setiap lokasi hosting dan memakainya untuk penempatan dan matchmaking; hasilnya lebih mendekati trafik game sebenarnya dibandingkan ping ICMP - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Median round trip terukur dari Seoul (Korea Central): Tokyo (Japan East) 29 ms, US West 124–136 ms - [Flow log records](https://docs.aws.amazon.com/vpc/latest/userguide/flow-log-records.html) · AWS · srcaddr pada record VPC Flow Logs: untuk trafik masuk, alamat IP pengirim #### in-cert · Sertifikat TLS kedaluwarsa atau salah konfigurasi · TLS certificate expiry / misconfiguration Jika sertifikat server login, API, atau patch kedaluwarsa atau sertifikat perantaranya tidak disertakan, koneksi TLS dari klien yang baru tersambung gagal sejak saat itu. - Mengapa → Akibatnya → Di layar: Masa berlaku sertifikat sudah lewat, server mengirim tanpa sertifikat perantara, atau tanggal dan jam di perangkat pemain salah → Klien gagal memverifikasi sertifikat dan memutus koneksi TLS → Tidak bisa masuk atau loading tanpa henti di tahap login atau patch, atau hanya fitur HTTPS seperti toko yang gagal. Pemain yang sudah terhubung biasanya baik-baik saja - Gejala: Tidak bisa masuk / loading tanpa henti, Aksi hilang / rollback / Faktor: Stall - Siapa: Seluruh server, Fitur tertentu saja, Hanya saya / Kapan: Tepat setelah login atau maintenance, Saat melakukan aksi tertentu - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Catat error sertifikat dengan kode error yang dibedakan dari kegagalan koneksi lain dan tampilkan panduannya, jika masalahnya tanggal minta pemain menyetel tanggal dan jam perangkat secara otomatis, jika memakai certificate pinning sertakan kunci cadangan dan samakan jadwal penggantian sertifikat dengan Tim Infrastruktur. - Tugas Tim Infrastruktur: Jaringan: jika TLS diterminasi di load balancer atau CDN, pasang alert untuk status pembaruan otomatis dan sisa hari sertifikat terkelola (di ACM: DaysToExpiry), pertahankan record DNS untuk validasi. Server/OS: jika TLS diterminasi di server, otomatiskan pembaruan dan muat ulang konfigurasi setelah pembaruan, konfigurasikan chain yang menyertakan sertifikat perantara, periksa sisa masa berlaku setiap alamat login, API, dan patch secara berkala dari luar dan pasang alert. - Kisaran angka: Sertifikat Let’s Encrypt berlaku 90 hari dan disarankan diperbarui setiap 60 hari, sedangkan AWS Certificate Manager memeriksa sertifikat yang divalidasi lewat DNS 45 hari sebelum kedaluwarsa lalu memperbaruinya otomatis. Jika pembaruan otomatis gagal diam-diam, koneksi baru tertahan serentak tepat pada saat kedaluwarsa. - Di grafik: Koneksi putus serentak (Jumlah login berhasil, jumlah error TLS handshake) - Yang diperiksa: Lihat daftar sertifikat yang benar-benar dikirim server dengan openssl s_client -connect HOST:443 -showcerts, lalu periksa tanggal kedaluwarsa (notAfter) tiap sertifikat dengan openssl x509 -noout -enddate. Jika TLS diterminasi di load balancer, periksa jumlah error negosiasi TLS (di AWS ALB dan NLB: ClientTLSNegotiationErrorCount) dan jumlah login berhasil - Cocok jika: Tanggal kedaluwarsa sudah lewat atau sertifikat perantara tidak ada di daftar yang dikirim server, dan waktu error mulai naik bertepatan dengan waktu kedaluwarsa atau waktu sertifikat diganti - Tidak cocok jika: Daftar sertifikat dan tanggal kedaluwarsa normal tetapi hanya sebagian pemain yang gagal: periksa tanggal dan jam perangkat pemain itu, atau daftar root certificate di OS lama - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Konfigurasi tanpa sertifikat perantara bisa terlihat normal saat dibuka di browser PC. Browser mengingat sertifikat perantara yang pernah diterima dari situs lain dan memakainya untuk mengisi kekosongan, tetapi klien yang tidak punya ingatan seperti itu, misalnya aplikasi Android, akan gagal. Masa berlaku juga makin pendek. Let’s Encrypt berencana memangkas masa berlaku default menjadi 64 hari pada 2027 dan 45 hari pada 2028, sehingga konfigurasi yang dipatok memperbarui setiap 60 hari hanya punya sisa empat hari untuk sertifikat 64 hari, dan sudah melewati masa kedaluwarsa untuk sertifikat 45 hari. AWS Certificate Manager juga tidak memperbarui otomatis sertifikat yang diimpor (import), dan pembaruan gagal jika record DNS untuk validasi dihapus. Gejala login tertahan mirip dengan “Gangguan dan latensi DNS”, tetapi masalah sertifikat gagal di TLS handshake setelah alamat server ditemukan, dan waktu mulainya bertepatan dengan waktu kedaluwarsa atau waktu sertifikat diganti. - Sumber: - [RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile](https://www.rfc-editor.org/rfc/rfc5280) · IETF · Masa berlaku sertifikat dari notBefore sampai notAfter; validasi jalur memeriksa apakah waktu saat ini masih dalam masa berlaku untuk setiap sertifikat di chain (gagal jika jam pihak yang memvalidasi salah) - [FAQ](https://letsencrypt.org/docs/faq/) · Let's Encrypt · Masa berlaku default sertifikat 90 hari, disarankan diperbarui setiap 60 hari - [Decreasing Certificate Lifetimes to 45 Days](https://letsencrypt.org/2025/12/02/from-90-to-45) · Let's Encrypt · Memangkas masa berlaku default menjadi 64 hari mulai Februari 2027 dan 45 hari mulai Februari 2028; pembaruan dengan interval tetap 60 hari tidak lagi cukup, jadi disarankan memperbarui pada sekitar dua pertiga masa berlaku - [Renewal for domains validated by DNS](https://docs.aws.amazon.com/acm/latest/userguide/dns-renewal-validation.html) · AWS · 45 hari sebelum kedaluwarsa, memeriksa apakah sertifikat dipakai di layanan AWS dan apakah record CNAME untuk validasi ada, lalu memperbaruinya otomatis; jika tidak bisa divalidasi, notifikasi dikirim 30, 15, 7, 3, dan 1 hari sebelum kedaluwarsa - [Managed certificate renewal in AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html) · AWS · Sertifikat yang diimpor (import) dan sertifikat yang sudah kedaluwarsa tidak diperbarui otomatis - [Supported CloudWatch metrics](https://docs.aws.amazon.com/acm/latest/userguide/cloudwatch-metrics.html) · AWS · DaysToExpiry: sisa hari sampai sertifikat kedaluwarsa, dipublikasikan dua kali sehari sampai kedaluwarsa - [Security with network protocols](https://developer.android.com/privacy-and-security/security-ssl) · Android (Google) · Jika server mengirim tanpa sertifikat perantara, aplikasi Android gagal dengan SSLHandshakeException, tetapi browser PC bisa tidak menampilkan error karena mengisinya dengan sertifikat perantara yang pernah diterima; periksa chain yang dikirim server dengan openssl s_client - [Network security configuration](https://developer.android.com/privacy-and-security/security-config) · Android (Google) · Jika memakai certificate pinning, kunci cadangan harus disertakan untuk berjaga-jaga saat kunci diganti atau CA berubah; jika tidak, koneksi terputus sampai aplikasi diperbarui - [openssl-s_client](https://docs.openssl.org/3.0/man1/openssl-s_client/) · OpenSSL · -showcerts: menampilkan daftar sertifikat yang dikirim server sesuai urutan pengirimannya (daftar ini belum tentu chain yang terverifikasi) - [openssl-x509](https://docs.openssl.org/3.0/man1/openssl-x509/) · OpenSSL · -enddate: menampilkan tanggal kedaluwarsa sertifikat (notAfter); -checkend: memeriksa apakah sertifikat kedaluwarsa dalam jumlah detik yang ditentukan - [CloudWatch metrics for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) · AWS · ClientTLSNegotiationErrorCount: jumlah koneksi yang gagal membentuk sesi TLS, misalnya saat klien memutus koneksi karena gagal memverifikasi sertifikat server - [CloudWatch metrics for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) · AWS · ClientTLSNegotiationErrorCount: jumlah TLS handshake yang gagal bernegosiasi antara klien dan TLS listener #### in-login-queue · Batas antrean login dan masa tenggang reconnect yang terlalu singkat · Login queue cap / no reconnect grace Jika koneksi membanjir tepat setelah rilis atau maintenance, antrean login mencapai batas dan menolak antrean baru, sementara pemain yang sedang menunggu kehilangan tempatnya saat koneksinya terputus sebentar dan kembali ke urutan paling belakang. - Mengapa → Akibatnya → Di layar: Orang yang ingin masuk lebih banyak daripada kapasitas yang bisa diterima server login sekaligus, sehingga dibuat antrean, dan jika antrean terlalu panjang, antrean baru ditolak untuk melindungi server → Makin panjang antrean, makin lama waktu tunggu, dan selama itu Wi-Fi atau jaringan seluler yang terputus sebentar saja sudah membuat tempat di antrean hilang → Tidak bisa masuk atau loading tanpa henti, game tertutup dengan error saat menunggu, harus mengantre lagi dari belakang - Gejala: Tidak bisa masuk / loading tanpa henti, Disconnect / Faktor: Stall - Siapa: Seluruh server, Hanya saya / Kapan: Tepat setelah login atau maintenance, Jam sibuk malam hari - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Server: sesuaikan batas antrean dengan kapasitas yang benar-benar bisa diproses server login, simpan tempat pemain yang terputus saat menunggu selama waktu tertentu (masa tenggang reconnect), tampilkan nomor antrean dan perkiraan waktu tunggu, catat panjang antrean, jumlah penolakan, dan jumlah koneksi terputus saat menunggu sebagai metrik. Klien: jika terputus saat menunggu, jangan tutup game dan lakukan reconnect otomatis ke tempat yang sama, sebar interval retry dengan exponential backoff dan jitter. - Tugas Tim Infrastruktur: Server/OS: ukur batas kapasitas server login dan lobby dengan uji beban sebelum rilis, siapkan agar server cadangan bisa langsung ditambahkan saat rilis, tampilkan metrik antrean dalam satu grafik dengan jumlah percobaan koneksi. - Kisaran angka: Saat ekspansi FINAL FANTASY XIV dirilis pada 2021, antrean baru ditolak jika jumlah pemain yang menunggu melebihi 17.000 per logical data center (Error 2002). Jika koneksi terputus saat menunggu, lobby server menunggu selama puluhan detik hingga 1 menit, dan jika pemain tersambung lagi dalam waktu itu, antrean dilanjutkan dari posisinya semula. - Di grafik: Mendatar di batas (Panjang antrean login, jumlah penolakan karena mencapai batas, jumlah koneksi terputus saat menunggu) - Yang diperiksa: Tampilkan panjang antrean, rata-rata waktu tunggu, jumlah penolakan karena mencapai batas, dan jumlah koneksi terputus saat menunggu yang dicatat server login dan lobby dalam satu grafik dengan jumlah percobaan koneksi - Cocok jika: Tepat setelah rilis atau maintenance, selama panjang antrean menyentuh batas dan mendatar, jumlah penolakan naik, dan koneksi terputus saat menunggu terpusat pada pemain Wi-Fi dan jaringan seluler - Tidak cocok jika: Antrean pendek tetapi login lambat: lebih mungkin DB (db-login-storm) atau antrean koneksi sistem operasi (so-backlog) - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Kasus DB melambat karena login membanjir dibahas di “Lonjakan login dan N+1 query”, dan kasus antrean koneksi sistem operasi meluap dibahas di “Antrean koneksi (backlog) meluap”. Entri ini membahas masalah desain antrean login yang sengaja dibuat oleh game. Batas antrean adalah pengaman untuk melindungi server login sehingga tidak bisa dihapus. Permintaan yang berlebih harus ditolak sejak awal agar permintaan yang masih bisa diproses tetap terproses. Karena itu, kuncinya adalah mengurangi kerugian pemain akibat penolakan dan koneksi terputus. Makin panjang antrean, makin banyak error yang menimpa pemain dengan koneksi tidak stabil, seperti Wi-Fi atau jaringan seluler. - Kasus nyata: ffxiv-2021 - Sumber: - [Response to Congestion (as of Dec. 11)](https://na.finalfantasyxiv.com/lodestone/news/detail/6a94b30182b6d963994fdc0b789264ac9f24986f) · Square Enix · Jika jumlah pemain yang menunggu melebihi 17.000 per logical data center, antrean baru ditolak agar server login tidak down (Error 2002); jika terputus saat menunggu, lobby server menunggu puluhan detik hingga 1 menit, dan jika tersambung lagi dalam waktu itu antrean dilanjutkan dari posisi semula, jika lewat kembali ke paling belakang - [Using load shedding to avoid overload](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/) · Amazon Builders' Library · Load shedding: menolak permintaan berlebih sejak awal agar permintaan yang bisa diproses tetap terproses ### Desain sinkronisasi (16 penyebab) #### sy-request-response · Feedback baru tampil setelah server merespons (model request-response) · Request-response (no client-side feedback) Saat tombol ditekan, tidak ada animasi maupun suara sampai jawaban server datang. Ping langsung menjadi kecepatan respons. - Mengapa → Akibatnya → Di layar: Skill, gerakan, dan pengambilan item baru diputar setelah konfirmasi server datang → Sejak tombol ditekan, tidak ada respons apa pun selama waktu pulang-pergi + waktu tunggu tick → Dengan ping 150 ms, setiap aksi terasa lamban 0,2 detik - Gejala: Input lag / Faktor: Latensi - Siapa: Hanya saya / Kapan: Selalu, Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: mulai animasi, suara, dan efek begitu tombol ditekan (feedback sisi klien), tampilkan hanya hasilnya (damage, hadiah) setelah server mengonfirmasi, terapkan gerakan dan serangan dasar langsung dengan prediksi, dan saat menerima koreksi posisi dari server, terapkan ulang input yang belum dikonfirmasi mulai dari posisi itu. Server: hitung sendiri gerakan dari input yang diterima, kirim nilai koreksi hanya jika selisihnya dengan posisi prediksi klien melewati batas. - Kisaran angka: Waktu respons ≈ ping + setengah interval tick + satu frame. Pada server 20 tick dengan ping 150 ms, sekitar 190 ms. - Di grafik: Selalu tinggi sejak awal (Waktu dari input sampai animasi dimulai, RTT (ping)) - Yang diperiksa: Catat waktu tombol ditekan, waktu animasi atau suara pertama dimulai, dan waktu respons server tiba di log klien pada build development, lalu bandingkan berdampingan dengan RTT di dalam game. Ukur sambil mengubah ping dengan menambahkan latensi lewat emulasi jaringan engine (Unreal NetEmulation.PktLag) atau tc netem Linux di server uji - Cocok jika: Animasi selalu dimulai tepat saat respons server tiba, waktu dari input sampai animasi sebesar RTT + waktu tunggu tick, dan bertambah persis sebesar latensi yang ditambahkan - Tidak cocok jika: Animasi dimulai begitu tombol ditekan dan hanya hasil seperti angka damage yang terlambat: desainnya normal. Tetap terlambat lebih dari satu interval tick walaupun ping rendah: lebih mungkin menunggu tick dua kali atau masalah frame di klien - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Untuk game yang tidak butuh respons cepat, seperti game turn-based, kartu, atau idle, cara ini paling sederhana dan aman. Masalah muncul saat game dengan kontrol real-time juga membuat gerakan atau serangan dasar dengan cara ini. - Sumber: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Klien yang hanya menunggu hasil dari server baru menampilkan setiap aksi 500 ms kemudian jika latensinya 500 ms. Diatasi dengan prediksi sisi klien dan rekonsiliasi server - [Using Gameplay Abilities in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-gameplay-abilities-in-unreal-engine) · Epic Games · Local Predicted langsung dijalankan begitu tombol ditekan dan keputusan akhirnya di server, sedangkan Server Initiated tidak punya prediksi sehingga latensi terlihat oleh pemakainya - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Klien memprediksi dan menyimpan gerakan, server hanya mengoreksi jika selisihnya melewati batas toleransi (MAXPOSITIONERRORSQUARED), dan setelah koreksi gerakan yang disimpan diterapkan ulang - [Using Network Emulation in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-network-emulation-in-unreal-engine) · Epic Games · Pengujian dengan memasukkan latensi minimum dan maksimum serta rasio packet loss ke server dan klien; di konsol diatur seperti NetEmulation.PktLag - [tc-netem(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-netem.8.html) · iproute2 · Tools pengujian yang meniru jaringan nyata dengan menambahkan latensi dan jitter (delay TIME JITTER) serta packet loss (loss random PERCENT) ke paket keluar #### sy-chatty · Protokol dengan banyak round trip berurutan (chatty) · Chatty protocol / sequential round trips Jika satu aksi butuh beberapa kali pulang-pergi ke server secara berurutan, ping dikalikan sebanyak jumlah itu. - Mengapa → Akibatnya → Di layar: Buka toko → minta daftar → cek harga → beli → perbarui inventory, masing-masing diminta terpisah → Permintaan berikutnya baru dikirim setelah jawaban permintaan sebelumnya diterima → Dengan ping 150 ms, satu kali beli butuh hampir 1 detik. Loading terasa sangat lama - Gejala: Input lag, Tidak bisa masuk / loading tanpa henti / Faktor: Latensi - Siapa: Fitur tertentu saja, Hanya saya / Kapan: Saat melakukan aksi tertentu, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: ubah protokol agar beberapa tahap digabung dalam satu permintaan dan respons (misalnya, sertakan inventory yang sudah diperbarui di respons pembelian). Klien: ambil data yang dibutuhkan lebih dulu, buat UI yang tidak menunggu hasil. - Kisaran angka: Waktu yang dibutuhkan ≈ jumlah round trip × (ping + pemrosesan server + waktu tunggu tick). Untuk 5 kali dengan ping 150 ms, sekitar 0,85–1 detik. - Di grafik: Selalu tinggi sejak awal (Waktu selesai per fitur, jumlah round trip per aksi) - Yang diperiksa: Dari packet capture di sisi server (Wireshark), hitung berapa kali permintaan dan respons bergantian dan berapa jeda di antaranya selama akun uji melakukan satu aksi, seperti membeli di toko atau login. Jika ada log permintaan server, kelompokkan berdasarkan ID sesi lalu periksa jumlah permintaan serta waktu tiba dan waktu respons setiap permintaan - Cocok jika: Dalam satu aksi, permintaan bolak-balik beberapa kali secara berurutan sambil menunggu respons sebelumnya, waktu selesai kira-kira jumlah round trip × RTT, dan makin tinggi ping wilayah pemain, makin lambat fitur yang sama secara proporsional - Tidak cocok jika: Round trip hanya satu atau dua kali tetapi satu respons lama: penyebabnya di pemrosesan server atau DB. Semua pemain sama lambatnya tanpa peduli ping: periksa beban server - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Chatty I/O antipattern](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/chatty-io/) · Microsoft Azure · Banyak permintaan I/O kecil membuat latensi kumulatif sangat menurunkan responsivitas. Disarankan menggabungkan permintaan menjadi lebih besar dan lebih sedikit #### sy-no-queue · Tidak ada input buffering untuk skill · No input/spell queue Jika skill berikutnya baru bisa ditekan setelah ada konfirmasi bahwa skill sebelumnya selesai di server, waktu pulang-pergi menyela setiap kombo. - Mengapa → Akibatnya → Di layar: Input skill berikutnya hanya diterima “setelah skill sebelumnya dikonfirmasi” → Di antara setiap skill muncul waktu kosong sebesar ping → Ada celah di antara setiap kombo, dan makin tinggi ping makin rendah DPS - Gejala: Input lag, Aksi hilang / rollback / Faktor: Latensi - Siapa: Hanya saya, Fitur tertentu saja / Kapan: Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: sediakan batas waktu input buffering, yaitu input dalam waktu tertentu sebelum cooldown selesai (misalnya 0,3–0,4 detik) tetap diterima dan langsung dikirim ke server. Server: jangan tolak input yang tiba sedikit lebih awal, jalankan tepat saat cooldown selesai. - Kisaran angka: Pada kombo dengan cooldown 1 detik dan ping 150 ms, ada jeda kosong 0,15 detik atau lebih di antara setiap skill, sehingga jumlah skill yang dipakai dalam waktu yang sama berkurang lebih dari 13%. - Di grafik: Selalu tinggi sejak awal (Waktu kosong di antara skill, RTT (ping)) - Yang diperiksa: Catat di log server, per karakter, waktu cooldown skill selesai, waktu permintaan skill berikutnya tiba, dan waktu skill dijalankan, lalu bandingkan waktu kosong di antaranya dengan RTT pemain - Cocok jika: Antara cooldown selesai dan skill berikutnya dijalankan selalu ada jeda sekitar RTT, makin tinggi ping pemain makin panjang jedanya, dan makin sedikit skill yang dipakai dalam waktu yang sama - Tidak cocok jika: Waktu kosong tetap tanpa peduli ping: lebih mungkin desain global cooldown atau panjang animasi. Waktu kosong hanya sesekali melonjak besar: periksa jitter, packet loss, atau tick melewati budget - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Misalnya, World of Warcraft punya batas waktu input buffering yang bisa diatur pemain di pengaturan. Jika batas waktu itu lebih panjang dari waktu pulang-pergi, ping hampir tidak menyela kombo. - Sumber: - [Latency and Player Actions in Online Games (Communications of the ACM, 2006)](https://web.cs.wpi.edu/~claypool/papers/precision-deadline/final.pdf) · ACM · Di EverQuest 2, makin besar latensi makin kecil damage yang diberikan karakter sehingga pertempuran makin lama (dari 0 ke 500 ms, pertempuran sekitar 2 menit bertambah 5 detik) #### sy-short-window · Timing window pendek yang termakan ping · Timing window too short for latency + reaction Jika waktu untuk bereaksi pendek, seperti pada dodge, parry, atau guard, ping memakan waktu itu sehingga muncul serangan yang mustahil dihindari. - Mengapa → Akibatnya → Di layar: Timing window pendek, seperti telegraph serangan boss 0,5 detik atau parry window 0,2 detik → Telegraph terlihat terlambat (latensi dari server ke klien + interpolasi), dan input Anda juga tiba terlambat (latensi dari klien ke server + waktu tunggu tick) → Jelas sudah menghindar tetapi tetap kena, parry tidak terhitung - Gejala: Aksi hilang / rollback, Input lag / Faktor: Latensi - Siapa: Hanya saya, Fitur tertentu saja / Kapan: Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Server: jadwalkan telegraph serangan dengan waktu server lalu kirim lebih dulu, perpanjang timing window sebesar ping (lag compensation). Klien: putar telegraph yang diterima sesuai waktu server yang dijadwalkan. - Tugas Tim Infrastruktur: Tempatkan server dekat wilayah yang banyak pemainnya (server regional) untuk mengurangi ping itu sendiri. - Kisaran angka: Dengan ping 150 ms dan interpolasi 100 ms, telegraph butuh sekitar 0,18 detik untuk muncul di layar Anda, dan input Anda butuh sekitar 0,1 detik untuk sampai di server. Ditambah reaksi manusia 0,25 detik, telegraph 0,5 detik hampir mustahil dihindari. - Di grafik: Hanya sebagian yang tinggi (Tingkat gagal dodge dan parry (per rentang ping)) - Yang diperiksa: Catat di log server waktu mulai dan akhir timing window, waktu input pemain tiba di server, dan RTT pemain itu, lalu lihat tingkat kegagalan per rentang ping (misalnya per 50 ms) - Cocok jika: Makin tinggi rentang ping, makin jelas tingkat kegagalannya naik, dan input yang gagal tiba sedikit setelah timing window berakhir (dalam batas RTT ditambah waktu interpolasi) - Tidak cocok jika: Tingkat kegagalan mirip di semua rentang ping: masalah tingkat kesulitan pola. Input tiba di dalam timing window tetapi tetap dianggap gagal: periksa kode penilaian atau validasi server - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015)](https://doi.org/10.3389/fnhum.2015.00131) · Frontiers · Rata-rata waktu reaksi sederhana sekitar 231 ms (213 ms setelah dikoreksi latensi perangkat); studi skala besar terbaru menunjukkan 233–400 ms - [Latency and Player Actions in Online Games (Communications of the ACM, 2006)](https://web.cs.wpi.edu/~claypool/papers/precision-deadline/final.pdf) · ACM · Makin presisi dan makin pendek tenggat suatu aksi, makin sensitif terhadap latensi (batasnya sekitar 100 ms untuk sudut pandang orang pertama, sekitar 500 ms untuk orang ketiga, dan sekitar 1.000 ms untuk sudut pandang omnipresent) - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Cara menjadwalkan event sesuai waktu server (ServerTime) agar semua klien memutarnya pada saat yang sama #### sy-no-lagcomp · Hit registration tanpa lag compensation · Server-now hit validation Jika server menilai serangan kena hanya dengan “posisi sekarang di server”, hasilnya tidak cocok dengan layar yang Anda lihat. - Mengapa → Akibatnya → Di layar: Lawan di layar Anda ada di posisi sekitar 0,2 detik di masa lalu (dengan ping 150 ms dan interpolasi 100 ms) → Server menilai dengan posisi sekarang, jadi lawan sudah tidak ada di tempat yang Anda bidik → Jelas kena tetapi meleset. Harus menembak mendahului target yang bergerak - Gejala: Aksi hilang / rollback / Faktor: Latensi - Siapa: Hanya saya / Kapan: Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: putar mundur waktu ke momen yang dilihat penyerang saat menilai serangan (lag compensation), atau ganti ke sistem target lock. Klien: saat menyerang, kirim juga momen yang dilihatnya (waktu server yang sedang diinterpolasi). - Di grafik: Hanya sebagian yang tinggi (Akurasi terhadap target bergerak (per rentang ping)) - Yang diperiksa: Catat di log keputusan server waktu serangan, posisi target di layar penyerang (nilai yang dikirim klien), posisi target di server yang dipakai untuk menilai, dan RTT penyerang. Di build development, jika posisi yang dipakai server digambar di atas layar klien, perbedaannya langsung terlihat - Cocok jika: Pada penilaian yang meleset, selisih kedua posisi kira-kira kecepatan target × (RTT penyerang + waktu interpolasi), dan makin tinggi ping, hanya akurasi terhadap target bergerak yang turun - Tidak cocok jika: Target yang diam pun meleset: masalah hitbox atau collision check. Sudah memakai rewind tetapi tetap meleset: periksa apakah klien salah memberi tahu waktu interpolasi ke server - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Tanpa lag compensation, pemain harus menembak mendahului sebesar latensi. Lag compensation: server memutar mundur waktu sebesar latensi dan waktu interpolasi lalu menilai - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Server memutar mundur ke state game yang dilihat pemain saat menembak untuk menilai apakah kena; klien mengirim juga waktu simulasi yang sedang dilihatnya - [Source SDK 2013: player_lagcompensation.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player_lagcompensation.cpp) · Valve · Waktu rewind di Source engine = latensi jaringan + waktu interpolasi #### sy-lagcomp-overreach · Lag compensation berlebihan · Excessive lag compensation Jika server memutar mundur waktu terlalu jauh demi penyerang, pihak yang diserang tetap kena walaupun sudah bersembunyi. - Mengapa → Akibatnya → Di layar: Server memutar mundur waktu jauh demi penyerang yang ping-nya tinggi → Di layar pihak yang diserang, ia sudah berlindung → “Kena dari balik tembok”, pemain dengan ping tinggi diuntungkan - Gejala: Aksi hilang / rollback / Faktor: Latensi - Siapa: Hanya saya, Wilayah/ISP tertentu / Kapan: Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pasang batas rewind (misalnya 200–250 ms), untuk penyerang dengan ping lebih tinggi dari itu putar mundur hanya sampai batas dan biarkan sisanya ditutup dengan menembak mendahului sendiri. - Di grafik: Hanya sebagian yang tinggi (Waktu rewind per serangan yang kena (per ping penyerang)) - Yang diperiksa: Catat di log keputusan server waktu rewind setiap serangan yang kena, RTT penyerang, dan waktu server saat pihak yang diserang masuk ke perlindungan. Di build development, gambar hitbox hasil rewind di layar (di Source engine: sv_showlagcompensation) - Cocok jika: Serangan kena dari laporan “kena dari balik tembok” terpusat pada penyerang dengan waktu rewind panjang, dan waktu rewind bertambah mengikuti ping penyerang tanpa batas - Tidak cocok jika: Kena dari balik tembok juga terjadi pada serangan dengan waktu rewind pendek: masalah hitbox atau collision check. Ping pihak yang diserang tinggi: gerakannya terlambat sampai di server - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Penilaian dengan rewind menganut prinsip “penembak didahulukan”. Ada juga usulan pengecualian “pihak yang diserang didahulukan”: jika pihak yang diserang sudah masuk ke tempat aman di layarnya sendiri, waktu tidak diputar mundur. - Sumber: - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Jika rewind tidak dibatasi, pemain dengan latensi 500 ms bisa mengenai lawan bahkan 0,5 detik setelah lawan berlindung, jadi diberi batas - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · Fenomena “kena dari balik sudut (shot around the corner)”, batas rewind di game FPS komersial, dan usulan teknik tanpa rewind jika pihak yang diserang sudah aman - [Source SDK 2013: player_lagcompensation.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player_lagcompensation.cpp) · Valve · Batas rewind Source engine sv_maxunlag default 1 detik (maksimum 1 detik); sv_showlagcompensation menampilkan hitbox hasil rewind di layar #### sy-client-auth · Otoritas klien · Client-authoritative results Jika setiap klien memutuskan hasilnya sendiri, layar Anda terasa responsif, tetapi hasilnya tidak cocok dengan layar pemain lain dan rentan terhadap cheat. - Mengapa → Akibatnya → Di layar: Klien menentukan posisi dan hit, server hanya meneruskan → Dua pemain sama-sama mengklaim mengenai lebih dulu, server tidak bisa memverifikasi → Lawan teleport atau menembus tembok, “saya sudah mengenai, tetapi tidak terhitung” - Gejala: Teleport, Aksi hilang / rollback / Faktor: Latensi - Siapa: Seluruh server / Kapan: Selalu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: verifikasi sendiri hasil penting (seperti hit), periksa kecepatan dan jarak gerakan. Klien: jika menerima hasil yang ditolak atau dikoreksi server, kembalikan ke nilai itu. - Di grafik: Selalu tinggi sejak awal (Jumlah laporan kecepatan gerak mustahil dan laporan hit yang saling bertentangan) - Yang diperiksa: Catat apa adanya di server posisi dan hit yang dilaporkan klien, hitung kecepatan gerak dari laporan posisi yang berurutan, lalu hitung laporan yang melewati kecepatan maksimum dan laporan dua pemain yang sama-sama mengklaim mengenai lebih dulu - Cocok jika: Server meneruskan laporan ke klien lain tanpa verifikasi, dan laporan kecepatan mustahil atau hit yang saling bertentangan muncul terus-menerus tanpa terkait patch atau wilayah - Tidak cocok jika: Server menghitung atau memverifikasi hasil sendiri: bukan penyebab ini. Teleport dalam kasus itu: periksa packet loss atau buffer interpolasi - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Cara klien melaporkan hasil hanya mungkin jika klien bisa dipercaya. Karena khawatir cheat, dipakai server otoritatif - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Model otoritas server: server sama sekali tidak memercayai state game yang dilihat klien - [Distributed authority topologies (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/distributed-authority.html) · Unity · Jika otoritas dibagi ke klien, cheating menjadi mudah dan tidak ada lagi satu simulasi tunggal yang mengatur semua objek #### sy-lockstep · Lockstep menunggu pemain paling lambat · Lockstep waits for the slowest peer Dalam arsitektur tempat semua pemain menghitung giliran yang sama bersama-sama, jika input satu orang terlambat, semua orang menunggu. - Mengapa → Akibatnya → Di layar: Setiap giliran baru bisa dihitung setelah input semua pemain terkumpul → Input satu orang tiba terlambat karena jitter atau packet loss → Semua orang tersendat sesaat bersamaan; jika parah, muncul jendela “Menunggu pemain” - Gejala: Freeze, Patah-patah, Input lag / Faktor: Jitter, Packet loss, Stall - Siapa: Lokasi/channel tertentu / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: atur input delay otomatis sesuai ping, keluarkan sementara hanya pemain yang terlambat agar pemain lain tetap berjalan tanpa menunggu. Klien: terapkan input delay yang ditentukan; jika P2P tanpa server relay, klien host juga menangani pengaturan input delay dan penanganan pemain yang terlambat. - Kisaran angka: Jika input delay diatur lebih pendek dari “waktu input sampai ke lawan + jitter”, game makin sering freeze. Waktu sampai itu kira-kira setengah ping jika saling kirim langsung, atau sekitar setengah dari jumlah ping kedua pemain jika lewat server relay. - Di grafik: Melonjak acak sesekali (Waktu tunggu giliran, latensi kedatangan input per pemain) - Yang diperiksa: Catat untuk setiap giliran waktu kedatangan input per pemain dan lama giliran berhenti menunggu, lalu lihat input siapa yang ditunggu pada giliran yang berhenti. Jika ada server relay, interval kedatangan paket input per pemain juga bisa dilihat dari packet capture di sisi server - Cocok jika: Pada setiap giliran yang berhenti, input dari satu orang yang sama tiba lebih lambat dari input delay, dan pada saat itu jitter atau packet loss orang tersebut melonjak - Tidak cocok jika: Semua input tiba tepat waktu tetapi game tetap berhenti: masalah waktu komputasi PC paling lambat atau pemrosesan server. Tidak berhenti, tetapi hasil di dua layar berbeda: hasil komputasi menyimpang (desync), jadi periksa kemungkinan perhitungan jalur tidak sama pada sinkronisasi perintah - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Frame n baru bisa dihitung setelah semua inputnya tiba, jadi jika ada yang terlambat game menunggu. Jika buffer playout delay yang menyerap jitter terlalu kecil, game tersendat sesaat - [1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond](https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond) · Game Developer · Perintah dijadwalkan untuk dijalankan dua giliran kemudian, dan panjang giliran diatur sesuai komputer paling lambat dan ping (Speed Control) - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · Input delay (incoming delay) dibuat sebesar latensi “A→server + server→B” agar semua pemain menerapkannya pada saat yang sama #### sy-rollback · Prediksi rollback netcode meleset · Rollback misprediction Input lawan diprediksi dan ditampilkan lebih dulu; jika prediksinya salah, game diputar mundur lalu dihitung ulang. Makin tinggi ping, makin lebar rentang rewind. - Mengapa → Akibatnya → Di layar: Lawan mengubah input (berbeda dari prediksi) → Input sebenarnya tiba terlambat sebesar setengah ping, jadi game diputar mundur sebesar itu lalu dihitung ulang → Gerakan lawan melompati beberapa frame atau tiba-tiba berubah - Gejala: Teleport / Faktor: Latensi, Jitter - Siapa: Hanya saya / Kapan: Saat melakukan aksi tertentu, Sesekali secara acak - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Campurkan input delay 1–3 frame untuk mempersempit rentang rewind, pasang batas rewind. - Kisaran angka: Dengan ping 100 ms (satu arah 50 ms), pada 60 fps sekitar 3 frame diputar mundur. Jika input delay 2 frame diterapkan, berkurang menjadi 1 frame. - Di grafik: Melonjak acak sesekali (Jumlah frame yang diputar mundur, RTT (ping)) - Yang diperiksa: Catat di klien setiap rewind: jumlah frame yang diputar mundur, RTT saat itu, pengaturan input delay, dan waktu yang dipakai untuk rewind dan menghitung ulang - Cocok jika: Pada saat gerakan lawan dilaporkan melompat, jumlah frame yang diputar mundur besar, rata-rata rentang rewind kira-kira (latensi satu arah − input delay) ÷ waktu per frame, dan makin tinggi ping makin besar - Tidak cocok jika: Rentang rewind kecil tetapi tetap terjadi patah-patah: masalah performa, yaitu perhitungan ulang melebihi waktu satu frame. Hasil di dua layar tetap berbeda setelah rewind: hasil komputasi menyimpang (desync) - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [GGPO Rollback Networking SDK](https://www.ggpo.net/) · GGPO · Input lawan diprediksi dan game berjalan lebih dulu; jika input sebenarnya berbeda, game dihitung ulang dari titik penyimpangan sampai sekarang - [8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2'](https://www.gdcvault.com/play/1025471/8-Frames-in-16ms-Rollback) · GDC · Rollback menghilangkan input delay lokal pada lockstep, dan memutar mundur serta menghitung ulang hingga 8 frame dalam 16 ms #### sy-no-timestamp · Event diputar begitu tiba tanpa timestamp · Events played on arrival (no timestamps) Jika event dari server diputar begitu diterima tanpa diberi waktu kejadian, jitter jaringan langsung membuat timing animasi tidak beraturan. - Mengapa → Akibatnya → Di layar: Event “mulai serang” atau “putar efek” dijalankan begitu tiba → Waktu tiba setiap paket berbeda sehingga intervalnya tidak beraturan → Gerakan serangan beruntun kadang cepat kadang lambat, timing pola boss berbeda setiap kali - Gejala: Patah-patah, Fast forward / Faktor: Jitter - Siapa: Hanya saya / Kapan: Selalu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: putar event sesuai waktu yang menyertainya (event terjadwal, buffer interpolasi). Server: sertakan waktu kejadian (waktu server) saat mengirim event. - Di grafik: Melonjak acak sesekali (Interval pemutaran event, interval kedatangan paket) - Yang diperiksa: Cocokkan waktu kejadian event di log server dengan waktu tiba dan waktu putar di log klien berdasarkan nomor event, lalu bandingkan intervalnya. Di build development, coba reproduksi dengan menambahkan jitter (nilai jitter di tc netem, latensi minimum dan maksimum di emulasi jaringan Unreal) - Cocok jika: Interval kejadian di server tetap, tetapi interval pemutaran persis mengikuti interval kedatangan yang tidak beraturan - Tidak cocok jika: Interval kedatangan rata tetapi pemutaran tidak beraturan: masalah frame di klien (lonjakan frame time). Interval kejadian di server sudah goyah sejak awal: tick melewati budget - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Setiap update diberi waktu server, dan objek digambar di posisi pada waktu target, yaitu waktu sekarang dikurangi waktu interpolasi (100 ms) - [Snapshot Interpolation](https://gafferongames.com/post/snapshot_interpolation/) · Gaffer On Games · Jika snapshot yang diterima langsung digambar, gerakan tersendat karena jitter; jika dikumpulkan sebentar di buffer interpolasi lalu digambar, gerakan mulus - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Contoh RPC yang membawa waktu pengiriman agar pihak penerima memutar efek sesuai waktu server - [tc-netem(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-netem.8.html) · iproute2 · Tools pengujian yang meniru jaringan nyata dengan menambahkan latensi dan jitter (delay TIME JITTER) serta packet loss (loss random PERCENT) ke paket keluar - [Using Network Emulation in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-network-emulation-in-unreal-engine) · Epic Games · Pengujian dengan memasukkan latensi minimum dan maksimum serta rasio packet loss ke server dan klien; di konsol diatur seperti NetEmulation.PktLag #### sy-double-tick · Menunggu tick dua kali · Double tick quantization Jika permintaan dikumpulkan sampai tick berikutnya untuk diproses, lalu hasilnya juga dikirim pada tick sesudahnya, interval tick bertambah dua kali. - Mengapa → Akibatnya → Di layar: Permintaan yang diterima diproses pada tick berikutnya → Hasil pemrosesan juga dikumpulkan dan dikirim pada tick pengiriman berikutnya → Ping koneksi rendah, tetapi respons selalu terlambat sekitar 1,5 kali interval tick. Pada server 10 tick, rata-rata 0,15 detik, terburuk 0,2 detik - Gejala: Input lag / Faktor: Latensi - Siapa: Seluruh server / Kapan: Selalu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Kirim respons langsung pada tick yang memprosesnya, naikkan tick rate, kirim respons penting secepatnya. - Kisaran angka: Pada server 10 tick, satu tick 100 ms, jadi waktu tunggu tick saja menambah rata-rata 150 ms dan paling buruk 200 ms. Jika hanya menunggu sekali, rata-ratanya 50 ms. - Di grafik: Selalu tinggi sejak awal (Waktu dari permintaan tiba sampai respons dikirim) - Yang diperiksa: Dari packet capture di sisi server, ukur jeda antara waktu paket permintaan tiba dan waktu paket responsnya keluar saat akun uji melakukan aksi yang sama berkali-kali (misalnya memakai item). Jika ada log server, periksa waktu permintaan tiba, nomor tick yang memprosesnya, dan waktu respons dikirim - Cocok jika: Waktu di dalam server rata-rata sekitar 1,5 kali interval tick, maksimum sekitar 2 kali, dan tetap tanpa terpengaruh RTT - Tidak cocok jika: Waktu di dalam server rata-rata sekitar setengah interval tick: menunggu tick hanya sekali. Lebih panjang dari interval tick dan tidak beraturan: periksa tick melewati budget - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Input yang tiba menunggu paling lama satu tick sampai batas tick, lalu butuh satu frame lagi untuk diterapkan dan dikirim. Makin tinggi tick rate, makin kecil waktunya - [VALORANT's 128-Tick Servers](https://www.riotgames.com/en/news/valorants-128-tick-servers) · Riot Games · Sebagian latensi berasal dari jaringan, sebagian dari tick rate server - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Perubahan NetworkVariable tidak langsung dikirim. Perubahan dikumpulkan lalu dikirim setiap network tick #### sy-strict-check · Validasi server yang terlalu ketat · Over-strict server validation Jika server memeriksa kecepatan gerak, cooldown, dan jangkauan terlalu ketat, input normal yang datang bertumpuk akibat jitter pun ikut ditolak. - Mengapa → Akibatnya → Di layar: Kriteria ketat seperti “jarak yang boleh ditempuh dalam satu tick” atau “toleransi cooldown 0 ms” → Jika dua perintah tiba bertumpuk dalam satu tick akibat jitter, server menganggapnya melanggar aturan → Rubber banding, skill ditolak padahal cooldown sudah selesai - Gejala: Rubber banding, Aksi hilang / rollback / Faktor: Jitter - Siapa: Hanya saya / Kapan: Sesekali secara acak, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Periksa dengan cara kuota kumulatif (token bucket), beri kelonggaran sebesar ping dan jitter. - Di grafik: Melonjak acak sesekali (Jumlah penolakan validasi dan koreksi posisi oleh server) - Yang diperiksa: Catat di log server alasan setiap penolakan validasi dan koreksi posisi, jumlah perintah pemain itu yang tiba pada tick tersebut, dan jeda kedatangan dari perintah sebelumnya - Cocok jika: Penolakan dan koreksi terpusat pada saat 2 perintah atau lebih tiba bertumpuk dalam satu tick, sedangkan jumlah gerakan dan pemakaian yang dijumlahkan per beberapa detik masih di dalam aturan - Tidak cocok jika: Dijumlahkan per beberapa detik pun tetap melanggar aturan: kemungkinan memang bergerak terlalu cepat atau cheat. Penolakan terpusat pada ISP tertentu dan malam hari: lebih mungkin false positive validasi yang terpusat pada pemain ISP tertentu - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Perintah yang datang bertumpuk diizinkan dengan budget pemrosesan perintah yang terakumulasi setiap tick (maksimum sv_maxusrcmdprocessticks 24 tick). Ada komentar pengembang bahwa pembatasan yang lebih ketat membuat pemain normal pun mengalami patah-patah - [RFC 2697: A Single Rate Three Color Marker](https://www.rfc-editor.org/rfc/rfc2697) · IETF · Token bucket: dinilai dengan kecepatan rata-rata (CIR) dan ukuran burst yang diizinkan sekaligus (CBS) #### sy-host · Arsitektur host (pembuat room) · Listen server / host advantage Jika PC salah satu pemain berperan sebagai server, koneksi dan performa PC orang itu menentukan rasa bermain semua pemain. - Mengapa → Akibatnya → Di layar: PC host berperan sebagai server (P2P, listen server) → Jika koneksi atau PC host lambat, dampaknya menyebar ke semua pemain, sementara ping host sendiri 0 → Hanya host yang diuntungkan; jika host keluar, semua pemain freeze atau disconnect - Gejala: Patah-patah, Freeze, Disconnect / Faktor: Latensi, Stall - Siapa: Lokasi/channel tertentu / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Server: beralih ke server dedicated yang menangani keputusan; sampai saat itu, pilih pemain dengan koneksi dan PC yang bagus sebagai host saat matchmaking. Klien: dukung perpindahan host (migration), ukur ping ke peserta lain, kecepatan upload, dan performa PC saat matchmaking lalu kirimkan hasilnya. - Tugas Tim Infrastruktur: Siapkan server fisik atau instance untuk server dedicated, tempatkan dekat wilayah yang banyak pemainnya. - Di grafik: Hanya sebagian yang tinggi (Jumlah laporan lag dan disconnect per host) - Yang diperiksa: Catat di log match kecepatan upload host, RTT tiap peserta ke host, frame time PC host, dan waktu host keluar, lalu kelompokkan laporan lag dan disconnect per host. Pemain juga bisa memastikannya dengan bermain lagi bersama orang yang sama sambil hanya mengganti host - Cocok jika: Lag dan disconnect terpusat di room host tertentu, semua peserta memburuk bersamaan saat kecepatan upload host rendah atau frame time-nya panjang, dan tanpa perpindahan host semua pemain disconnect begitu host keluar - Tidak cocok jika: Hanya peserta dari wilayah yang sama yang buruk tanpa peduli siapa host-nya: masalah koneksi atau rute. Arsitekturnya server dedicated: bukan penyebab ini - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Networking Overview for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-overview-for-unreal-engine) · Epic Games · Host listen server lebih diuntungkan dibanding klien lain, dan bebannya besar karena menangani server sekaligus rendering - [Distributed authority topologies (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/distributed-authority.html) · Unity · Jika session owner keluar, owner baru dipilih otomatis dari klien yang tersisa - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · Game P2P pun bisa dipandang sebagai arsitektur client-server tempat host merangkap peran server #### sy-optimistic-reject · Server menolak setelah feedback sisi klien · Client-side feedback rejected by server Jika server kemudian tidak mengakui hit atau skill yang sudah lebih dulu ditampilkan di layar Anda, hasil yang jelas-jelas Anda lihat menjadi tidak pernah terjadi. - Mengapa → Akibatnya → Di layar: Efek hit dan animasi skill diputar lebih dulu sebelum konfirmasi server (feedback sisi klien) → Server menimbang ulang jangkauan, posisi target, cooldown, dan resource, lalu menolak → Darah muncrat tetapi tidak ada damage, hanya animasi skill yang keluar tanpa efek, hanya cooldown yang berjalan - Gejala: Aksi hilang / rollback, Rubber banding / Faktor: Latensi - Siapa: Hanya saya, Fitur tertentu saja / Kapan: Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: tampilkan dari hasil server hanya bagian yang perlu dikonfirmasi, seperti angka damage, kematian, dan hadiah, periksa lebih dulu alasan penolakan yang umum, jika ditolak kembalikan cooldown dan resource lalu tampilkan alasannya. Server: beri kelonggaran sebesar ping pada pemeriksaan jangkauan dan posisi target, sertakan alasan di respons penolakan, kumpulkan rasio penolakan per skill sebagai metrik. - Kisaran angka: Respons penolakan datang terlambat sebesar ping + waktu tunggu tick setelah tombol ditekan. Dengan ping 150 ms, selama sekitar 0,2 detik pemain mengira serangannya kena. - Di grafik: Hanya sebagian yang tinggi (Rasio penolakan server per skill (per rentang ping)) - Yang diperiksa: Kumpulkan di server rasio penolakan per skill dan alasannya (jangkauan, posisi target, cooldown, resource), lalu bagi per rentang RTT pemain. Di klien, catat jumlah aksi dengan feedback sisi klien yang ditolak - Cocok jika: Penolakan terpusat pada skill tertentu dengan alasan jangkauan atau posisi target, dan makin tinggi ping makin tinggi rasio penolakan - Tidak cocok jika: Alasan penolakan adalah cooldown atau resource dan tidak terkait ping: periksa apakah nilai data (cooldown, biaya) di klien dan server berbeda. Tidak ada penolakan, tetapi animasi baru dimulai setelah respons server: lebih mungkin feedback baru tampil setelah server merespons (model request-response) - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Feedback sisi klien adalah cara terbaik untuk menutupi ping. Namun, makin berbeda informasi yang dipakai klien dan server untuk memutuskan (posisi lawan, sisa resource), makin sering penolakan terjadi. Jika rasio penolakan per skill dikumpulkan sebagai metrik, tempat keputusan yang tidak cocok lebih mudah ditemukan. - Sumber: - [Using Gameplay Abilities in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-gameplay-abilities-in-unreal-engine) · Epic Games · Ability Local Predicted langsung dijalankan di klien, tetapi keputusan akhirnya di server dan server bisa membatalkan hasilnya - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Tembakan senjata diprediksi di klien dan efeknya diputar lebih dulu, lalu kesalahan prediksi dikoreksi dengan hasil server #### sy-path-mismatch · Perhitungan jalur tidak sama pada sinkronisasi perintah · Command sync with divergent pathing Jika yang dipertukarkan hanya “pergi ke sini” dan jalurnya dihitung masing-masing oleh kedua pihak, perbedaan perhitungan sekecil apa pun membuat karakter atau monster berjalan lewat jalur lain lalu ditarik kembali ke posisinya. - Mengapa → Akibatnya → Di layar: Pada click-to-move dan monster yang mengejar, hanya tujuan yang dikirim dan jalurnya dihitung terpisah oleh klien → Bergerak lewat jalur yang berbeda dari server karena perbedaan data terrain, tabrakan dengan karakter lain, atau perbedaan urutan perhitungan → Monster berjalan menembus tembok lalu tiba-tiba berpindah tempat, karakter yang diklik berbelok seperti meluncur - Gejala: Teleport, Rubber banding / Faktor: Latensi - Siapa: Lokasi/channel tertentu, Hanya saya / Kapan: Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kirim juga titik-titik antara pada jalur (waypoint), samakan posisi secara berkala. Klien: konvergensikan penyimpangan secara halus, pakai data terrain yang sama dengan server. - Di grafik: Melonjak acak sesekali (Jumlah dan jarak koreksi posisi per objek) - Yang diperiksa: Catat per objek selisih antara posisi yang dikirim server dan posisi yang dihitung klien, lalu tandai koordinat tempat koreksi terjadi di peta. Jika hasil jalur atau posisi di kedua pihak diringkas menjadi checksum dan dibandingkan secara berkala, waktu mulai penyimpangan bisa ditemukan - Cocok jika: Koreksi terpusat pada terrain tertentu (ambang, lorong sempit, lereng) atau tempat ramai, dan berulang di tempat yang sama bahkan pada pemain yang metrik jaringannya normal - Tidak cocok jika: Koreksi hanya terjadi saat packet loss atau jitter melonjak, tanpa terkait tempat: masalah koneksi. Satu monster melompat di layar banyak orang sekaligus: periksa apakah otoritas kontrol monster ada di klien yang lambat - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Cara inilah salah satu alasan game click-to-move dan tab-target tidak terlalu sensitif terhadap ping. Sebagai gantinya, tidak ada jaminan hasil di kedua pihak sama, jadi mekanisme yang sesekali menyamakan posisi wajib ada. Perhitungan floating point bisa sedikit berbeda hasilnya tergantung jenis CPU, compiler, dan pengaturan optimasinya (termasuk perbedaan build debug dan release). Pada arsitektur yang hanya bertukar input dan mengasumsikan hasil perhitungan di kedua pihak sama persis, seperti lockstep atau rollback, perbedaan kecil ini bisa menumpuk sampai state game di dua layar terbelah (desync). - Sumber: - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Meski deterministik di mesin yang sama, hasil floating point bisa berbeda jika compiler, OS, atau CPU berbeda - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Jika state dikirim bersama input, kedua pihak bisa disamakan tanpa determinisme yang sempurna - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Saat ada packet loss atau dua karakter mencoba menuju posisi yang sama, simulasi server dan klien menyimpang sehingga perlu koreksi - [1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond](https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond) · Game Developer · Perbedaan yang sangat kecil membesar seiring waktu sehingga jalur worker sedikit demi sedikit menyimpang. World, objek, dan pathfinding dibandingkan dengan checksum untuk menemukan penyimpangan (out-of-sync) - [Floating Point Determinism](https://gafferongames.com/post/floating_point_determinism/) · Gaffer On Games · Kode floating point yang sama pun bisa memberi hasil berbeda tergantung compiler, arsitektur CPU, serta build debug atau release. Ada kasus CPU AMD dan Intel memberi nilai yang sedikit berbeda pada fungsi transendental - [/fp (Specify floating-point behavior)](https://learn.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior) · Microsoft · /fp:fast bisa mengubah urutan atau menggabungkan operasi floating point sehingga hasilnya berbeda dari pengaturan /fp lain, dan operasi yang digabung dengan FMA juga bisa berbeda dari hasil perkalian dan penjumlahan terpisah #### sy-low-send-rate · Laju pengiriman snapshot rendah · Low snapshot / update rate Jika server mengirim update posisi (snapshot) hanya beberapa kali per detik, buffer interpolasi harus dibuat lebih panjang sebanding, sehingga karakter lain terlihat di masa lalu yang lebih jauh. - Mengapa → Akibatnya → Di layar: Untuk menghemat volume kirim, update posisi hanya dikirim 5–10 kali per detik → Agar gerakan tergambar mulus, buffer harus 2 kali interval paket (200–400 ms); jika lebih pendek, kehilangan satu paket saja sudah membuat gerakan terhenti → Perubahan arah lawan terlihat terlambat dan tidak cocok dengan keputusan server. Jika buffer pendek, gerakan patah-patah dan teleport saat terjadi packet loss - Gejala: Patah-patah, Teleport, Aksi hilang / rollback / Faktor: Latensi, Packet loss - Siapa: Seluruh server / Kapan: Selalu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kirim lebih sering untuk target yang dekat atau sedang bertarung dan lebih jarang untuk target yang jauh, kirim hanya bagian yang berubah (kompresi delta) agar ukuran per kirim kecil lalu naikkan frekuensinya. Klien: sesuaikan panjang buffer interpolasi otomatis dengan interval paket. - Kisaran angka: Pada 10 kali per detik, interval paket 100 ms dan buffer 200 ms. Ditambah latensi satu arah 75 ms dari ping 150 ms, lawan terlihat sekitar 0,3 detik di masa lalu. - Di grafik: Selalu tinggi sejak awal (Interval kedatangan paket per klien, panjang buffer interpolasi) - Yang diperiksa: Dari packet capture di sisi server, saring hanya aliran ke satu pemain lalu periksa jumlah paket per detik dan interval antarpaket dengan I/O Graphs di Wireshark. Jika ada log di sisi game, periksa juga interval update per objek dan sisa buffer interpolasi klien (waktu tersisa sampai snapshot berikutnya datang) - Cocok jika: Update posisi selalu jarang, 5–10 kali per detik (interval 100–200 ms), dan buffer interpolasi diatur lebih dari 200 ms atau sisa buffer sering mencapai 0 - Tidak cocok jika: Update dikirim rapat tetapi hanya interval kedatangannya yang goyah: lebih mungkin jitter atau packet loss. Hanya objek jauh yang jarang diterima saat ramai: lebih mungkin budget pengiriman dan prioritas per koneksi - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Dengan update 10 kali per detik, interpolasi 200 ms tahan terhadap satu kali kehilangan. Default Half-Life 20 kali per detik dengan interpolasi 100 ms - [Snapshot Interpolation](https://gafferongames.com/post/snapshot_interpolation/) · Gaffer On Games · Pada 10 snapshot per detik, butuh latensi 350 ms agar tahan sampai dua kehilangan berturut-turut; pada 30 per detik cukup 150 ms - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Dengan akumulasi prioritas, objek penting dikirim lebih sering, dan sisanya dikirim bergiliran dalam batas bandwidth - [8.8. The “I/O Graphs” Window](https://www.wireshark.org/docs/wsug_html_chunked/ChStatIOGraphs.html) · Wireshark · Menggambar jumlah paket dan byte yang cocok dengan filter tampilan sebagai grafik per interval waktu ### Masalah yang hanya dialami sebagian pemain (24 penyebab) #### pt-slow-burst · Pemain yang lag terlihat fast forward di layar pemain lain · Laggy player seen by others (bursty inputs) Input dari pemain yang koneksinya buruk tiba di server secara tidak beraturan dan bertumpuk. Jika server menerapkan input sebanyak yang diterima di setiap tick, pemain lain melihat karakter itu tersendat sesaat, lalu maju beberapa langkah sekaligus. - Mengapa → Akibatnya → Di layar: Perintah gerak dari pemain yang lambat tiba dalam jumlah berubah-ubah: 0 di satu tick, 2–3 di tick lain → Server menerapkan semuanya sekaligus di tick saat perintah diterima, sehingga posisi karakter itu berubah seperti anak tangga → Di layar pemain lain, hanya karakter itu yang tersendat lalu bergerak sekaligus. Yang lain normal - Gejala: Fast forward, Teleport / Faktor: Jitter, Packet loss - Siapa: Hanya satu karakter yang terlihat aneh, Wilayah/ISP tertentu / Kapan: Selalu, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Terapkan perintah secara merata lewat buffer input per pemain, terapkan dengan interval aslinya berdasarkan nomor urut input, memperbesar buffer interpolasi di layar pemain lain saja tidak cukup (karena riwayat posisi di server sendiri sudah berbentuk anak tangga). - Tugas Pihak Eksternal: Imbau pemain yang lambat untuk memakai koneksi kabel (LAN) serta memeriksa Wi-Fi dan router. - Kisaran angka: Dengan jitter 80 ms, jumlah perintah per tick di server 20 tick (50 ms) berubah-ubah antara 0 dan 3. - Di grafik: Hanya sebagian yang tinggi (Jumlah perintah yang diterapkan per tick per pemain, jitter per pemain) - Yang diperiksa: Di packet capture sisi server, saring hanya paket dari pemain yang dilaporkan, hitung berapa paket yang tiba di setiap interval tick (misalnya 50 ms), lalu bandingkan dengan pemain lain. Jika ada log server, periksa jumlah perintah gerak yang diterapkan per tick dan nomor urut input per pemain - Cocok jika: Hanya paket pemain yang dilaporkan yang tiba bertumpuk, berganti-ganti antara 0 dan 2–3 per tick, jitter dan packet loss pemain itu tinggi, sedangkan paket pemain lain tiba merata. Berkurang jika pemain itu beralih ke koneksi kabel - Tidak cocok jika: Banyak karakter mengalami fast forward bersamaan: lebih mungkin tick server terlambat atau koneksi di sisi pemain yang melihat. Kedatangan dan penerapan merata, tetapi hanya karakter itu yang terlihat melompat: masalah interpolasi atau tampilan di sisi pemain yang melihat - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Dalam struktur otoritas server, ini perilaku normal. Lag satu pemain yang lambat hanya terlihat oleh orang lain sebagai “pemain itu bergerak aneh”, dan tidak memengaruhi kontrol pemain lain maupun gerakan monster. Namun, interaksi langsung dengan pemain itu (trade, mekanik party, hit registration di PvP) ikut terlambat. - Sumber: - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Server memasukkan input yang tiba ke antrean gerak per pemain sesuai urutan tick, dan mengisinya dengan prediksi jika kosong. Koreksi hanya terlihat oleh pemain itu, sedangkan pemain lain melihat gerakan yang mulus - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Paket yang dikirim 60 kali per detik pun tiba bertumpuk, misalnya 2 paket di satu frame dan 0 di frame berikutnya - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Perintah yang datang bertumpuk dibagi ke beberapa tick server untuk diproses (meter out) #### pt-event-server · Fast forward pada server yang memproses input begitu tiba · Event-driven processing of bursty inputs Pada server yang langsung memproses paket begitu tiba dan segera mengabarkan hasilnya, aksi pemain lambat yang datang bertumpuk langsung dijalankan berturut-turut. - Mengapa → Akibatnya → Di layar: Permintaan skill dan gerak dari pemain yang lambat tiba bertumpuk → Server langsung menjalankannya sesuai urutan begitu diterima, lalu segera memberi tahu semua pemain → Di mata pemain lain, pemain itu memakai beberapa skill dalam sekejap atau bergerak seperti dipercepat - Gejala: Fast forward / Faktor: Jitter - Siapa: Hanya satu karakter yang terlihat aneh / Kapan: Saat melakukan aksi tertentu, Selalu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: jalankan aksi sesuai interval waktu input yang tercantum pada aksi (waktu itu hanya diterima dalam batas toleransi), atau jangan tolak aksi yang datang bertumpuk dan jalankan satu per satu dengan jarak minimum (global cooldown), jangan memeriksa cooldown hanya dari waktu kedatangan (input normal jadi hilang). Klien: kirim aksi beserta waktu input-nya. - Di grafik: Hanya sebagian yang tinggi (Interval eksekusi aksi per pemain) - Yang diperiksa: Catat di log server waktu tiba, waktu eksekusi, dan waktu input yang dicantumkan klien (jika ada) untuk setiap aksi per pemain, lalu bandingkan interval eksekusi dengan interval input. Periksa juga interval kedatangan paket pemain itu di packet capture sisi server - Cocok jika: Interval input normal, tetapi interval tiba dan eksekusi di server menumpuk dalam beberapa ms, dan waktu terjadinya penumpukan itu bertepatan dengan waktu laporan fast forward dari pemain lain - Tidak cocok jika: Interval waktu input sudah menumpuk sejak awal: lebih mungkin klien atau macro. Interval eksekusi di server merata, tetapi hanya terlihat menumpuk di layar pemain lain: koneksi pemain yang melihat - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Server menghitung gerakan setiap kali menerima ServerMove dan menentukan selang waktu dari selisih timestamp dengan gerakan sebelumnya. Jika selisihnya dengan waktu server terlalu besar, gerakan itu dibuang - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Jika input diterapkan begitu tiba, intervalnya tidak merata meskipun dikirim pada 60 Hz, sehingga hasilnya tidak konsisten #### pt-input-buffer · Ukuran buffer input per pemain · Per-player server input buffer (jitter buffer) Jika server menampung sedikit input untuk setiap pemain lalu mengambilnya satu per tick, gerakan terlihat mulus di mata pemain lain, tetapi aksi pemain itu sendiri dikonfirmasi server lebih lambat sebesar itu. - Mengapa → Akibatnya → Di layar: Server menampung input pemain yang lambat di buffer, lalu menerapkannya satu per tick → Buffer kecil sering kosong, sehingga karakter itu berhenti di tempat atau server menggerakkannya dengan menebak dari input terakhir. Buffer besar membuat input pemain itu sendiri lambat dikonfirmasi → Buffer kecil: tersendat sesaat di mata pemain lain. Buffer besar: hasil skill pemain itu sendiri keluar terlambat (input lag) - Gejala: Patah-patah, Input lag / Faktor: Jitter - Siapa: Hanya satu karakter yang terlihat aneh, Hanya saya / Kapan: Selalu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: atur ukuran buffer secara otomatis sesuai kondisi koneksi tiap pemain, ambil dua input sekaligus untuk mengejar jika tertinggal, perintahkan klien pemain yang buffer-nya sering kosong untuk mengirim input lebih awal. Klien: kirim input sedikit lebih awal sesuai perintah server (penyesuaian waktu klien). - Kisaran angka: Berbeda di setiap game, tetapi umumnya sepanjang 1–3 tick. VALORANT, dengan server 128 tick, menjaga buffer server lebih pendek lagi, rata-rata setengah frame (sekitar 4 ms). Cara adaptif yang hanya memperbesar buffer untuk pemain dengan jitter besar cukup umum. - Di grafik: Hanya sebagian yang tinggi (Panjang buffer input dan jumlah buffer kosong per pemain) - Yang diperiksa: Catat di server, per pemain dan per tick, jumlah input yang tersisa di buffer input, berapa kali buffer kosong lalu diisi tebakan dari input terakhir, dan waktu dari input tiba sampai diterapkan - Cocok jika: Pemain dengan buffer kecil sering mengalami buffer kosong, dan pada saat itu karakternya berhenti sebentar di layar pemain lain. Pada pemain dengan buffer besar, waktu dari input sampai diterapkan bertambah sebesar panjang buffer - Tidak cocok jika: Buffer hampir tidak pernah kosong, tetapi patah-patah terlihat di layar pemain lain: masalah interpolasi di sisi pemain yang melihat. Buffer pendek, tetapi input lag tetap besar: lebih mungkin RTT itu sendiri atau menunggu tick dua kali - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Server menyesuaikan acuan waktu klien agar antrean input tetap sependek mungkin, tetapi cukup untuk meredam kedatangan yang tidak merata. Target buffering server rata-rata setengah frame - [NetworkTimeSystem class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkTimeSystem.html) · Unity · LocalBufferSec: lama server menampung pesan klien di buffer. Waktu klien dimajukan agar pesan tiba lebih awal di server - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Nilai buffer bisa diperbesar untuk pemain dengan koneksi buruk #### pt-isp-validation · False positive validasi yang terpusat pada pemain ISP tertentu · Anti-cheat / movement validation false positives on bad ISPs Input dari pemain yang koneksinya punya jitter besar tiba bertumpuk, sehingga sering terjaring pemeriksaan kecepatan dan cooldown di server. - Mengapa → Akibatnya → Di layar: Jitter koneksi di ISP atau wilayah tertentu membesar pada malam hari → Server menganggap input normal yang tiba bertumpuk sebagai pelanggaran kecepatan atau cooldown → Hanya pemain dari ISP itu yang mengalami rubber banding dan skill ditolak. Dalam kasus parah, server mengeluarkan mereka sehingga terjadi disconnect - Gejala: Rubber banding, Aksi hilang / rollback, Disconnect / Faktor: Jitter - Siapa: Wilayah/ISP tertentu, Hanya saya / Kapan: Jam sibuk malam hari, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Lakukan pemeriksaan dengan kuota kumulatif selama beberapa detik, longgarkan kriteria dengan mempertimbangkan kondisi koneksi (ping, jitter), sisipkan tahap peringatan sebelum pemain dikeluarkan paksa, kurangi false positive dari akarnya dengan membagi input yang datang bertumpuk secara merata per tick lewat buffer input per pemain. - Tugas Tim Infrastruktur: Periksa sebaran packet loss dan jitter per ISP menurut jam lalu bagikan ke Tim Pengembang Game, periksa rute di jalur ISP tersebut (mtr dua arah), ubah rute atau lakukan eskalasi ke ISP jika perlu. - Di grafik: Tinggi hanya di jam tertentu (Jumlah penolakan validasi dan kick per ISP (ASN), jitter per ISP) - Yang diperiksa: Tambahkan ISP (ASN) dari IP koneksi dan waktunya ke log penolakan validasi, koreksi, dan kick di server, lalu hitung per ISP dan per jam. Tim Infrastruktur menjalankan mtr dua arah ke ISP itu pada jam yang sama untuk memeriksa jitter dan packet loss - Cocok jika: Penolakan dan kick terpusat di ISP tertentu dan bertambah pada malam hari, jitter ISP itu ikut tinggi pada jam yang sama, dan total gerakan yang dijumlahkan per beberapa detik masih dalam aturan - Tidak cocok jika: Hanya akun tertentu yang berulang tanpa peduli ISP: kemungkinan memang cheat. Bertambah bersamaan di semua ISP: penyebab di sisi server berupa tick melewati budget (tick overrun), yang membuat tick tertunda dan perintah diterapkan bertumpuk - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Komentar pengembang: gerak terlalu cepat dicegah dengan budget perintah yang bertambah setiap tick, tetapi batasan yang lebih ketat membuat pemain normal pun mengalami patah-patah - [RFC 2697: A Single Rate Three Color Marker](https://www.rfc-editor.org/rfc/rfc2697) · IETF · Token bucket: penilaian berdasarkan laju rata-rata dan ukuran burst yang diizinkan - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Jika selisih timestamp klien dan server besar, gerakan dibuang atau ditangani dengan prosedur penyelesaian selisih waktu. Perhitungan memakai waktu server untuk mencegah speed hack #### pt-raid-member · Satu anggota party yang lambat dan mekanik boss · One laggy member in a synchronized mechanic Pada mekanik raid yang menuntut semua pemain bereaksi bersamaan di saat yang ditentukan, reaksi terlambat dari satu pemain yang lambat membuat seluruh party gagal. - Mengapa → Akibatnya → Di layar: Mekanik bersama seperti “semua menyebar bersamaan” atau “satu orang menekan tombol” → Pemain yang lambat melihat telegraph terlambat, dan input-nya juga tiba terlambat → Seluruh party tewas (wipe) gara-gara satu orang itu, dan anggota party lain merasa “ini gara-gara orang yang lag” - Gejala: Aksi hilang / rollback, Input lag / Faktor: Latensi - Siapa: Lokasi/channel tertentu, Hanya satu karakter yang terlihat aneh / Kapan: Saat banyak pemain berkumpul, Saat melakukan aksi tertentu - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: beri kelonggaran timing window mekanik sebesar ping, kirim telegraph lebih dulu dengan waktu server, desain agar kegagalan satu orang tidak berujung wipe. Klien: putar telegraph yang diterima sesuai waktu server. - Di grafik: Hanya sebagian yang tinggi (RTT per pemain yang memicu kegagalan mekanik) - Yang diperiksa: Catat di log mekanik server pemain yang memicu kegagalan, waktu tiba input-nya, timing window, serta RTT dan packet loss pemain itu - Cocok jika: Sebagian besar input yang memicu wipe berasal dari satu orang yang sama, RTT orang itu jelas lebih tinggi dari rata-rata party, dan input-nya tiba sesaat setelah timing window berakhir - Tidak cocok jika: Kegagalan terbagi merata di antara anggota party: lebih mungkin timing window pendek yang termakan ping. Input pemain yang lambat tiba di dalam timing window, tetapi tetap gagal: kode penilaian di server - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Cara menjadwalkan event sesuai waktu server agar semua pemain memutarnya di saat yang sama - [Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015)](https://doi.org/10.3389/fnhum.2015.00131) · Frontiers · Rata-rata waktu reaksi sederhana sekitar 231 ms #### pt-mob-control · Otoritas kontrol monster ada di klien yang lambat · Monster movement delegated to a player client Ada game yang menyerahkan perhitungan gerakan monster ke klien salah satu pemain di dekatnya untuk mengurangi beban server. Jika koneksi pemain itu buruk, monster itu bergerak aneh di layar semua pemain. - Mengapa → Akibatnya → Di layar: Server menyerahkan perhitungan gerakan monster ke klien pemain yang paling dekat (atau yang datang lebih dulu) → Laporan hasil dari pemain yang memegangnya tiba di server terlambat atau bertumpuk → Hanya monster itu yang tersendat lalu teleport di layar semua pemain di sekitarnya. Di layar pemain yang memegangnya, monster itu normal - Gejala: Teleport, Patah-patah, Fast forward / Faktor: Jitter, Packet loss - Siapa: Hanya satu karakter yang terlihat aneh, Lokasi/channel tertentu / Kapan: Selalu, Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Alihkan otoritas kontrol ke pemain dengan koneksi baik (berdasarkan ping dan packet loss), biarkan server segera mengambilnya kembali jika laporan terhenti, hitung langsung di server untuk monster penting seperti boss. - Di grafik: Hanya sebagian yang tinggi (Interval laporan posisi per monster (per klien yang memegang otoritas kontrol)) - Yang diperiksa: Catat di server, untuk setiap monster, klien yang memegang otoritas kontrol beserta interval laporan, RTT, dan packet loss klien itu. Interval kedatangan paket dari klien itu juga bisa diperiksa di packet capture sisi server - Cocok jika: Otoritas kontrol semua monster yang bergerak aneh dipegang satu orang yang sama, interval laporannya tidak beraturan atau terputus, dan langsung normal begitu otoritas dialihkan ke orang lain - Tidak cocok jika: Monster yang dihitung langsung oleh server juga melompat dengan cara yang sama: lebih mungkin tick server terlambat atau koneksi di sisi pemain yang melihat. Tetap melompat walaupun otoritas sudah dialihkan: lebih mungkin perhitungan jalur tidak sama pada sinkronisasi perintah - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Pemain yang memegang kontrol merasa semuanya normal, sehingga laporan yang masuk hanya berbunyi “monsternya aneh”. Jika semua pemain kecuali satu orang melihat monster yang sama bergerak aneh, periksa dulu siapa yang memegang otoritas kontrol monster itu. - Sumber: - [Authority (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/authority.html) · Unity · Pada model otoritas terdistribusi, setiap instance game (klien) memegang otoritas atas sebagian objek jaringan dan menghitung objek itu - [Distributed authority topologies (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/distributed-authority.html) · Unity · Jika otoritas dibagi ke klien, tidak ada satu simulasi tunggal dan game rentan terhadap cheating #### pt-heavy-char · Data karakter tertentu terlalu besar · One character with oversized data (inventory, mail, buffs) Karakter yang menumpuk ribuan item atau mail, atau punya daftar teman, daftar blokir, dan buff yang sangat banyak, harus memuat, menyimpan, dan mengabarkan ke sekitarnya data yang berkali-kali lipat lebih besar dari karakter lain. Lambatnya hanya terjadi pada karakter itu, tanpa peduli koneksinya. - Mengapa → Akibatnya → Di layar: Pada karakter yang sudah lama dimainkan, atau akibat hadiah event, ribuan item menumpuk di inventory dan mailbox → Setiap kali login, pindah area, atau menyimpan, data sebanyak itu dibaca dari dan ditulis ke DB, dan data equipment serta buff yang dikirim ke pemain di sekitar juga besar → Hanya karakter itu yang loading masuknya lama dan tersendat sesaat saat membuka inventory atau mail. Pada server yang menunggu penyimpanan di thread game, pemain di sekitarnya pun ikut terhenti sebentar - Gejala: Tidak bisa masuk / loading tanpa henti, Input lag, Freeze / Faktor: Stall - Siapa: Hanya saya, Fitur tertentu saja / Kapan: Tepat setelah login atau maintenance, Saat melakukan aksi tertentu, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur DB (Tim Infrastruktur) - Tugas Tim Pengembang Game: Tetapkan batas penyimpanan inventory dan mail serta pembersihan otomatis mail lama, muat hanya bagian yang dibutuhkan secara bertahap, simpan hanya bagian yang berubah di luar thread game. - Tugas Tim Infrastruktur: Cari query baca lambat yang berulang untuk karakter yang sama di slow query log lalu teruskan ke Tim Pengembang Game, sediakan daftar teratas karakter dengan jumlah baris item dan mail terbanyak. - Kisaran angka: Jika satu item adalah satu baris di DB, karakter dengan 5.000 item membaca 5.000 baris setiap kali login. Itu puluhan kali lipat karakter biasa. - Di grafik: Hanya sebagian yang tinggi (Waktu login dan penyimpanan per karakter, jumlah baris yang dibaca dari DB per karakter) - Yang diperiksa: Cari pembacaan dan penyimpanan lambat yang berulang dengan ID karakter yang sama di slow query log DB (MySQL slow query log, PostgreSQL log_min_duration_statement), lalu ambil daftar teratas jumlah baris per karakter di tabel item dan mail - Cocok jika: Query lambat terpusat pada beberapa ID karakter, jumlah baris item dan mail karakter itu puluhan kali rata-rata, dan tetap lambat walaupun login dari PC atau koneksi lain - Tidak cocok jika: Karakter lain di akun yang sama atau pemain lain ikut lambat: lebih mungkin server DB atau lock. Karakter itu normal di PC lain: lingkungan pemain - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Jika karakter yang sama tetap lambat walaupun login dari PC atau koneksi lain, sementara karakter lain di akun yang sama normal, curigai data karakternya. Karena itulah nama karakter wajib dicantumkan dalam laporan. - Sumber: - [Extraneous Fetching antipattern](https://learn.microsoft.com/en-us/azure/architecture/antipatterns/extraneous-fetching/) · Microsoft Azure · Mengambil data lebih dari yang dibutuhkan menambah beban I/O dan memperlambat respons - [PostgreSQL Documentation: Error Reporting and Logging](https://www.postgresql.org/docs/current/runtime-config-logging.html) · PostgreSQL · log_min_duration_statement: mencatat SQL yang berjalan melebihi durasi tertentu untuk melacak query lambat - [The Slow Query Log](https://dev.mysql.com/doc/refman/8.4/en/slow-query-log.html) · MySQL · Slow query log yang mencatat query yang melewati long_query_time #### pt-phase · Perbedaan channel, instance, atau phasing · Different channel / instance / phase Jika dua karakter berada di channel atau instance yang berbeda, atau di “phasing” berbeda yang menentukan NPC yang terlihat sesuai progres quest, keduanya melihat dunia yang berbeda. - Mengapa → Akibatnya → Di layar: Karakter kedua ditempatkan di channel lain, atau tahap quest-nya berbeda → Server tidak mengirim NPC tersebut ke karakter itu (normal) → NPC tidak ada hanya di salah satu sisi. Terlihat seperti bug, tetapi memang sesuai desain - Gejala: Tidak terlihat / objek hantu / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama, Hanya saya / Kapan: Selalu, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kirim informasi channel dan phasing ke klien, tambahkan “periksa channel dan tahap quest kedua karakter” ke checklist QA. Klien: tampilkan channel dan phasing di layar. - Di grafik: Hanya sebagian yang tinggi (Jumlah objek di sekitar per klien, channel dan phasing) - Yang diperiksa: Bandingkan nomor channel dan tahap progres quest terkait pada kedua karakter di layar game, lalu samakan channel dan tahapnya dan lihat lagi. Jika ada log pengiriman objek di server, periksa alasan NPC itu tidak dikirim ke karakter tersebut (channel atau phasing) - Cocok jika: Channel atau tahap quest kedua karakter berbeda, dan NPC terlihat setelah disamakan - Tidak cocok jika: Channel dan tahapnya sama, tetapi NPC tetap tidak ada di salah satu sisi: lebih mungkin pesan spawn yang tiba saat loading dibuang, data spawn hilang saat membanjir tepat setelah masuk zona, atau urutan pendaftaran jarak pandang kacau - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Periksa juga apakah progres quest disimpan per akun atau per karakter. Pada dua karakter di akun yang sama, progres salah satunya bisa mengubah phasing karakter yang lain. - Sumber: - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Server hanya mereplikasi actor yang relevan untuk setiap koneksi, dan tidak mengirim actor yang tidak relevan - [Object visibility (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/basics/object-visibility.html) · Unity · CheckObjectVisibility menentukan objek yang terlihat untuk setiap klien, dan objek yang disembunyikan tidak dikirim ke klien itu #### pt-loading-drop · Pesan spawn yang tiba saat loading dibuang · Spawn messages dropped before the client is ready Begitu karakter masuk zona, server mengirim pesan spawn NPC di sekitarnya, tetapi klien masih memuat map sehingga pesan itu dibuang. - Mengapa → Akibatnya → Di layar: Server mengirim pesan spawn objek di sekitar tepat setelah proses masuk selesai → Klien masih loading dan belum punya message handler, sehingga pesan itu dibuang → Server menganggap pesan sudah terkirim dan tidak mengirim ulang. NPC tidak terlihat sampai karakter keluar dari jarak pandang lalu kembali - Gejala: Tidak terlihat / objek hantu / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama, Hanya saya / Kapan: Tepat setelah login atau maintenance, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: kirim “siap” setelah loading selesai, atau simpan paket yang diterima selama loading lalu proses belakangan. Server: kirim informasi sekitar setelah menerima “siap”. - Kisaran angka: Jika dua klien di PC yang sama loading bersamaan, atau klien yang sedang loading berada di jendela latar belakang, CPU dan disk dipakai bersama dan pemrosesannya juga dibatasi, sehingga loading klien itu bisa beberapa kali lebih lama. Bug yang sama juga muncul jika proses masuk di server menjadi lebih cepat. - Di grafik: Hanya sebagian yang tinggi (Waktu loading per klien, jumlah pesan yang dibuang selama loading) - Yang diperiksa: Bandingkan jumlah dan jenis pesan yang diterima lalu dibuang klien selama loading serta waktu loading selesai dengan waktu server mengirim pesan spawn. Gejala mudah direproduksi dengan menjalankan loading dua klien bersamaan di PC yang sama, atau membiarkan klien yang sedang loading di jendela latar belakang - Cocok jika: Server sudah mengirim pesan spawn NPC yang tidak terlihat, pesan itu tiba sebelum loading selesai, dan jumlah pesan yang dibuang pada saat itu bertambah. Hanya terjadi di klien yang loading-nya lebih lama - Tidak cocok jika: Pesan spawn tiba setelah loading selesai, tetapi NPC tetap tidak terlihat: lebih mungkin snapshot baseline hilang atau kekeliruan akibat ID objek dipakai ulang. Server sama sekali tidak mengirim pesan untuk NPC itu: lebih mungkin urutan pendaftaran jarak pandang kacau atau perbedaan channel atau phasing - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [NetworkConfig class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkConfig.html) · Unity · SpawnTimeout: pesan untuk objek yang belum dibuat ditahan dulu, lalu dibuang jika objek itu tidak juga dibuat dalam batas waktu - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Actor yang tidak lagi relevan dihapus di klien, lalu direplikasi ulang dari awal saat kembali relevan #### pt-aoi-race · Urutan pendaftaran jarak pandang kacau · Interest-management race on enter/leave Jika saat karakter didaftarkan ke grid jarak pandang bertepatan dengan saat NPC berpindah sel grid, pesan spawn NPC itu bisa terlewat. - Mengapa → Akibatnya → Di layar: Proses masuk, pindah channel, atau teleportasi karakter bertepatan dengan gerakan NPC → NPC itu terlewat dari perhitungan “objek yang baru terlihat” → Hanya beberapa NPC tertentu yang tidak terlihat, atau NPC yang sudah pergi masih tertinggal - Gejala: Tidak terlihat / objek hantu / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama, Hanya saya / Kapan: Saat bergerak atau pindah area, Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Proses update jarak pandang di satu thread dengan satu urutan, sinkronkan ulang seluruh “daftar objek terlihat” secara berkala. - Di grafik: Melonjak acak sesekali (Jumlah selisih antara daftar objek terlihat di server dan daftar objek di klien) - Yang diperiksa: Catat di server pendaftaran ke grid jarak pandang, perpindahan sel objek, dan pengiriman pesan spawn/despawn beserta nomor tick-nya, lalu bandingkan secara berkala “daftar objek terlihat” di server dengan daftar yang dimiliki klien - Cocok jika: NPC yang terlewat berpindah sel di tick yang sama dengan proses masuk atau teleportasi karakter itu, dan tidak ada catatan pengiriman pesan spawn untuk NPC itu - Tidak cocok jika: Pesan spawn sudah dikirim, tetapi klien tidak menerimanya atau membuangnya: masalah pengiriman (data spawn hilang saat membanjir tepat setelah masuk zona, pesan spawn yang tiba saat loading dibuang). Selalu NPC yang sama yang terlewat: lebih mungkin perbedaan phasing atau opsi tampilan - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Replication Graph in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/replication-graph-in-unreal-engine) · Epic Games · MMORPG dan game sejenis membagi dunia game menjadi grid, menyimpan daftar actor per sel, dan mengirim data berdasarkan sel tempat klien berada - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Relevansi dinilai per koneksi, dan actor yang tidak lagi relevan dihapus di klien #### pt-baseline · Snapshot baseline hilang · Lost baseline for delta compression Pada server yang hanya mengirim “yang berubah sejak terakhir kali”, jika data lengkap yang dikirim sekali di awal (baseline) hilang, perubahan setelahnya tidak bisa diterapkan. - Mengapa → Akibatnya → Di layar: Paket data lengkap objek (baseline) hilang atau dibuang sebelum diproses → Klien tidak punya dasar untuk menerapkan perubahan berikutnya, sehingga mengabaikannya → Objek itu tidak terlihat, atau tiba-tiba muncul jauh kemudian - Gejala: Tidak terlihat / objek hantu, Teleport / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama, Hanya saya / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kirim ulang baseline sampai ACK (konfirmasi terima) diterima, buat data perubahan hanya terhadap baseline yang sudah dikonfirmasi diterima klien. Klien: kirim ACK untuk baseline setelah benar-benar diterapkan, minta ulang ke server jika menerima data perubahan untuk objek yang tidak dikenal. - Di grafik: Melonjak acak sesekali (Jumlah data perubahan yang diterima untuk objek yang tidak dikenal) - Yang diperiksa: Cocokkan jumlah dan ID objek dari data perubahan yang dibuang klien karena tidak ada baseline dengan waktu server mengirim baseline objek itu dan waktu ACK diterima. Reproduksi di lingkungan development dengan menambahkan packet loss (loss di tc netem, rasio packet loss di emulasi jaringan Unreal) - Cocok jika: Untuk objek yang tidak terlihat, server sudah mengirim baseline tetapi tidak menerima ACK, namun tetap terus mengirim data perubahan saja, dan klien membuang data perubahan itu - Tidak cocok jika: Baseline sudah mendapat ACK dan diterapkan di klien, tetapi objek tetap tidak terlihat: lebih mungkin pesan despawn hilang atau kekeliruan akibat ID objek dipakai ulang - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Snapshot Compression](https://gafferongames.com/post/snapshot_compression/) · Gaffer On Games · Data perubahan hanya boleh dibuat terhadap baseline yang sudah dikonfirmasi (ack) diterima pihak lain, dan state awal dikirim terpisah - [Quake III Arena source: code/server/sv_snapshot.c](https://raw.githubusercontent.com/id-Software/Quake-III-Arena/master/code/server/sv_snapshot.c) · id Software · Kompresi delta dilakukan terhadap snapshot yang sudah dikonfirmasi klien, dan jika baseline-nya terlalu lama, snapshot lengkap dikirim - [tc-netem(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-netem.8.html) · iproute2 · Tools pengujian yang meniru jaringan nyata dengan menambahkan latensi dan jitter (delay TIME JITTER) serta packet loss (loss random PERCENT) ke paket keluar - [Using Network Emulation in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-network-emulation-in-unreal-engine) · Epic Games · Pengujian dengan memasukkan latensi minimum dan maksimum serta rasio packet loss ke server dan klien; di konsol diatur seperti NetEmulation.PktLag #### pt-ghost · Pesan despawn hilang (objek hantu) · Missed despawn (ghost entity) Sebaliknya, jika pesan “sudah hilang” terlewat, NPC atau pemain yang sudah mati atau pergi tetap tertinggal hanya di layar Anda. - Mengapa → Akibatnya → Di layar: Pesan bahwa objek mati, pergi, atau keluar dari jarak pandang hilang atau urutannya kacau → Klien menganggap objek itu masih ada → Monster yang tidak bereaksi saat diserang atau pemain yang sudah keluar masih berdiri - Gejala: Tidak terlihat / objek hantu / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama, Hanya saya / Kapan: Sesekali secara acak, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kirim “daftar objek yang sedang terlihat” secara berkala. Klien: hapus objek yang tidak ada di daftar, sembunyikan objek yang seharusnya bergerak jika lama tidak mendapat update. - Di grafik: Melonjak acak sesekali (Jumlah objek yang hanya tersisa di klien) - Yang diperiksa: Bandingkan “daftar objek yang sedang terlihat” dari server dengan daftar objek di klien, hitung objek yang hanya ada di klien, lalu cocokkan log pengiriman dan penerimaan pesan despawn berdasarkan ID objek - Cocok jika: Server sudah mengirim pesan despawn untuk objek hantu itu, tetapi tidak ada catatan penerimaan di klien, atau pesan despawn tiba lebih dulu dari pesan spawn sehingga urutannya terbalik - Tidak cocok jika: Objek itu juga masih ada di daftar objek terlihat di server: server tidak membersihkan objek itu. Terjadi tepat setelah objek baru muncul dengan ID yang sama: lebih mungkin kekeliruan akibat ID objek dipakai ulang - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Actor dinamis yang tidak lagi relevan dihapus di klien - [Object visibility (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/basics/object-visibility.html) · Unity · Jika objek disembunyikan, klien itu melakukan despawn dan menghapus objek tersebut #### pt-spawn-burst · Data spawn hilang saat membanjir tepat setelah masuk zona · Initial spawn burst lost (unreliable channel, receive buffer, fragmentation) Begitu karakter masuk zona, server mengirim data spawn puluhan hingga ratusan objek di sekitarnya sekaligus. Jika data ini dikirim lewat channel unreliable, atau buffer terima meluap selama klien tidak bisa membaca socket karena sedang loading, sebagian data hilang dan tidak dikirim lagi. - Mengapa → Akibatnya → Di layar: Tepat setelah masuk, data spawn tiba bertumpuk dalam waktu singkat → Klien yang sedang loading terlambat membaca socket sehingga buffer terima OS meluap, atau paket UDP besar terfragmentasi sehingga satu fragmen saja yang hilang membuat seluruh paket hilang. Jika lewat channel unreliable, data itu juga tidak dikirim ulang → Beberapa NPC hilang hanya di klien yang loading-nya lambat. NPC terlihat setelah karakter keluar dari jarak pandang lalu kembali - Gejala: Tidak terlihat / objek hantu / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama, Hanya saya / Kapan: Tepat setelah login atau maintenance, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: kirim pesan spawn/despawn lewat channel reliable yang menjamin retransmisi, kirim data awal secara bertahap. Klien: terima paket di thread yang terpisah dari loading, perbesar ukuran buffer terima. - Kisaran angka: Nilai default buffer terima UDP di PC berbeda di setiap OS, tetapi biasanya puluhan hingga ratusan KB. Jika data masuk di kota yang ramai pemain lebih besar dari itu, buffer meluap meskipun socket hanya sebentar tidak terbaca karena loading. - Di grafik: Melonjak tepat setelah server dibuka (Volume data yang diterima tepat setelah masuk, jumlah pesan spawn yang terlewat) - Yang diperiksa: Bandingkan jumlah pesan spawn yang dikirim server tepat setelah masuk dengan jumlah yang diterima klien, lalu periksa channel yang dipakai (reliable atau unreliable). Di packet capture sisi server, periksa volume data yang dikirim ke pemain itu tepat setelah masuk dan paket yang terfragmentasi (filter Wireshark ip.flags.mf == 1 || ip.frag_offset > 0) - Cocok jika: Jumlah yang diterima lebih sedikit dari yang dikirim, yang terlewat berkumpul di rentang padat tepat setelah masuk, dan pesan dikirim lewat channel unreliable atau paket besar terfragmentasi. Lebih sering terjadi di klien yang loading-nya lambat - Tidak cocok jika: Jumlah yang dikirim dan diterima sama, tetapi objek tetap tidak terlihat: pesan dibuang setelah diterima (pesan spawn yang tiba saat loading dibuang) atau masalah perhitungan jarak pandang. Sering terlewat kapan saja, tidak hanya tepat setelah masuk: packet loss di koneksi - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Paket yang terfragmentasi hilang seluruhnya meskipun hanya satu fragmen yang hilang - [UDP vs. TCP](https://gafferongames.com/post/udp_vs_tcp/) · Gaffer On Games · UDP tidak menjamin pengiriman maupun urutan, sehingga paket yang hilang harus dideteksi dan dikirim ulang sendiri - [Socket.ReceiveBufferSize Property](https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.receivebuffersize) · Microsoft · Ukuran default buffer terima socket berbeda di setiap OS - [Display Filter Reference: Internet Protocol Version 4](https://www.wireshark.org/docs/dfref/i/ip.html) · Wireshark · Paket IP yang terfragmentasi disaring dengan ip.flags.mf (More fragments) dan ip.frag_offset (Fragment Offset) #### pt-id-reuse · Kekeliruan akibat ID objek dipakai ulang · Entity ID reused without a generation counter Jika server memakai ulang ID objek yang sama saat NPC yang mati muncul kembali, klien yang melewatkan pesan despawn di antaranya salah mengira NPC baru sebagai NPC lama. - Mengapa → Akibatnya → Di layar: NPC mati, lalu muncul lagi dengan ID objek yang sama → Klien yang melewatkan pesan despawn mengabaikan pesan spawn karena menganggapnya “objek yang sudah dikenal”, atau membiarkan objek itu tetap dalam keadaan mati → NPC tidak ada atau terlihat tergeletak hanya di salah satu layar, kadang juga terlihat dengan wujud NPC lain - Gejala: Tidak terlihat / objek hantu / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama, Hanya saya / Kapan: Sesekali secara acak, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: tambahkan nomor generasi ke ID objek untuk membedakan ID yang dipakai ulang. Klien: jika menerima pesan spawn untuk ID yang sudah dikenal, hapus objek lama lalu buat yang baru. - Di grafik: Melonjak acak sesekali (Jumlah pesan spawn untuk ID yang sudah dikenal) - Yang diperiksa: Catat di server waktu pembuatan dan penghapusan per ID objek (beserta nomor generasi jika ada), lalu hitung berapa kali klien menerima pesan spawn dengan ID yang sudah dikenal dan berapa penghapusan dan pembuatan ulang yang diproses sebagai “tidak berubah” saat update jarak pandang - Cocok jika: ID NPC yang tidak terlihat atau terlihat tergeletak sama dengan NPC yang baru saja mati, dan di antaranya klien itu tidak menerima pesan despawn, atau server tidak mengirim pesan despawn maupun pesan spawn - Tidak cocok jika: ID punya nomor generasi dan nomor itu juga dipakai saat membandingkan: bukan penyebab ini. Tidak terlihat walaupun ID-nya tidak dipakai ulang: lebih mungkin pesan spawn hilang - Sarana pemeriksaan: Log dan metrik server atau klien game - Pelajari lebih lanjut: Masalah ini juga bisa terjadi di sisi server. Jika daftar objek dalam jarak pandang dibandingkan hanya berdasarkan ID, NPC yang mati lalu spawn lagi dengan ID yang sama di antara dua update jarak pandang dianggap “tidak berubah”, sehingga pesan despawn maupun pesan spawn sama-sama tidak dikirim. Jika waktu update jarak pandang berbeda untuk setiap pemain, hanya klien yang update-nya jatuh di saat itu yang mengalaminya. - Sumber: - [Entity struct (Entities 1.3)](https://docs.unity3d.com/Packages/com.unity.entities@1.3/api/Unity.Entities.Entity.html) · Unity · Entity terdiri dari Index dan nomor generasi (Version), sehingga bisa dibedakan apakah Index yang dipakai ulang masih valid - [NetworkConfig class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkConfig.html) · Unity · RecycleNetworkIds dan NetworkIdRecycleDelay: ID jaringan dipakai ulang setelah dibiarkan kosong selama waktu tertentu #### pt-port-collision · Bentrok port UDP tetap · Two clients bound to the same local UDP port Jika klien dibuat untuk memakai port lokal yang tetap, klien kedua di PC yang sama tidak bisa memakai port itu atau harus berbagi paket dengan klien pertama. - Mengapa → Akibatnya → Di layar: Dua klien mencoba membuka port UDP lokal yang sama (dipaksa berbagi dengan opsi reuse) → OS hanya meneruskan paket masuk ke salah satu socket, atau tidak menjamin socket mana yang menerimanya. Router dan server juga melihat kedua klien sebagai alamat yang sama → Salah satu klien tidak menerima paket dunia game, sehingga NPC dan pemain lain tidak terlihat atau terjadi disconnect - Gejala: Tidak terlihat / objek hantu, Disconnect, Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama / Kapan: Tepat setelah login atau maintenance, Selalu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: biarkan OS memilih port lokal secara otomatis (bind ke port 0). Server: bedakan koneksi dengan token sesi yang diterbitkan untuk setiap koneksi. - Di grafik: Hanya sebagian yang tinggi (Jumlah paket yang diterima per klien) - Yang diperiksa: Di PC pemain, dengan kedua klien menyala, jalankan netstat -ano -p udp di Command Prompt untuk melihat port UDP lokal yang dibuka setiap proses game (PID). Di sisi server, periksa apakah kedua sesi masuk dari IP publik dan port yang sama - Cocok jika: Kedua proses game terikat ke port lokal yang sama, atau di server kedua sesi terlihat dari IP dan port yang sama. Normal jika hanya satu klien yang dinyalakan - Tidak cocok jika: Kedua klien memakai port lokal yang berbeda, tetapi salah satunya tetap bermasalah: lebih mungkin bug pembedaan sesi berdasarkan IP atau perangkat, atau pembatasan multi-klien - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE](https://learn.microsoft.com/en-us/windows/win32/winsock/using-so-reuseaddr-and-so-exclusiveaddruse) · Microsoft · Bind kedua ke port yang sama dengan SO_REUSEADDR merebut port itu, dan tidak bisa dipastikan socket mana yang menerima paket - [bind function (winsock.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-bind) · Microsoft · Jika bind dilakukan ke port 0, port unik dialokasikan dari rentang port dinamis (49152–65535) - [netstat](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netstat) · Microsoft · -a menampilkan port TCP dan UDP, -n alamat dalam bentuk angka, -o ID proses (PID), dan -p udp hanya UDP #### pt-session-key · Bug pembedaan sesi berdasarkan IP atau perangkat · Session keyed by IP or machine ID Jika server atau server perantara membedakan koneksi berdasarkan IP atau ID perangkat, dua klien di PC yang sama (IP publik yang sama) dikenali sebagai satu orang. - Mengapa → Akibatnya → Di layar: Tabel sesi dibuat dengan kunci IP atau IP + ID perangkat → Data klien kedua menimpa sesi pertama atau tercampur dengannya → Di satu klien NPC tidak terlihat, sementara klien lainnya disconnect atau menerima data orang lain - Gejala: Tidak terlihat / objek hantu, Disconnect / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama, Satu rumah, Wilayah/ISP tertentu / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: bedakan setiap koneksi dengan token sesi yang unik, baik di server maupun server perantara, dan pastikan ini diperbaiki karena beberapa orang di rumah yang sama (di balik NAT router) serta pengguna jaringan seluler yang satu IP-nya dibagi ISP ke banyak pelanggan (CGNAT) juga mengalami masalah yang sama. Klien: pakai token sesi yang diterima terpisah untuk setiap klien yang dijalankan. - Di grafik: Hanya sebagian yang tinggi (Jumlah sesi bersamaan dari IP publik yang sama, jumlah sesi yang tertimpa) - Yang diperiksa: Catat di log server dan server perantara kunci yang dipakai untuk mencari sesi, token sesi, serta IP dan port klien, lalu periksa apakah sesi yang ada berubah saat koneksi kedua dari IP yang sama masuk. Gejala bisa direproduksi dengan menyalakan dua klien berturut-turut di PC yang sama - Cocok jika: Begitu klien kedua terhubung, alamat atau data karakter sesi pertama berubah, dan disconnect yang sama juga terlihat pada pemain lain di balik router yang sama atau jaringan seluler (CGNAT) - Tidak cocok jika: Dua sesi dari IP yang sama tetap terpisah dengan token yang berbeda: bukan penyebab ini. Kedua proses memakai port lokal yang sama: bentrok port UDP tetap - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [RFC 6269: Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) · IETF · Jika banyak pelanggan berbagi satu alamat IPv4 lewat NAT atau CGN, pengguna tidak bisa dibedakan hanya dari IP #### pt-multiclient · Pembatasan multi-klien · Multi-client restriction policy Jika modul keamanan atau kebijakan server membatasi beberapa klien di satu PC, klien kedua tidak bisa dijalankan atau masuk, atau klien yang dinyalakan lebih dulu terputus. Sebagian game hanya memblokir fitur pada klien tambahan. - Mengapa → Akibatnya → Di layar: Modul keamanan mendeteksi klien yang dijalankan ganda, atau server membatasi koneksi tambahan dari perangkat yang sama → Menolak eksekusi atau koneksi kedua, atau memutus salah satunya. Dalam kasus yang jarang, hanya sebagian fitur klien tambahan yang diblokir → Tidak bisa masuk, atau salah satu klien disconnect. Pada game yang hanya memblokir fitur, NPC atau toko tidak terlihat di salah satu klien saja - Gejala: Tidak bisa masuk / loading tanpa henti, Tidak terlihat / objek hantu, Disconnect / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: jika memang dibatasi, tampilkan pesan pemberitahuan yang jelas, atur pengecualian untuk QA di modul keamanan. Server: atur juga pengecualian untuk QA pada pembatasan koneksi dari perangkat yang sama. - Di grafik: Hanya sebagian yang tinggi (Jumlah penolakan koneksi dan pemutusan per alasan (koneksi ganda)) - Yang diperiksa: Periksa pesan yang muncul saat klien kedua dinyalakan dan pesan pemutusan di klien yang dinyalakan lebih dulu. Periksa apakah log penolakan koneksi dan kick di server mencatat kode alasan seperti koneksi ganda atau perangkat yang sama - Cocok jika: Saat klien kedua dijalankan atau masuk, muncul pesan penolakan atau klien pertama terputus dengan alasan koneksi ganda, dan tidak ada masalah jika hanya satu klien yang dinyalakan - Tidak cocok jika: Kedua klien bisa masuk tanpa alasan penolakan atau pemutusan, tetapi NPC tidak terlihat di salah satunya: lebih mungkin bentrok port UDP tetap, bug pembedaan sesi berdasarkan IP atau perangkat, atau penyebab di sisi loading dan tampilan - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [CreateMutexW function (synchapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexw) · Microsoft · Jika named mutex sudah ada, ERROR_ALREADY_EXISTS dikembalikan, sehingga dipakai untuk mendeteksi eksekusi ganda dan membatasi agar hanya satu instance yang berjalan #### pt-background · Pemrosesan dibatasi di jendela latar belakang · Background window throttling Untuk klien di jendela latar belakang, game, engine, dan OS mengurangi frame dan pemrosesan. Paket yang diterima tidak sempat diproses tepat waktu, sehingga menumpuk atau meluap. - Mengapa → Akibatnya → Di layar: Batas frame latar belakang di opsi game atau driver grafis (misalnya, di driver NVIDIA bisa diatur 20–200 frame per detik), mode hemat daya, pengaturan engine yang menghentikan game di latar belakang. OS juga memprioritaskan CPU dan GPU untuk jendela di depan (foreground) → Jumlah paket yang diproses per frame berkurang sehingga antrean menumpuk, dan paket dibuang jika buffer terima meluap → Saat jendela dibawa ke depan, semuanya muncul sekaligus, atau sebagian NPC tetap tidak terlihat - Gejala: Tidak terlihat / objek hantu, Fast forward, Disconnect / Faktor: Stall, Packet loss - Siapa: Hanya satu klien di PC yang sama / Kapan: Setelah lama diam, Selalu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Terus terima data jaringan di thread terpisah dari game loop, jamin throughput minimum di latar belakang, aktifkan pengaturan engine untuk berjalan di latar belakang (runInBackground di Unity). - Tugas Pihak Eksternal: Imbau pemain untuk mematikan batas frame latar belakang di driver grafis dan mode hemat daya PC. - Kisaran angka: Di Unity, jika runInBackground dimatikan, game loop berhenti begitu jendela kehilangan fokus. Jika paket hanya diterima di loop itu, tidak ada paket yang diproses sama sekali selama itu. - Di grafik: Kosong lalu datang sekaligus (Interval frame klien, jumlah paket yang diproses per frame) - Yang diperiksa: Di PC yang sama, letakkan satu jendela di depan dan yang lain di belakang, lalu tukar posisinya dan bandingkan. Ukur interval frame kedua proses dengan PresentMon, dan jika ada log dari game, periksa status fokus jendela dan jumlah paket yang diproses per frame - Cocok jika: Interval frame melebar jauh hanya saat jendela di latar belakang (jika karena batas driver, intervalnya mendatar di nilai yang sesuai dengan frame rate yang diatur) atau pemrosesan berhenti, dan saat jendela ditukar, masalahnya ikut pindah ke klien lain - Tidak cocok jika: Terjadi sama persis di jendela depan: bukan karena pembatasan latar belakang. Selalu klien yang sama yang bermasalah tanpa peduli posisi jendela: lebih mungkin perbedaan opsi tampilan atau versi - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Application.runInBackground](https://docs.unity3d.com/ScriptReference/Application-runInBackground.html) · Unity · Nilai default runInBackground adalah false, dan dengan nilai itu aplikasi dijeda di latar belakang - [Manage 3D Settings (reference) — NVIDIA Control Panel Help](https://www.nvidia.com/content/Control-Panel-Help/vLatest/en-us/mergedProjects/nv3d/Manage_3D_Settings_(reference).htm) · NVIDIA · Background Application Max Frame Rate: membatasi frame maksimum game di latar belakang pada 20–200 frame per detik - [Priority Boosts](https://learn.microsoft.com/en-us/windows/win32/procthread/priority-boosts) · Microsoft · Windows menaikkan prioritas proses milik jendela foreground hingga setara atau lebih tinggi dari proses di latar belakang - [PresentMon README](https://raw.githubusercontent.com/GameTechDev/PresentMon/main/README.md) · Intel · Tool yang mengumpulkan frame time CPU, GPU, dan display per aplikasi untuk aplikasi grafis Windows #### pt-asset-lock · Bentrok akses bersamaan ke file cache dan aset · Shared cache / asset file lock conflicts Jika dua klien menulis ke folder cache yang sama secara bersamaan atau mengunci file, salah satu klien gagal memuat model dan tekstur NPC. - Mengapa → Akibatnya → Di layar: Dua klien menulis file cache atau patch di folder instalasi yang sama secara bersamaan → Pemuatan gagal karena file tidak bisa dikunci atau file yang baru setengah tertulis ikut terbaca → NPC yang punya name tag tetapi tanpa model karakter, atau NPC yang transparan - Gejala: Tidak terlihat / objek hantu / Faktor: Stall - Siapa: Hanya satu klien di PC yang sama / Kapan: Tepat setelah login atau maintenance, Saat bergerak atau pindah area - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Pisahkan folder cache per klien, coba lagi jika penguncian file gagal, tampilkan setidaknya model default jika pemuatan gagal. - Di grafik: Hanya sebagian yang tinggi (Jumlah kegagalan pemuatan aset per klien) - Yang diperiksa: Di PC pemain, saring hanya path folder instalasi dan cache game di Process Monitor, lalu periksa hasil operasi buka dan tulis file oleh kedua proses game. Jika ada log klien, cari kegagalan pemuatan aset dan kode error saat membuka file (ERROR_SHARING_VIOLATION) - Cocok jika: Pembukaan file untuk model yang tidak terlihat berakhir dengan sharing violation atau gagal kunci, dan pada saat yang sama klien lain sedang menulis file itu. Hilang jika hanya satu klien yang dinyalakan atau folder instalasi dan cache dipisah - Tidak cocok jika: Model yang sama tetap tidak terlihat walaupun hanya satu klien yang dinyalakan: lebih mungkin file rusak, atau versi klien atau data tidak cocok. File terbuka dengan baik tetapi tidak tergambar: lebih mungkin kekurangan memori atau VRAM - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Creating and Opening Files](https://learn.microsoft.com/en-us/windows/win32/fileio/creating-and-opening-files) · Microsoft · File yang dibuka tanpa share mode tidak bisa dibuka proses lain, dan muncul ERROR_SHARING_VIOLATION - [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) · Microsoft · Mencatat aktivitas file system, registry, dan proses secara real-time, dan bisa disaring berdasarkan path maupun semua kolom lainnya #### pt-vram · Streaming gagal akibat kekurangan memori atau VRAM · Memory / VRAM exhaustion Jika dua klien berbagi memori grafis, tidak ada ruang untuk memuat model dan tekstur yang baru dibutuhkan, sehingga sebagian tidak tergambar. - Mengapa → Akibatnya → Di layar: Dua klien berbagi VRAM dan RAM. OS juga bisa lebih dulu mengurangi jatah memori grafis untuk jendela di latar belakang → Engine tidak bisa memuat model dan tekstur baru, atau terus melepas lalu memuatnya lagi → NPC muncul terlambat, tampak buram, atau tidak terlihat, disertai patah-patah - Gejala: Tidak terlihat / objek hantu, Patah-patah / Faktor: Stall - Siapa: Hanya satu klien di PC yang sama / Kapan: Saat bergerak atau pindah area, Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Atur kualitas otomatis sesuai budget memori, tampilkan model pengganti jika pemuatan gagal. - Tugas Pihak Eksternal: Imbau pemain yang menyalakan dua klien sekaligus untuk menurunkan kualitas grafis atau memakai mode grafis rendah, informasikan spesifikasi VRAM dan RAM yang direkomendasikan. - Di grafik: Mendatar di batas (Pemakaian memori GPU khusus (dedicated) per proses) - Yang diperiksa: Di Task Manager PC pemain, tambahkan kolom Dedicated GPU memory di tab “Details”, lalu bandingkan total pemakaian kedua klien dengan kapasitas VRAM kartu grafis. Di sisi game, catat budget (Budget) dan pemakaian saat ini (CurrentUsage) yang dilaporkan QueryVideoMemoryInfo dari DXGI - Cocok jika: Total pemakaian kedua klien mendatar di dekat kapasitas VRAM, dan kegagalan pemuatan model dan tekstur terpusat pada saat pemakaian saat ini melewati budget. Hilang jika kualitas diturunkan atau hanya satu klien yang dinyalakan - Tidak cocok jika: VRAM masih longgar tetapi objek tetap tidak terlihat: lebih mungkin bentrok akses bersamaan ke file cache dan aset, atau perbedaan opsi tampilan - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Residency (Direct3D 12)](https://learn.microsoft.com/en-us/windows/win32/direct3d12/residency) · Microsoft · Budget memori video bisa turun drastis saat beralih ke aplikasi lain, dan jika budget terlampaui, aplikasi bisa terhenti atau pembuatan resource gagal. Jika bukan foreground, jatah yang sudah dipesan pun tidak dijamin - [GPUs in the task manager](https://devblogs.microsoft.com/directx/gpus-in-the-task-manager/) · Microsoft · Dengan menambahkan kolom di tab Details pada Task Manager, pemakaian memori GPU khusus (dedicated) dan bersama (shared) per proses bisa dilihat. Memori GPU khusus adalah VRAM kartu grafis - [DXGI_QUERY_VIDEO_MEMORY_INFO structure (dxgi1_4.h)](https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_4/ns-dxgi1_4-dxgi_query_video_memory_info) · Microsoft · Budget (budget memori video yang ditetapkan OS) dan CurrentUsage (pemakaian aplikasi saat ini). Jika pemakaian melewati budget, bisa terjadi patah-patah #### pt-display-option · Perbedaan opsi tampilan · Different display settings Jika opsi seperti batas jumlah karakter yang ditampilkan, penyembunyian name tag atau model NPC, dan mode grafis rendah berbeda di kedua klien, yang terlihat pun berbeda. - Mengapa → Akibatnya → Di layar: Hanya satu klien yang memakai “batas jumlah karakter di sekitar yang ditampilkan” atau mode grafis rendah → NPC yang jauh atau berprioritas rendah tidak digambar (normal) → NPC tidak ada hanya di salah satu sisi - Gejala: Tidak terlihat / objek hantu / Faktor: Stall - Siapa: Hanya satu klien di PC yang sama, Hanya saya / Kapan: Saat banyak pemain berkumpul, Selalu - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Beri tanda bahwa objek disembunyikan oleh opsi, pisahkan file pengaturan per klien agar tidak tercampur. - Di grafik: Hanya sebagian yang tinggi (Jumlah objek yang digambar di layar per klien) - Yang diperiksa: Bandingkan berdampingan pengaturan batas jumlah karakter yang ditampilkan, penyembunyian name tag dan model, serta mode grafis rendah di kedua klien, lalu samakan salah satunya dengan yang lain. Periksa juga apakah kedua klien memakai satu file pengaturan bersama dan saling menimpa - Cocok jika: Setelah pengaturannya disamakan, kedua layar menjadi sama, dan NPC yang tadinya tidak terlihat ternyata objek jauh di luar batas jumlah tampilan atau objek berprioritas rendah - Tidak cocok jika: Pengaturan sudah disamakan, tetapi NPC tetap tidak ada di salah satu sisi: lebih mungkin perbedaan channel atau phasing, atau pesan spawn hilang - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [Changing the Quantity of Characters Displayed On-screen (FINAL FANTASY XIV UI Guide)](https://na.finalfantasyxiv.com/uiguide/faq/faq-other/setting_ch_quantity.html) · Square Enix · Pengaturan batas tampilan (Character and Object Quantity) mengatur jumlah karakter dan objek yang digambar di layar #### pt-version · Versi klien atau data tidak cocok · Client version / data table mismatch Jika klien kedua berasal dari instalasi lain atau patch-nya belum selesai, klien itu tidak mengenal ID NPC baru yang dikirim server dan diam-diam mengabaikannya. - Mengapa → Akibatnya → Di layar: Instalasi di folder lain, atau klien yang dijalankan saat patch masih berlangsung → ID NPC atau ID model yang tidak dikenal dilewati → Hanya NPC yang baru ditambahkan yang tidak terlihat di salah satu sisi - Gejala: Tidak terlihat / objek hantu / Faktor: Packet loss - Siapa: Hanya satu klien di PC yang sama / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Klien: kirim versi data saat masuk, catat ke log dan tampilkan pengganti jika menerima ID yang tidak dikenal. Server: periksa versi data saat masuk, tolak koneksi dan arahkan pemain untuk patch jika berbeda. - Di grafik: Hanya sebagian yang tinggi (Jumlah ID tidak dikenal yang diterima per versi klien) - Yang diperiksa: Bandingkan path file executable kedua klien serta versi klien dan versi data yang tampil di layar atau log. Di sisi game, catat versi data yang dikirim saat masuk dan berapa kali ID NPC atau model yang tidak dikenal diterima lalu dilewati - Cocok jika: Versi atau folder instalasi kedua klien berbeda, NPC yang tidak terlihat adalah NPC yang ditambahkan lewat patch terbaru, dan NPC itu terlihat di instalasi yang patch-nya sudah selesai - Tidak cocok jika: Versi dan folder instalasi sama, tetapi NPC tidak ada di salah satu sisi: lebih mungkin perbedaan channel atau phasing, atau penyebab di sisi loading atau pengiriman - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [NetworkConfig class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkConfig.html) · Unity · Jika ProtocolVersion berbeda, keduanya tidak saling berkomunikasi, dan ForceSamePrefabs memeriksa perbedaan daftar prefab saat koneksi dibuat #### pt-priority · Budget pengiriman dan prioritas per koneksi · Per-connection bandwidth budget and priority Jika server membatasi volume kirim per koneksi dan mengirim objek yang dekat lebih dulu, koneksi dengan batas rendah menerima NPC yang jauh dengan terlambat atau tidak menerimanya sama sekali. - Mengapa → Akibatnya → Di layar: Di tempat ramai, server mengirim data sesuai urutan kepentingan dalam batas volume kirim per koneksi → Koneksi dengan estimasi bandwidth rendah (misalnya, klien di jendela latar belakang yang lambat mengirim ACK) terus menunda objek di urutan belakang → NPC yang jauh terlihat terlambat atau tidak terlihat hanya di salah satu sisi - Gejala: Tidak terlihat / objek hantu, Input lag / Faktor: Latensi - Siapa: Hanya satu klien di PC yang sama, Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: naikkan prioritas objek yang tertunda seiring waktu (mencegah starvation), jamin interval update minimum. Klien: tetap kirim ACK tepat waktu di latar belakang agar estimasi bandwidth tidak turun. - Di grafik: Naik mengikuti beban (Jumlah objek yang ditunda per koneksi, volume kirim per koneksi) - Yang diperiksa: Catat di server, per koneksi, byte yang dikirim per tick, batas kirim (estimasi bandwidth), jumlah objek yang tertunda karena tidak sempat dikirim, dan waktu sejak pengiriman terakhir per objek. Di Unreal, ukuran paket per koneksi dan objek replikasi di dalamnya bisa dilihat di Networking Insights - Cocok jika: NPC yang tidak terlihat adalah objek yang lama tertunda di koneksi itu, batas koneksi itu lebih rendah dari koneksi lain, dan makin ramai pemain, makin banyak objek yang tertunda - Tidak cocok jika: Tidak ada objek yang tertunda dan NPC itu juga dikirim tepat waktu: masalahnya di tahap setelah pengiriman (buffer terima, loading, opsi tampilan). Semua koneksi menempel di batas: masalah volume kirim seluruh server atau desain jarak pandang - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Saat bandwidth jenuh, actor yang direplikasi dipilih berdasarkan prioritas (jarak, arah pandang, waktu sejak replikasi terakhir). Tidak semua actor direplikasi setiap kali - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Akumulasi prioritas: objek yang tidak masuk ke paket kali ini masuk lebih dulu ke paket berikutnya, dan batas bandwidth disesuaikan secara real-time - [Networking Insights in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-insights-in-unreal-engine) · Epic Games · Menampilkan ukuran paket yang dikirim dan diterima per koneksi serta objek dan properti replikasi di dalamnya #### pt-clock-hold · Objek ditahan akibat kesalahan estimasi jam · Clock estimate error holds or discards entities Jika waktu server yang diperkirakan klien salah, data objek yang baru tiba ditahan karena dianggap “masih di masa depan”, atau dibuang karena dianggap “sudah terlalu lama”. - Mengapa → Akibatnya → Di layar: Perkiraan waktu server di salah satu klien meleset jauh (diukur saat loading, atau setelah bangun dari mode hemat daya) → Waktu acuan interpolasi tidak cocok dengan waktu data objek → Objek muncul terlambat atau terlihat diam di tempat - Gejala: Tidak terlihat / objek hantu, Patah-patah / Faktor: Latensi - Siapa: Hanya satu klien di PC yang sama / Kapan: Setelah lama diam, Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Ulangi sinkronisasi waktu secara berkala dan reset segera jika selisihnya besar, jangan pakai nilai yang diukur saat loading atau tepat setelah bangun dari mode hemat daya. - Di grafik: Hanya sebagian yang tinggi (Error perkiraan waktu server per klien) - Yang diperiksa: Catat di klien perkiraan waktu server, RTT, saat sinkronisasi waktu diulang, dan berapa kali data objek ditahan atau dibuang. Coba reproduksi tepat setelah loading atau tepat setelah bangun dari mode hemat daya - Cocok jika: Hanya di klien yang bermasalah error perkiraannya melewati ambang reset (di Unity hardResetThresholdSec, default 0,2 detik), ada catatan data objek ditahan karena dianggap masa depan atau dibuang karena dianggap masa lalu, dan langsung normal setelah sinkronisasi waktu diulang - Tidak cocok jika: Error perkiraannya kecil, tetapi objek tetap muncul terlambat: lebih mungkin budget pengiriman dan prioritas per koneksi, atau penyebab di sisi loading - Sarana pemeriksaan: Log dan metrik server atau klien game - Sumber: - [NetworkTimeSystem class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkTimeSystem.html) · Unity · Jika selisih waktu melewati hardResetThresholdSec (default 0,2 detik), waktu langsung dipaksa disamakan. Di luar itu, waktu disesuaikan sedikit demi sedikit lebih cepat atau lebih lambat dengan adjustmentRatio - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · LocalTime berjalan lebih dulu dari server, sedangkan ServerTime tertinggal. Pesan yang tiba terlambat bisa punya waktu tunggu negatif ### Akar penyebab retransmisi TCP (20 penyebab) #### rt-wireless · Packet loss di jalur nirkabel · Wi-Fi / cellular link loss Wi-Fi dan jaringan seluler mengirim ulang paket beberapa kali di jalur nirkabel, dan jika tetap gagal, paket dibuang. Paket yang dibuang itu baru dikirim ulang oleh TCP jauh kemudian. - Mengapa → Akibatnya → Di layar: Sinyal lemah atau interferensi berat membuat pengiriman di jalur nirkabel gagal berturut-turut → Paket dibuang setelah melewati batas percobaan ulang perangkat nirkabel (biasanya beberapa hingga belasan kali) → Freeze selama menunggu retransmisi TCP, lalu fast forward karena paket berikutnya yang tertahan di buffer terima diteruskan sekaligus - Gejala: Freeze, Fast forward, Teleport / Faktor: Packet loss, Jitter - Siapa: Hanya saya, Satu rumah / Kapan: Sesekali secara acak, Saat bergerak atau pindah area - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: aktifkan TCP_NODELAY (jika Nagle aktif, RACK tidak punya paket susulan untuk mendeteksi packet loss), kirim hanya update state terbaru selama koneksi tertahan oleh retransmisi (batasi jumlah yang menumpuk di kernel dengan TCP_NOTSENT_LOWAT). Klien: aktifkan TCP_NODELAY (packet loss di arah input pemain dipulihkan oleh OS klien), tampilkan status jaringan di layar saat packet loss menumpuk atau ping melonjak. - Tugas Tim Infrastruktur: Percepat pemulihan packet loss dengan RACK-TLP (server tidak bisa mencegah packet loss nirkabel dan paling jauh hanya bisa mempercepat pemulihan), pastikan nilai default Linux terbaru net.ipv4.tcp_recovery=1 (RACK) dan net.ipv4.tcp_early_retrans=3 (TLP) tidak diubah. - Tugas Pihak Eksternal: Imbau pemain untuk memakai koneksi kabel atau Wi-Fi 5 GHz/6 GHz, serta memindahkan router atau mengganti channel-nya. - Kisaran angka: Dengan packet loss nirkabel 1%, 1 dari 100 paket game hilang. Jika menerima 10 paket per detik, game tersendat sesaat kira-kira sekali setiap 10 detik. Tanpa RACK-TLP, setiap kejadian membuat game berhenti selama RTO (ping + 200 ms atau lebih). - Di grafik: Hanya sebagian yang tinggi (Tingkat retransmisi per koneksi, RTT (ping) per koneksi) - Yang diperiksa: Dari PC pemain, kirim ping ratusan kali ke alamat router (gateway) dan ke server game, bandingkan packet loss dan rentang latensinya, lalu ukur lagi setelah beralih ke kabel atau data seluler. Di server, periksa retrans dan rtt (rata-rata/deviasi) pada koneksi pemain itu dengan ss -ti - Cocok jika: Ping ke router saja sudah menunjukkan packet loss atau latensi yang naik turun, dan masalah hilang setelah beralih ke kabel. Dari sisi server, hanya koneksi pemain itu yang retrans dan deviasi RTT-nya besar - Tidak cocok jika: Bersih sampai router, packet loss baru mulai setelahnya: mengarah ke ISP atau rute (“Antrean bottleneck meluap”, “Perubahan rute dan jalur ECMP bermasalah”). Beberapa pemain di ISP yang sama memburuk bersamaan: periksa jalur ISP lebih dulu - Sarana pemeriksaan: Lingkungan pemain sendiri - Pelajari lebih lanjut: Percobaan ulang di perangkat nirkabel menimbulkan jitter (beberapa ms setiap percobaan), dan hanya paket yang melewati batas percobaan ulang yang menjadi packet loss. Karena itu, makin buruk kualitas nirkabel, gejalanya makin berat dengan urutan “jitter → sesekali freeze → sering freeze”. Saat roaming, yaitu berpindah dari satu router (AP) ke AP lain, paket bisa hilang berturut-turut selama puluhan ms hingga beberapa detik. Jaringan seluler banyak melakukan retransmisi di jalur ke BTS, sehingga masalahnya lebih sering muncul sebagai lonjakan latensi ratusan ms daripada sebagai packet loss. - Kasus nyata: ffxiv-2021 - Sumber: - [net/wireless/core.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/wireless/core.c?h=v6.12) · Linux kernel · Batas percobaan ulang default di stack nirkabel Linux: 7 kali untuk frame pendek, 4 kali untuk frame panjang (dot11ShortRetryLimit, dot11LongRetryLimit) - [RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks](https://www.rfc-editor.org/rfc/rfc3481) · IETF · Berkat retransmisi di lapisan link, packet loss IP di jaringan seluler kecil, tetapi pemulihan itu muncul sebagai jitter dan lonjakan latensi - [Wi-Fi roaming support in Apple devices](https://support.apple.com/guide/deployment/wi-fi-roaming-support-dep98f116c0f/web) · Apple · Saat berpindah AP, data tidak bisa dikirim sampai autentikasi ke AP baru selesai, dan di lingkungan 802.1X prosesnya bisa memakan beberapa detik - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · Definisi RACK (deteksi packet loss berbasis waktu) dan TLP (retransmisi paket terakhir) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Default tcp_recovery 0x1 (RACK), default tcp_early_retrans 3 (TLP aktif), TCP_NOTSENT_LOWAT dan tcp_notsent_lowat membatasi jumlah data yang belum dikirim - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_NODELAY mematikan algoritma Nagle sehingga data kecil pun langsung dikirim - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · Nilai minimum RTO: TCP_RTO_MIN = 200 ms - [misc/ss.c](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/misc/ss.c?h=v6.12.0) · iproute2 · ss -ti menampilkan retrans:jumlah yang sedang dikirim ulang/jumlah retransmisi kumulatif dan rtt:RTT/deviasi RTT (rttvar) #### rt-queue-drop · Antrean bottleneck meluap (packet loss akibat kongesti) · Tail drop at a congested bottleneck Saat antrean di titik tersempit penuh, misalnya router rumah, jalur penghubung antar-ISP, atau jalur data center, paket yang baru datang dibuang. - Mengapa → Akibatnya → Di layar: Bottleneck penuh oleh trafik video, unduhan, dan pengguna lain → Selama antrean penuh, paket yang baru datang dibuang berturut-turut (tail drop). Paket yang lolos pun menunggu di ujung antrean yang penuh → Banyak paket hilang sekaligus sehingga terjadi freeze panjang lalu fast forward, sering pada malam hari - Gejala: Freeze, Fast forward, Rubber banding / Faktor: Packet loss, Latensi - Siapa: Satu rumah, Wilayah/ISP tertentu, Seluruh server / Kapan: Jam sibuk malam hari, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pihak Eksternal (Pihak Eksternal), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Tampilkan status jaringan di layar saat packet loss menumpuk atau ping melonjak (sertakan petunjuk bahwa mungkin ada transfer besar di koneksi yang sama). - Tugas Tim Infrastruktur: Sediakan kapasitas cadangan di jalur data center, periksa counter drop antrean (output drops) di jalur dan port switch kami, alihkan trafik lewat jalur lain atau peering jika jalur ISP padat. - Tugas Pihak Eksternal: Imbau pemain untuk memakai SQM (fq_codel, CAKE) dan ECN di router (agar pengirim menurunkan laju sebelum antrean meluap), minta ISP menambah kapasitas di bottleneck. - Kisaran angka: Saat antrean meluap, sebagian besar paket yang masuk selama puluhan ms bisa hilang sekaligus. Paket mudah hilang berturut-turut, bahkan paket retransmisinya pun ikut hilang, sehingga pemulihan sering harus menunggu RTO. - Di grafik: Tinggi hanya di jam tertentu (Tingkat retransmisi, RTT (ping)) - Yang diperiksa: Pilah tingkat retransmisi server (kenaikan TcpRetransSegs ÷ TcpOutSegs dari nstat yang dijalankan setiap 1 menit) dan RTT per koneksi menurut wilayah, ISP, dan jam, lalu periksa juga drop output (ifOutDiscards) di jalur dan port switch kami. Jalankan mtr ke wilayah bermasalah pada jam sibuk dan jam sepi, lalu bandingkan - Cocok jika: Tingkat retransmisi naik hanya pada jam sibuk malam, dan RTT naik lebih dulu tepat sebelum packet loss (tanda antrean terisi). Di mtr, hanya pada jam sibuk packet loss dan latensi bertambah bersamaan mulai dari satu hop sampai ujung - Tidak cocok jika: RTT tidak naik sebelum packet loss: lebih mungkin “Policer membuang trafik berlebih”. Packet loss selalu mirip di jam berapa pun: lebih mungkin “Error fisik” atau “Perubahan rute dan jalur ECMP bermasalah” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Kasus nyata: riot-direct-2015 - Sumber: - [RFC 7567: IETF Recommendations Regarding Active Queue Management](https://www.rfc-editor.org/rfc/rfc7567) · IETF · Penjelasan bahwa tail drop membuat antrean penuh dalam waktu lama sehingga latensi bertambah dan packet loss terjadi beruntun, serta rekomendasi AQM - [RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm](https://www.rfc-editor.org/rfc/rfc8290) · IETF · fq_codel: antrean per flow dan AQM menjaga antrean tetap pendek sehingga bufferbloat berkurang - [RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP](https://www.rfc-editor.org/rfc/rfc3168) · IETF · ECN: memberi tahu adanya kongesti dengan tanda di header IP tanpa membuang paket - [Smart Queue Management](https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/) · Bufferbloat.net · SQM: cara yang menggabungkan penjadwalan per flow, pengelolaan panjang antrean (AQM), dan shaping - [Cake](https://www.bufferbloat.net/projects/codel/wiki/Cake/) · Bufferbloat.net · CAKE: SQM untuk router yang menggabungkan shaper dan pengelolaan antrean ala fq_codel - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · TcpRetransSegs dan TcpOutSegs yang ditampilkan nstat (RetransSegs dan OutSegs pada bagian Tcp) - [nstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/nstat.8.html) · iproute2 · Secara default, nstat menampilkan kenaikan sejak eksekusi sebelumnya - [RFC 2863: The Interfaces Group MIB](https://www.rfc-editor.org/rfc/rfc2863) · IETF · ifOutDiscards: jumlah paket keluar yang dibuang tanpa dikirim walaupun tidak ada error, misalnya untuk mengosongkan ruang buffer - [An Internet-Wide Analysis of Traffic Policing](https://research.google/pubs/an-internet-wide-analysis-of-traffic-policing/) · Google · Pembedaan: pada antrean yang meluap, waktu antre dan RTT naik lebih dulu sebelum packet loss, sedangkan policing membuang kelebihan trafik tanpa kenaikan RTT (SIGCOMM 2016) #### rt-burst · Buffer dangkal meluap akibat burst pengiriman · Sender bursts overflow shallow buffers Jika setiap tick server mengirim update untuk ribuan pemain sekaligus dalam sekejap, buffer kecil di switch atau batas sesaat di cloud meluap dalam waktu kurang dari 1 ms dan sebagian paket dibuang. - Mengapa → Akibatnya → Di layar: Paket untuk semua pemain dikirim sekaligus tepat saat tick dimulai → Buffer port switch tempat trafik banyak server berkumpul (ratusan KB hingga beberapa MB per port) atau batas instance cloud meluap sesaat (utilisasi rata-rata tetap rendah) → Banyak pemain teleport atau tersendat sesaat secara bersamaan, penyebabnya tidak terlihat dari metrik rata-rata - Gejala: Teleport, Freeze, Fast forward / Faktor: Packet loss - Siapa: Lokasi/channel tertentu, Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur) - Tugas Tim Pengembang Game: Sebar pengiriman satu tick di sepanjang durasi tick (lonjakan ribuan koneksi di awal tick sulit diatasi dengan pacing per koneksi), sebar waktu mulai tick antarserver, batasi kecepatan koneksi yang mengirim data besar dengan SO_MAX_PACING_RATE. - Tugas Tim Infrastruktur: Server/OS: batasi laju kirim total server (shaper di OS server, tc di Linux), ratakan burst dari satu koneksi dengan pacing (qdisc fq di Linux, BBR). Jaringan: pakai switch dengan buffer besar, periksa counter drop output port switch dengan interval pendek (tidak terlihat dari utilisasi rata-rata). - Kisaran angka: Port 10 Gbps bisa mengirim sekitar 1,25 MB dalam 1 ms. Jika tick dari beberapa server bertepatan dan trafiknya terkumpul di satu port, buffer penuh dalam sekejap. - Di grafik: Naik mengikuti beban (Jumlah drop output port switch, tingkat retransmisi) - Yang diperiksa: Kumpulkan drop output (ifOutDiscards) di port switch tempat server terhubung dan port di atasnya setiap beberapa detik; di cloud, periksa bw_out_allowance_exceeded dan pps_allowance_exceeded di ethtool -S. Kumpulkan retransmisi pada saat yang sama dengan bcc tcpretrans, lalu cocokkan - Cocok jika: Utilisasi rata-rata per menit rendah, tetapi drop output atau allowance yang terlampaui bertambah, dan jumlahnya membesar mengikuti CCU dan jumlah pemain yang berkumpul di satu tempat. Retransmisi tidak terpusat pada rentang IP pemain tertentu (ISP atau wilayah) dan muncul di banyak koneksi server itu pada saat yang sama - Tidak cocok jika: Error CRC dan error input di port yang sama ikut naik: lebih mungkin “Error fisik”. Counter drop NIC atau softnet dropped di server penerima naik: lebih mungkin “Paket dibuang di host server penerima” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Pacing bekerja per koneksi. Lonjakan saat ribuan koneksi masing-masing mengirim satu atau dua paket di awal tick sulit diatasi dengan pacing per koneksi, sehingga server game sendiri harus menyebar waktu pengirimannya. Sebaliknya, saat satu koneksi mengirim data besar, NIC memotong data puluhan KB menjadi seukuran paket lalu mengirimnya beruntun (TSO), dan burst seperti ini bisa diratakan dengan baik oleh pacing. - Sumber: - [High-Resolution Measurement of Data Center Microbursts](https://research.facebook.com/publications/high-resolution-measurement-of-data-center-microbursts/) · Meta · Lebih dari 70% burst di switch rak data center selesai dalam puluhan µs, dan hubungan antara utilisasi rata-rata per menit dan drop lemah (IMC 2017) - [tc-fq(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-fq.8.html) · iproute2 · Qdisc fq melakukan pacing per socket (koneksi), dan SO_MAX_PACING_RATE menentukan kecepatan maksimum per koneksi - [net/ipv4/tcp_bbr.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_bbr.c?h=v6.12) · Linux kernel · BBR menentukan pacing_rate dari estimasi bandwidth bottleneck - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · TCP menentukan ukuran frame TSO sesuai laju flow (maksimal 64 KB, tcp_min_tso_segs) - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · bw_out_allowance_exceeded, pps_allowance_exceeded: jumlah paket yang dimasukkan ke antrean atau dibuang karena instance melewati batas bandwidth atau batas paket per detik - [RFC 2863: The Interfaces Group MIB](https://www.rfc-editor.org/rfc/rfc2863) · IETF · ifOutDiscards: jumlah paket keluar yang dibuang tanpa dikirim walaupun tidak ada error, misalnya untuk mengosongkan ruang buffer - [Demonstrations of tcpretrans, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/tcpretrans_example.txt) · IO Visor · Menampilkan satu baris untuk setiap retransmisi, berisi alamat dan port lawan serta status koneksi #### rt-policer · Policer membuang trafik berlebih · Traffic policing Batas kecepatan langganan ISP, batas instance cloud, dan perangkat proteksi DDoS kadang langsung membuang paket yang melewati kecepatan yang ditetapkan tanpa memasukkannya ke antrean. - Mengapa → Akibatnya → Di layar: Volume kirim sesaat melewati kecepatan atau burst yang diizinkan → Paket yang melewati batas langsung dibuang tanpa antrean (policing) → Setiap ada burst besar, beberapa paket hilang sehingga terjadi freeze lalu fast forward, padahal kecepatan rata-rata terlihat di bawah batas - Gejala: Freeze, Fast forward, Teleport / Faktor: Packet loss - Siapa: Seluruh server, Wilayah/ISP tertentu, Hanya saya / Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Sebar volume yang dikirim sekaligus setiap tick di sepanjang durasi tick agar volume kirim sesaat berada di bawah burst yang diizinkan, gabungkan pesan satu tick ke dalam satu paket jika terbentur batas paket per detik. - Tugas Tim Infrastruktur: Jaringan: periksa counter pelampauan policer di perangkat, ganti policer dengan shaper, perbesar burst yang diizinkan. Server/OS: periksa metrik batas cloud yang terlampaui (di AWS, bw_out_allowance_exceeded dan pps_allowance_exceeded di ethtool -S), naikkan tipe instance, lakukan pacing di server (qdisc fq di Linux). - Kisaran angka: Shaper (memasukkan paket ke antrean dan menundanya) menambah latensi, sedangkan policer (langsung membuang) menambah packet loss. Koneksi game TCP bisa berhenti ratusan ms karena satu kali packet loss, jadi jika trafik hanya sesaat melewati batas, biasanya dampak policer lebih besar. - Di grafik: Mendatar di batas (Volume kirim pada interval pendek, counter pelampauan policer dan allowance) - Yang diperiksa: Periksa counter pelampauan (exceed) dan drop di perangkat yang menjalankan policer; di cloud, periksa bw_out_allowance_exceeded dan pps_allowance_exceeded di ethtool -S. Untuk koneksi yang mengalami packet loss, periksa RTT tepat sebelum packet loss lewat rtt di ss -ti atau packet capture - Cocok jika: Counter pelampauan naik, dan volume kirim pada interval pendek mendatar seperti terpotong di nilai tertentu. RTT tidak naik sebelum packet loss, dan beberapa paket hilang sekaligus hanya saat burst besar - Tidak cocok jika: RTT naik lebih dulu sebelum packet loss: lebih mungkin antrean meluap (“Antrean bottleneck meluap”, “Buffer dangkal meluap akibat burst pengiriman”). Counter pelampauan tidak berubah: penyebab lain - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 2475: An Architecture for Differentiated Services](https://www.rfc-editor.org/rfc/rfc2475) · IETF · Definisi: shaping menunda paket agar sesuai profil trafik, sedangkan policing membuang paket yang melewati profil - [An Internet-Wide Analysis of Traffic Policing](https://research.google/pubs/an-internet-wide-analysis-of-traffic-policing/) · Google · Transfer yang terkena policing rata-rata mengalami packet loss 6 kali lebih tinggi, dan tujuan yang sama bisa dicapai dengan pacing atau shaping. Pembedaan: policing membuang kelebihan trafik tanpa kenaikan RTT, sedangkan pada antrean yang meluap RTT naik sebelum packet loss (SIGCOMM 2016) - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · bw_out_allowance_exceeded, pps_allowance_exceeded di ethtool -S: jumlah paket yang dimasukkan ke antrean atau dibuang karena melewati batas instance - [tc-fq(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-fq.8.html) · iproute2 · Pacing per koneksi pada qdisc fq di Linux - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rtt (rata-rata round-trip time) di ss -i #### rt-physical · Error fisik (kabel, modul optik, atau konektor rusak) · Bit errors: bad cable, optics, dirty fiber Kabel yang rusak, konektor serat optik yang kotor, dan modul optik yang sudah habis umur pakainya menimbulkan bit error, dan paket yang rusak dibuang diam-diam oleh perangkat. - Mengapa → Akibatnya → Di layar: Bit terbalik akibat kabel, modul optik, atau konektor yang rusak → Perangkat membuang paket yang checksum (CRC)-nya tidak cocok → Hanya pemain yang melewati jalur itu yang terus-menerus tersendat sesaat lalu mengalami fast forward, di jam berapa pun - Gejala: Freeze, Fast forward, Teleport / Faktor: Packet loss - Siapa: Lokasi/channel tertentu, Satu rumah / Kapan: Selalu - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pihak Eksternal (Pihak Eksternal) - Tugas Tim Infrastruktur: Error CRC menumpuk di sisi penerima pada arah yang rusak, jadi periksa kedua ujung. Jaringan: periksa counter error CRC dan error input di port perangkat, periksa kekuatan sinyal optik (informasi modul optik di switch), bersihkan konektor serat optik, ganti kabel dan modul optik. Server/OS: periksa rx_crc_errors di ethtool -S server (namanya sedikit berbeda tiap driver), periksa kekuatan sinyal optik (ethtool -m), ganti kabel atau NIC di sisi server. - Tugas Pihak Eksternal: Jika masalahnya di rumah pemain, imbau pemain untuk mengganti kabel LAN atau router; jika di jalur ISP, minta ISP memeriksa jalurnya. - Kisaran angka: Packet loss 0,1% pun berarti satu dari 1.000 paket game. Jika puluhan pemain melewati jalur itu, setiap beberapa detik ada saja yang tersendat sesaat. Makin besar paketnya, makin mudah terkena bit error. - Di grafik: Hanya sebagian yang tinggi (Jumlah error CRC per port, tingkat retransmisi per server dan per port) - Yang diperiksa: Periksa counter CRC di kedua ujung link: di server, rx_crc_errors di ethtool -S atau crc di ip -s -s link; di switch, error FCS (dot3StatsFCSErrors) dan error input (ifInErrors) pada port. Untuk link optik, periksa kekuatan sinyal optik yang diterima dengan ethtool -m dan informasi modul optik di switch - Cocok jika: Error CRC pada satu port terus naik di jam berapa pun, dan hanya server dan koneksi yang melewati port itu yang tingkat retransmisinya tinggi. Kekuatan sinyal optik yang diterima lebih rendah daripada link lain yang sejenis - Tidak cocok jika: CRC tidak berubah, hanya drop output yang naik: lebih mungkin antrean meluap (“Buffer dangkal meluap akibat burst pengiriman”, “Antrean bottleneck meluap”). Late collision di satu sisi dan error CRC di sisi lain naik bersamaan: lebih mungkin “Duplex mismatch” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · rx_crc_errors adalah jumlah paket yang dihitung interface penerima sebagai error CRC; periksa dengan ip -s -s link dan ethtool -S - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · -S untuk statistik per NIC dan driver, -m untuk EEPROM modul optik (SFP+, QSFP) dan informasi diagnostik optik - [RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types](https://www.rfc-editor.org/rfc/rfc3635) · IETF · Error FCS pada port switch (dot3StatsFCSErrors); error ini ikut dijumlahkan ke error input (ifInErrors) #### rt-duplex · Duplex mismatch · Duplex mismatch Jika satu sisi memakai autonegotiation sedangkan sisi lain mengunci kecepatan dan duplex, salah satu sisi berjalan dalam mode half duplex, dan paket hilang akibat collision setiap kali beban naik. - Mengapa → Akibatnya → Di layar: Kecepatan dan duplex dikunci hanya di salah satu perangkat → Satu sisi berjalan full duplex, sisi lain half duplex, sehingga terjadi collision dan late collision → Biasanya normal, tetapi saat trafik naik, semua pemain yang melewati perangkat itu mengalami freeze lalu fast forward - Gejala: Freeze, Fast forward / Faktor: Packet loss - Siapa: Seluruh server, Lokasi/channel tertentu / Kapan: Saat banyak pemain berkumpul, Jam sibuk malam hari - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Atur kedua sisi ke autonegotiation, atau kunci kedua sisi ke nilai yang sama. Jaringan: periksa kecepatan dan duplex di status port switch, lalu periksa di counter port apakah late collision bertambah di sisi half duplex, serta error CRC dan frame yang terlalu pendek (runt) bertambah di sisi full duplex. Server/OS: periksa kecepatan dan duplex dengan ethtool. - Kisaran angka: Kabel tembaga 1 Gbps wajib memakai autonegotiation, dan pada 10 Gbps ke atas half duplex sama sekali tidak ada. Karena itu, sekarang masalah ini terutama muncul di perangkat lama 100 Mbps ke bawah, di port manajemen, dan di sebagian titik sambungan sirkuit. - Di grafik: Naik mengikuti beban (Jumlah late collision dan error CRC per port, tingkat retransmisi) - Yang diperiksa: Periksa kecepatan dan duplex yang sebenarnya di kedua ujung link: di server, jalankan ethtool hanya dengan nama interface; di switch, lihat status port atau dot3StatsDuplexStatus lewat SNMP. Periksa juga late collision (tx_window_errors di server, dot3StatsLateCollisions di switch) dan error CRC - Cocok jika: Satu sisi menunjukkan half duplex, sisi lain full duplex. Setiap kali trafik naik, late collision di sisi half duplex dan error CRC di sisi full duplex naik bersamaan - Tidak cocok jika: Kecepatan dan duplex di kedua sisi sama, hanya CRC yang naik: lebih mungkin “Error fisik”. Link 10 Gbps ke atas tidak punya half duplex, jadi coret penyebab ini untuk link tersebut - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Linux Base Driver for Intel(R) Ethernet Network Connection](https://docs.kernel.org/networking/device_drivers/ethernet/intel/e1000.html) · Linux kernel · Standar 1000BASE-T mewajibkan autonegotiation - [IEEE 802.3ae 10 Gigabit Ethernet: HSSG Objectives](https://www.ieee802.org/3/ae/objectives.pdf) · IEEE · 10 Gigabit Ethernet hanya mendukung full duplex - [IEEE P802.3ba Objectives](https://www.ieee802.org/3/ba/PAR/P802.3ba_Objectives_0709.pdf) · IEEE · 40 dan 100 Gigabit Ethernet juga hanya mendukung full duplex - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · tx_window_errors adalah jumlah pengiriman yang gagal akibat late collision, rx_crc_errors adalah jumlah paket yang diterima dengan error CRC - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · ethtool -s mengatur kecepatan, duplex, dan autonegotiation lewat speed, duplex, dan autoneg; jika hanya diberi nama interface, ethtool menampilkan pengaturan saat ini - [RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types](https://www.rfc-editor.org/rfc/rfc3635) · IETF · dot3StatsDuplexStatus (menampilkan duplex saat ini sebagai halfDuplex atau fullDuplex), dot3StatsLateCollisions (jumlah late collision) #### rt-host-drop · Paket dibuang di host server penerima · Receiver host drops (ring, softirq, CPU) Paket sudah sampai di server, tetapi dibuang karena ring buffer NIC (buffer yang menampung sementara paket yang tiba) meluap atau core yang menangani pemrosesan terima di kernel jenuh. - Mengapa → Akibatnya → Di layar: Lonjakan jumlah pemain, interrupt yang terpusat di satu core, CPU steal di virtual machine, atau virtual switch yang kelebihan beban → Paket dibuang di ring buffer (rx_missed_errors dan sejenisnya, namanya berbeda tiap driver) atau di antrean terima kernel (softnet dropped) → Saat pemain berkumpul, input terlambat diproses dan game tersendat sesaat di seluruh server secara bersamaan - Gejala: Input lag, Freeze, Fast forward, Teleport / Faktor: Packet loss, Stall - Siapa: Seluruh server / Kapan: Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Tambahkan counter drop seperti rx_missed_errors di ethtool -S dan dropped di /proc/net/softnet_stat ke monitoring, perbesar ring buffer (ethtool -G), sebar RSS dan interrupt ke beberapa core, pisahkan core thread game dari core pemrosesan terima, sisakan kapasitas CPU, dan di virtual machine periksa CPU steal serta beban virtual switch. - Kisaran angka: Paket yang dibuang server saat diterima akan dikirim ulang oleh klien. Karena itu, kejadian ini jarang tertangkap di metrik retransmisi server dan lebih dulu muncul di counter drop seperti rx_missed_errors di ethtool -S (namanya berbeda tiap driver) dan di dropped pada /proc/net/softnet_stat. - Di grafik: Mendatar di batas (Utilisasi softirq per core, counter drop NIC) - Yang diperiksa: Periksa counter drop di ethtool -S (rx_missed_errors dan sejenisnya; di mlx5, rx_out_of_buffer dan rx_discards_phy), missed di ip -s -s link, serta kolom ke-2 (dropped) dan kolom ke-3 (time_squeeze) di /proc/net/softnet_stat, lalu periksa %soft (pemrosesan software interrupt) per core dengan mpstat -P ALL. Di virtual machine, periksa juga %steal - Cocok jika: Saat pemain berkumpul, counter drop atau softnet dropped naik, dan %soft pada core yang menangani pemrosesan terima tertahan di dekat 100% dan tidak bisa naik lagi. Input melambat di semua koneksi server itu pada saat yang sama - Tidak cocok jika: Counter drop server tidak berubah dan retransmisi terpusat pada koneksi dari wilayah atau ISP tertentu: packet loss di rute. Jika paket yang dikirim server hilang di rute, TcpRetransSegs di nstat server naik, sedangkan counter di atas tidak berubah - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · rx_missed_errors adalah jumlah paket yang tidak bisa diterima host karena tidak ada buffer (di /proc/net/dev dijumlahkan ke drop); periksa dengan ip -s -s link - [drivers/net/ethernet/intel/igb/igb_ethtool.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/igb/igb_ethtool.c?h=v6.12) · Linux kernel · Nama counter di ethtool -S ditentukan oleh driver (misalnya rx_missed_errors dan rx_no_buffer_count pada igb) - [Ethtool counters](https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5/counters.html) · Linux kernel · rx_out_of_buffer (tidak ada buffer di antrean terima) dan rx_discards_phy (dibuang karena buffer port kurang) pada driver mlx5 - [net/core/net-procfs.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/net-procfs.c?h=v6.12) · Linux kernel · /proc/net/softnet_stat berisi satu baris per CPU dalam heksadesimal; kolom ke-2 adalah dropped, kolom ke-3 adalah time_squeeze - [Documentation for /proc/sys/net/](https://docs.kernel.org/admin-guide/sysctl/net.html) · Linux kernel · netdev_max_backlog: batas antrean terima yang menampung paket saat paket datang lebih cepat daripada kemampuan kernel memprosesnya - [Scaling in the Linux Networking Stack](https://docs.kernel.org/networking/scaling.html) · Linux kernel · RSS: NIC membagi trafik ke beberapa antrean terima yang diproses oleh beberapa CPU - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · -G (--set-ring) mengubah ukuran ring buffer - [proc_stat(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_stat.5.html) · Linux man-pages · steal di /proc/stat: waktu CPU dipakai OS lain di lingkungan virtualisasi - [mpstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/mpstat.1.html) · sysstat · mpstat -P ALL menampilkan utilisasi per core; %soft adalah waktu pemrosesan software interrupt, %steal adalah waktu menunggu selama hypervisor melayani CPU virtual lain - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · TcpRetransSegs yang ditampilkan nstat (RetransSegs pada bagian Tcp) #### rt-stateful-fw · Paket dibuang oleh firewall atau connection tracking · Stateful firewall / conntrack drops Firewall dan connection tracking Linux (conntrack, fitur yang mencatat koneksi yang lewat ke dalam tabel) membuang paket jika tabelnya penuh atau jika paket dianggap tidak sesuai dengan status koneksi. - Mengapa → Akibatnya → Di layar: Tabel connection tracking penuh (table full), atau rute pergi dan pulang berbeda sehingga hanya satu arah yang melewati firewall (rute asimetris) → Firewall menganggap paket itu milik “koneksi yang tidak dikenal” atau membawa “nomor urut di luar rentang window”, lalu membuangnya → Jika tabel penuh, koneksi baru terblokir; jika rutenya asimetris, hanya pemain di rute itu yang disconnect setelah retransmisi berulang - Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Seluruh server, Wilayah/ISP tertentu / Kapan: Saat banyak pemain berkumpul, Tepat setelah login atau maintenance, Sesekali secara acak - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: antisipasi tabel penuh dengan mengatur lonjakan koneksi lewat sistem antrean login, pakai ulang koneksi agar tidak terus membuka koneksi singkat (termasuk pemanggilan antarserver), tutup lebih dulu koneksi yang heartbeat-nya berhenti. Klien: jika koneksi gagal atau terputus, coba lagi dengan interval yang makin panjang dan disebar secara acak (agar pemain tidak menyerbu kembali bersamaan saat tabel penuh). - Tugas Tim Infrastruktur: Jaringan: perbesar tabel connection tracking di firewall, keluarkan port game dari connection tracking, samakan routing agar rute pergi dan pulang melewati firewall yang sama, periksa pengaturan pemeriksaan window TCP di firewall. Server/OS: perbesar tabel di Linux (nf_conntrack_max), keluarkan port game dari connection tracking (NOTRACK), periksa pengaturan pemeriksaan window TCP (nf_conntrack_tcp_be_liberal), di AWS periksa juga conntrack_allowance_exceeded. - Kisaran angka: Batas default conntrack Linux (nf_conntrack_max) berkisar puluhan ribu hingga ratusan ribu entri tergantung memori. Jika jumlah saat ini (nf_conntrack_count) mencapai batas, log mencatat “nf_conntrack: table full, dropping packet”. - Di grafik: Mendatar di batas (Jumlah entri conntrack (nf_conntrack_count), jumlah koneksi baru yang gagal) - Yang diperiksa: Di server Linux, periksa nf_conntrack_count dan nf_conntrack_max, “nf_conntrack: table full, dropping packet” di dmesg, serta drop dan invalid di /proc/net/stat/nf_conntrack (satu baris per core, heksadesimal). Di firewall, periksa pemakaian tabel sesi dan log drop; di AWS, periksa conntrack_allowance_exceeded di ethtool -S - Cocok jika: Jumlah entri mendatar di batas, dan pada saat yang sama log table full dan drop, atau conntrack_allowance_exceeded, naik. Pada rute asimetris, tabel masih punya ruang, tetapi invalid dan log drop firewall naik pada koneksi di rute tertentu - Tidak cocok jika: Jumlah entri jauh dari batas, invalid dan log drop juga tidak berubah: penyebab lain. Tabel masih punya ruang, tetapi CPU atau paket per detik firewall sudah penuh: lebih mungkin “Batas pemrosesan perangkat perantara terlampaui” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Nilai default nf_conntrack_max adalah jumlah hash bucket (memori ÷ 16384, 1.024–262.144), jumlah saat ini ada di nf_conntrack_count, dan nf_conntrack_tcp_be_liberal hanya menandai RST di luar window sebagai INVALID - [net/netfilter/nf_conntrack_core.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_core.c?h=v6.12) · Linux kernel · Jika tabel penuh, kernel mencatat log “nf_conntrack: table full, dropping packet” dan membuang paket (statistik drop naik); paket yang tidak sesuai dengan status koneksi menaikkan statistik invalid - [iptables-extensions(8) — Linux manual page](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) · netfilter · CT --notrack di tabel raw mengecualikan trafik dari connection tracking - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Jika jumlah koneksi yang dilacak melewati batas per instance, paket dibuang dan kejadiannya terlihat di conntrack_allowance_exceeded; disertai rekomendasi untuk menghindari rute asimetris - [net/netfilter/nf_conntrack_standalone.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/netfilter/nf_conntrack_standalone.c?h=v6.12) · Linux kernel · /proc/net/stat/nf_conntrack berisi satu baris per core dalam heksadesimal, dengan kolom seperti entries, invalid, insert_failed, drop, dan early_drop #### rt-appliance-pps · Batas pemrosesan perangkat perantara terlampaui (firewall, IPS, proteksi DDoS) · Inline appliance PPS / CPU overload Firewall, perangkat pencegah intrusi (IPS), dan perangkat proteksi DDoS memeriksa setiap paket yang lewat. Begitu trafik melampaui kapasitas pemeriksaannya, paket yang tidak sempat diproses dibuang. - Mengapa → Akibatnya → Di layar: Lebih dari ratusan ribu paket game kecil per detik datang bersamaan pada jam sibuk atau saat event, atau aturan pemeriksaannya berat → Batas CPU atau paket per detik perangkat penuh sehingga paket dibuang di perangkat. Jika terjadi false positive, paket normal pun diblokir → Seluruh server di belakang perangkat itu mengalami freeze dan teleport bersamaan, makin parah hanya saat pemain berkumpul - Gejala: Freeze, Fast forward, Teleport, Disconnect / Faktor: Packet loss, Latensi - Siapa: Seluruh server, Wilayah/ISP tertentu / Kapan: Jam sibuk malam hari, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Bagikan pola trafik game (port, ukuran paket, paket per detik) ke Tim Infrastruktur, kumpulkan pesan kecil dalam satu tick lalu kirim sekaligus untuk mengurangi jumlah paket. - Tugas Tim Infrastruktur: Pantau CPU, paket per detik, dan counter drop perangkat bersama metrik game, hitung kapasitas perangkat berdasarkan paket kecil, keluarkan port game dari pemeriksaan berat, sesuaikan aturan proteksi DDoS dengan pola trafik game. - Kisaran angka: Angka “10 Gbps” di spesifikasi perangkat sering ditulis berdasarkan paket besar 1.500 byte. Paket game berukuran sekitar 100 byte, sehingga pada bandwidth yang sama jumlah paketnya lebih dari 10 kali lipat, dan batas paket per detik tercapai lebih dulu walaupun jalurnya terlihat sepi. - Di grafik: Mendatar di batas (Paket per detik dan utilisasi CPU perangkat, jumlah drop perangkat) - Yang diperiksa: Periksa CPU, paket per detik, dan counter drop perangkat, lalu bandingkan jumlah paket di port switch sebelum dan sesudah perangkat dengan interval yang sama. Tumpangkan dengan CCU dan tingkat retransmisi server di satu layar - Cocok jika: Saat jam sibuk atau event, paket per detik atau CPU perangkat tertahan di satu nilai dan tidak bisa naik lagi, paket yang keluar dari perangkat lebih sedikit daripada yang masuk, dan pada saat yang sama tingkat retransmisi seluruh server di belakangnya ikut naik - Tidak cocok jika: Jumlah paket sebelum dan sesudah perangkat sama dan tidak ada drop di perangkat: penyebab lain. Counter drop NIC atau softnet dropped di server naik: lebih mungkin “Paket dibuang di host server penerima” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 2544: Benchmarking Methodology for Network Interconnect Devices](https://www.rfc-editor.org/rfc/rfc2544) · IETF · Performa perangkat harus diuji dengan berbagai ukuran frame, termasuk ukuran minimum dan maksimum (performa pemrosesan berubah sesuai ukuran paket) #### rt-mtu · MTU black hole (hanya paket besar yang berulang kali hilang) · PMTU black hole Jika ukuran maksimum yang bisa dilewati suatu jalur di tengah rute mengecil dan notifikasi “terlalu besar” (ICMP) diblokir, paket besar terus hilang berapa kali pun dikirim ulang. - Mengapa → Akibatnya → Di layar: Ukuran maksimum mengecil di segmen VPN atau tunnel, dan notifikasi ukuran terlampaui diblokir firewall → Pengirim terus mengirim ulang paket besar yang sama tanpa tahu sebabnya, dan RTO berlipat dua setiap kali → Biasanya normal, tetapi saat data besar lewat (inventory, tempat ramai, loading saat masuk), paket kecil di belakangnya pun ikut berhenti, lalu berakhir dengan disconnect atau loading tanpa henti - Gejala: Freeze, Disconnect, Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Wilayah/ISP tertentu, Hanya saya / Kapan: Saat melakukan aksi tertentu, Tepat setelah login atau maintenance - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Untuk menurunkannya langsung dari sisi server, atur ukuran segmen maksimum socket (TCP_MAXSEG); memecah pesan menjadi kecil-kecil di kode game saja tidak mencegah masalah ini (TCP menggabungkan lagi data yang akan dikirim seukuran MSS). - Tugas Tim Infrastruktur: Jaringan: lakukan penyesuaian MSS (clamping) di perangkat tepi jaringan, izinkan ICMP ukuran terlampaui (tipe 3 kode 4, fragmentation needed) di firewall dan network ACL cloud. Server/OS: atur path MTU, pastikan ICMP ukuran terlampaui juga tidak diblokir di firewall server dan security group cloud, aktifkan tcp_mtu_probing=1 di Linux sebagai jaring pengaman terakhir. - Kisaran angka: Biasanya 1.500 byte, dan sekitar 1.400 jika melewati tunnel. Jika paket yang sama dikirim ulang 5–6 kali, jedanya lebih dari 10 detik. - Di grafik: Hanya sebagian yang tinggi (RTO dan backoff per koneksi, jumlah disconnect per wilayah dan ISP) - Yang diperiksa: Periksa retransmisi pada koneksi bermasalah dengan packet capture di sisi server atau bcc tcpretrans -s (menampilkan nomor urut), lalu periksa mss, pmtu, dan backoff koneksi itu dengan ss -ti. Dari server, kirim ping kecil dan ping 1.500 byte dengan DF aktif (ping -M do -s 1472) ke alamat pemain itu, lalu bandingkan - Cocok jika: Paket seukuran MSS penuh terus dikirim ulang dengan nomor urut yang sama dan interval yang berlipat dua, sedangkan paket yang lebih kecil lolos. ICMP ukuran terlampaui (filter Wireshark icmp.type == 3 and icmp.code == 4) tidak datang, dan ping kecil dibalas, tetapi ping DF besar hilang tanpa balasan - Tidak cocok jika: Paket kecil juga ikut hilang: packet loss yang tidak terkait ukuran (“Antrean bottleneck meluap”, “Perubahan rute dan jalur ECMP bermasalah”). ICMP ukuran terlampaui datang dan pmtu di ss -ti mengecil: path MTU discovery berjalan dengan benar - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: tcp_mtu_probing=1 baru menganggap ada black hole dan menurunkan MSS ke 1.024 byte setelah timeout retransmisi berlangsung beberapa detik (setara dengan tcp_retries1=3). Selama itu koneksi berhenti, jadi jadikan opsi ini jaring pengaman terakhir dan dahulukan penyesuaian MSS yang mencegah masalah sejak awal. - Sumber: - [RFC 1191: Path MTU discovery](https://www.rfc-editor.org/rfc/rfc1191) · IETF · Path MTU discovery: paket yang terlalu besar diberitahukan lewat ICMP “fragmentation needed and DF set” (tipe 3 kode 4) - [RFC 2923: TCP Problems with Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc2923) · IETF · Masalah PMTU black hole, yaitu ICMP diblokir sehingga hanya paket besar yang terus hilang - [RFC 4821: Packetization Layer Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc4821) · IETF · Cara lapisan transport menemukan ukuran paket tanpa ICMP (dasar tcp_mtu_probing di Linux) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_mtu_probing: 0 nonaktif, 1 hanya saat black hole terdeteksi, 2 selalu (MSS awal adalah tcp_base_mss). Default tcp_retries1 adalah 3 - [net/ipv4/tcp_timer.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · Jika retransmisi RTO berlangsung sebanyak tcp_retries1, kernel menganggapnya sebagai black hole, mengaktifkan MTU probing, dan menurunkan MSS - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_BASE_MSS = 1.024 byte - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Menggandakan RTO setiap kali timer retransmisi habis - [iptables-extensions(8) — Linux manual page](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) · netfilter · TCPMSS --clamp-mss-to-pmtu: mengatasi paket besar yang tertahan di segmen yang memblokir ICMP dengan menyesuaikan MSS di SYN - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_MAXSEG: ukuran segmen maksimum paket keluar; jika diatur sebelum koneksi dibuat, MSS yang diberitahukan ke pihak lawan juga berubah - [Network maximum transmission unit (MTU) for your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html) · AWS · Internet gateway dan VPN memakai MTU 1.500; PMTUD membutuhkan ICMP tipe 3 kode 4, yang tidak akan diterima jika diblokir security group atau network ACL - [MTU considerations | Cloud VPN](https://cloud.google.com/network-connectivity/docs/vpn/concepts/mtu-considerations) · Google Cloud · MTU gateway Cloud VPN 1.460 byte, MTU payload tunnel IPv4 1.406 byte (sekitar 1.400 jika melewati tunnel) - [Demonstrations of tcpretrans, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/tcpretrans_example.txt) · IO Visor · Menampilkan satu baris untuk setiap retransmisi, dan -s juga menampilkan nomor urut paket yang dikirim ulang - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · mss, pmtu (path MTU), dan backoff (berapa kali RTO digandakan) di ss -i - [ping(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ping.8.html) · iputils · -M do mengaktifkan DF dan tidak mengirim paket yang lebih besar daripada path MTU yang diketahui kernel; -s adalah ukuran data (belum termasuk header ICMP 8 byte) - [Display Filter Reference: Internet Control Message Protocol](https://www.wireshark.org/docs/dfref/i/icmp.html) · Wireshark · Filter tampilan icmp.type dan icmp.code #### rt-mapping · Mapping NAT atau load balancer kedaluwarsa di tengah koneksi · NAT / load balancer mapping expired mid-connection Jika perangkat di tengah rute menghapus mapping koneksi idle (entri yang mencatat ke mana koneksi itu diteruskan), paket berikutnya tidak bisa diteruskan. Retransmisi terus berulang sampai pemain disconnect, atau perangkat membalas dengan penolakan koneksi (RST) sehingga pemain langsung disconnect. - Mengapa → Akibatnya → Di layar: Koneksi yang tidak dilewati paket selama beberapa waktu (AFK, di lobi) → NAT di router, CGNAT ISP, firewall, load balancer, atau security group cloud menghapus mapping yang idle → Begitu pemain bergerak lagi, retransmisi berlanjut hingga disconnect, atau langsung disconnect - Gejala: Disconnect, Freeze / Faktor: Packet loss - Siapa: Hanya saya, Wilayah/ISP tertentu / Kapan: Setelah lama diam - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Infrastruktur jaringan (Tim Infrastruktur), Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Klien: kirim heartbeat dengan interval maksimal setengah dari idle timeout terpendek (mapping di router pemain dan CGNAT ISP hanya diperbarui dengan pasti oleh paket keluar, dan timeout-nya tidak bisa kami ubah, jadi klien yang mengirim), reconnect otomatis jika terputus. Server: balas heartbeat dan putuskan koneksi lebih dulu jika tidak ada heartbeat dalam waktu tertentu (perpendek interval keepalive TCP dengan opsi socket seperti TCP_KEEPIDLE, deteksi cepat dengan TCP_USER_TIMEOUT), lanjutkan sesi dengan token sesi. - Tugas Tim Infrastruktur: Jaringan: kumpulkan idle timeout firewall dan load balancer di sepanjang rute lalu bagikan ke Tim Pengembang Game, perpanjang idle timeout di firewall dan load balancer kami jika perlu. Server/OS: periksa waktu connection tracking di security group cloud lalu bagikan ke Tim Pengembang Game. - Kisaran angka: Lama mapping TCP dipertahankan berbeda-beda tiap perangkat, dari beberapa menit hingga beberapa jam. Jika security group cloud diatur untuk melacak koneksi, tipe instance AWS Nitro v6 secara default menghapus entri pelacakannya setelah 350 detik (tipe lain setelah 5 hari, lihat entri “Connection tracking di security group cloud kedaluwarsa”). Nilai default keepalive TCP di Linux adalah “periksa setelah idle 2 jam”, lebih lambat daripada kebanyakan perangkat. - Di grafik: Koneksi putus serentak (Jumlah disconnect, waktu idle sebelum terputus) - Yang diperiksa: Periksa beberapa menit terakhir koneksi yang terputus lewat packet capture di sisi server; untuk koneksi yang masih hidup, periksa waktu idle dari lastsnd dan lastrcv di ss -ti (ms sejak terakhir mengirim dan menerima). Periksa juga TcpExtTCPAbortOnTimeout di nstat (jumlah koneksi yang dilepas karena timer habis) - Cocok jika: Setiap koneksi yang terputus sebelumnya idle melewati nilai yang mirip (idle timeout perangkat di rute, misalnya 350 detik untuk security group instance AWS Nitro v6), dan sejak paket pertama setelah idle hanya ada retransmisi tanpa ACK sampai koneksi menyerah, atau RST langsung datang - Tidak cocok jika: Terputus juga di tengah permainan tanpa terkait waktu idle: penyebab lain (“Perubahan rute dan jalur ECMP bermasalah”, “Paket dibuang oleh firewall atau connection tracking”). Koneksi yang bertukar heartbeat dengan interval maksimal setengah dari idle timeout terpendek: coret penyebab ini - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 5382: NAT Behavioral Requirements for TCP](https://www.rfc-editor.org/rfc/rfc5382) · IETF · Rekomendasi bahwa idle timeout koneksi TCP di NAT minimal 2 jam 4 menit (dengan asumsi perangkat bisa menghapus sesi idle lebih awal) - [RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) · IETF · Mapping NAT harus diperbarui oleh paket keluar (REQ-6), sedangkan pembaruan oleh paket masuk bersifat opsional (untuk UDP) - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Nilai default timeout pelacakan TCP idle adalah 350 detik untuk tipe instance Nitro v6 dan 432.000 detik (5 hari) untuk tipe lain; disarankan keepalive dengan interval kurang dari 5 menit - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Default tcp_keepalive_time 2 jam - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_KEEPIDLE (waktu idle sebelum keepalive dimulai), TCP_USER_TIMEOUT (lama menunggu data yang belum dikonfirmasi sebelum koneksi ditutup) - [RFC 5482: TCP User Timeout Option](https://www.rfc-editor.org/rfc/rfc5482) · IETF · TCP user timeout: berapa lama data yang dikirim boleh belum dikonfirmasi sebelum koneksi ditutup - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · lastsnd dan lastrcv di ss -i: waktu sejak terakhir mengirim dan menerima (ms) - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPAbortOnTimeout: jumlah koneksi yang dilepas tanpa RST karena timer TCP habis #### rt-path · Perubahan rute dan jalur ECMP bermasalah · Route change / bad ECMP member Paket hilang selama beberapa detik saat rute internet berubah, atau terus-menerus pada koneksi yang ditempatkan di jalur bermasalah di antara beberapa jalur ECMP. - Mengapa → Akibatnya → Di layar: Perhitungan ulang rute BGP, atau perangkat atau jalur yang rusak di salah satu dari beberapa jalur (ECMP, LAG) → Packet loss sementara selama rute beralih, atau packet loss terus-menerus hanya pada koneksi yang melewati jalur itu → Tiba-tiba freeze beberapa detik lalu fast forward, atau “membaik setelah reconnect” (ditempatkan di jalur lain) - Gejala: Freeze, Fast forward, Teleport / Faktor: Packet loss - Siapa: Wilayah/ISP tertentu / Kapan: Sesekali secara acak - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Pihak Eksternal (Pihak Eksternal) - Tugas Tim Pengembang Game: Catat statistik retransmisi per koneksi (TCP_INFO) agar IP, port, dan waktu pemain yang terdampak bisa diambil, jangan langsung memutus koneksi yang berhenti beberapa detik. - Tugas Tim Infrastruktur: Pantau tingkat retransmisi per wilayah dan ISP, periksa apakah rute berubah setelah reconnect, sediakan jalur dari beberapa ISP, periksa link yang rusak di jalur ECMP dan LAG perangkat kami, ukur rute dengan port TCP yang sama dengan game (mtr --tcp --port. Rute ditentukan oleh alamat dan port, jadi ping biasa bisa lewat jalur lain dan hasilnya terlihat normal). - Tugas Pihak Eksternal: Laporkan jalur bermasalah ke ISP dengan melampirkan hasil pengukuran rute pada port TCP yang sama serta perbandingan sebelum dan sesudah reconnect. - Di grafik: Naik seperti anak tangga (RTT (ping), tingkat retransmisi per wilayah dan ISP) - Yang diperiksa: Kumpulkan retransmisi per koneksi dengan bcc tcpretrans -c untuk mengambil alamat dan port pemain yang terdampak, lalu jalankan mtr dengan port TCP yang sama dengan game (mtr -T -P PORT) dari server ke arah pemain dan dari pemain ke arah server, lalu bandingkan. Bandingkan juga hasil sebelum dan sesudah reconnect - Cocok jika: Sejak waktu tertentu, RTT satu wilayah atau ISP berubah seperti anak tangga dan packet loss menumpuk selama beberapa detik, atau di dalam ISP yang sama hanya sebagian koneksi (kombinasi alamat dan port) yang terus mengirim ulang dan membaik setelah reconnect. Kadang ping biasa terlihat normal, tetapi packet loss hanya terlihat di mtr TCP - Tidak cocok jika: Semua koneksi di ISP itu memburuk bersamaan pada jam sibuk malam: lebih mungkin “Antrean bottleneck meluap”. Hanya satu pemain yang terdampak dan packet loss sudah muncul sejak ping ke router: lebih mungkin “Packet loss di jalur nirkabel” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Kasus nyata: cloudflare-2020 - Sumber: - [RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection](https://www.rfc-editor.org/rfc/rfc2991) · IETF · Hasil tools diagnosis seperti ping dan traceroute sulit dipercaya di jaringan multipath; menjelaskan cara mengunci rute setiap flow dengan hash - [RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm](https://www.rfc-editor.org/rfc/rfc2992) · IETF · ECMP memilih jalur berikutnya dari hash field header yang mengidentifikasi flow (flow yang sama melewati jalur yang sama) - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_INFO: membaca status per socket (struct tcp_info) - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · -T (--tcp) memakai TCP SYN sebagai pengganti ICMP, -P (--port) menentukan port tujuan - [Demonstrations of tcpretrans, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/tcpretrans_example.txt) · IO Visor · Menampilkan satu baris untuk setiap retransmisi berisi alamat dan port lawan; -c menghitung jumlah retransmisi per flow #### rt-spurious-delay · Retransmisi yang tidak perlu akibat lonjakan latensi · Spurious RTO from delay spikes Paket sebenarnya tidak hilang dan hanya sesaat datang sangat terlambat, tetapi jika keterlambatan itu lebih lama dari RTO, pengirim menganggap paket hilang lalu mengirimnya ulang. - Mengapa → Akibatnya → Di layar: Bufferbloat, mode hemat daya Wi-Fi, transisi state radio seluler, atau virtual machine yang dijeda sesaat menimbulkan keterlambatan sesaat ratusan ms → RTO habis lebih dulu sehingga paket dikirim ulang, lalu paket aslinya pun segera tiba (penerima menerima duplikat) → Freeze dan fast forward disebabkan oleh lonjakan latensi itu sendiri. Retransmisi yang tidak perlu hampir tidak menambah lama freeze, tetapi menaikkan metrik retransmisi sehingga disangka packet loss - Gejala: Freeze, Fast forward, Input lag / Faktor: Latensi, Jitter - Siapa: Hanya saya, Seluruh server / Kapan: Sesekali secara acak, Setelah lama diam - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Di klien Android 10 ke atas, minta mode Wi-Fi latensi rendah selama bermain (Wi-Fi lock WIFI_MODE_FULL_LOW_LATENCY, hanya berlaku saat layar menyala dan game berada di latar depan) untuk mengurangi lonjakan latensi akibat mode hemat daya. - Tugas Tim Infrastruktur: Hindari instance tipe burstable, jangan menurunkan nilai minimum RTO terlalu rendah, pertahankan F-RTO dan timestamp (tcp_frto, tcp_timestamps), baca metrik retransmisi bersama TCPSpuriousRTOs dan TCPDSACKRecv di nstat agar tidak disangka packet loss. - Tugas Pihak Eksternal: Imbau pemain untuk memakai SQM di router dan mematikan mode hemat daya Wi-Fi agar lonjakan latensinya sendiri berkurang. - Kisaran angka: Linux bisa mendeteksi RTO yang tidak perlu dengan F-RTO dan membatalkan penurunan laju kirim. Periksa dengan TCPSpuriousRTOs di nstat (berapa kali RTO dinilai tidak perlu) dan TCPDSACKRecv (berapa kali penerima memberi tahu “sudah pernah diterima”). - Di grafik: Melonjak acak sesekali (RTT (ping), jumlah RTO yang tidak perlu) - Yang diperiksa: Jalankan nstat setiap 1 menit dan periksa kenaikan TcpExtTCPTimeouts (RTO habis), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv, dan TcpExtTCPLostRetransmit secara bersamaan. Jika ada packet capture, pakai filter Wireshark tcp.analysis.spurious_retransmission - Cocok jika: Saat RTO bertambah, TcpExtTCPSpuriousRTOs atau TcpExtTCPDSACKRecv ikut naik, dan pada saat yang sama RTT melonjak ke ratusan ms. Di capture sisi penerima, paket asli dan paket retransmisi sama-sama tiba - Tidak cocok jika: TcpExtTCPSpuriousRTOs dan DSACK tidak berubah, tetapi TcpExtTCPLostRetransmit (paket yang dikirim ulang pun hilang lagi) naik: packet loss sungguhan. RTT tidak melonjak, tetapi DSACK terus banyak: lebih mungkin “Fast retransmit yang tidak perlu akibat urutan paket tertukar” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP](https://www.rfc-editor.org/rfc/rfc5682) · IETF · F-RTO: memakai ACK yang datang setelah RTO untuk menentukan apakah RTO itu tidak perlu - [RFC 3481: TCP over Second (2.5G) and Third (3G) Generation Wireless Networks](https://www.rfc-editor.org/rfc/rfc3481) · IETF · Lonjakan latensi di jaringan seluler (handover, pemulihan di lapisan link, dan lainnya) menimbulkan timeout dan retransmisi TCP yang tidak perlu serta mengecilkan congestion window - [RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP](https://www.rfc-editor.org/rfc/rfc2883) · IETF · DSACK: penerima memberi tahu adanya duplikat sehingga pengirim tahu retransmisinya tidak perlu - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPSpuriousRTOs (RTO tidak perlu yang dideteksi F-RTO), TcpExtTCPDSACKRecv (jumlah DSACK yang diterima), TcpExtTCPLostRetransmit (jumlah laporan SACK bahwa paket yang dikirim ulang hilang lagi) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_frto aktif secara default (menguntungkan di jaringan nirkabel yang RTT-nya naik turun), default tcp_timestamps 1 - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Dasar bahwa RTO minimum yang besar diperlukan untuk mencegah retransmisi yang tidak perlu (rekomendasi minimal 1 detik) - [WifiManager](https://developer.android.com/reference/android/net/wifi/WifiManager#WIFI_MODE_FULL_LOW_LATENCY) · Android (Google) · WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): Wi-Fi lock latensi rendah yang hanya berlaku saat terhubung ke AP, layar menyala, dan aplikasi berada di latar depan - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Nama counter yang ditampilkan nstat: TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv, TCPLostRetransmit - [net/ipv4/tcp_timer.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · TCPTimeouts naik saat timer retransmisi (RTO) habis - [nstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/nstat.8.html) · iproute2 · Secara default, nstat menampilkan kenaikan sejak eksekusi sebelumnya - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Filter tampilan tcp.analysis.spurious_retransmission #### rt-reorder · Fast retransmit yang tidak perlu akibat urutan paket tertukar · Reordering triggers spurious fast retransmit Jika urutan paket berubah saat melewati beberapa jalur atau link yang digabung, penerima memberi tahu “ada paket yang hilang” lewat duplicate ACK, dan pengirim mengirim ulang paket yang sebenarnya sudah sampai dengan baik. - Mengapa → Akibatnya → Di layar: Perangkat yang membagi rute per paket, LAG (gabungan link) yang membagi muatan per paket, dan momen saat rute berubah membuat urutan paket teracak → Paket belakang tiba lebih dulu sehingga 3 duplicate ACK menumpuk → fast retransmit → Paket game yang dikirim jarang-jarang hampir tidak terpengaruh. Update besar di tempat ramai dan unduhan patch melambat, sesekali patah-patah - Gejala: Patah-patah, Input lag / Faktor: Jitter - Siapa: Wilayah/ISP tertentu, Seluruh server / Kapan: Selalu, Saat banyak pemain berkumpul - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Jaringan: ganti pembagian beban per paket dengan pembagian per koneksi (ECMP dan LAG dengan hash alamat dan port). Server/OS: pakai RACK (deteksi packet loss berbasis waktu yang tahan terhadap urutan paket tertukar; jika DSACK menunjukkan retransmisi yang tidak perlu, toleransi urutan tertukar diperlebar otomatis), periksa tingkat reordering yang diestimasi Linux secara otomatis untuk tiap koneksi (nilai reordering di ss -ti, nilai awalnya tcp_reordering=3). - Di grafik: Selalu tinggi sejak awal (Jumlah deteksi urutan paket tertukar, jumlah DSACK yang diterima) - Yang diperiksa: Periksa TcpExtTCPSACKReorder dan TcpExtTCPTSReorder (jumlah deteksi urutan paket tertukar) serta TcpExtTCPDSACKRecv di nstat; per koneksi, periksa reordering (ditampilkan jika nilainya selain 3) dan reord_seen di ss -ti. Di packet capture, pakai filter Wireshark tcp.analysis.out_of_order - Cocok jika: Counter urutan tertukar dan DSACK terus naik di jam berapa pun, dan nilai reordering pada koneksi yang melewati rute atau perangkat tertentu lebih besar dari 3. Di capture sisi penerima, paket belakang datang lebih dulu dan paket depan pun segera menyusul - Tidak cocok jika: Counter urutan tertukar tidak berubah, tetapi TcpExtTCPLostRetransmit naik: packet loss sungguhan. DSACK hanya naik saat RTT melonjak: lebih mungkin “Retransmisi yang tidak perlu akibat lonjakan latensi” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection](https://www.rfc-editor.org/rfc/rfc2991) · IETF · Jika rute dibagi per paket, urutan paket berubah, dan jika 3 paket belakang atau lebih datang lebih dulu, TCP melakukan fast retransmit yang tidak perlu - [RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm](https://www.rfc-editor.org/rfc/rfc2992) · IETF · ECMP yang memilih rute dari hash field header yang mengidentifikasi flow (pembagian beban per flow) - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Fast retransmit pada duplicate ACK ketiga - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · RACK mendeteksi packet loss berbasis waktu sehingga tahan terhadap urutan paket tertukar, dan memperlebar batas waktu toleransi urutan tertukar (reo_wnd) jika menerima DSACK - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Nilai awal tcp_reordering 3 (disesuaikan otomatis per koneksi hingga tcp_max_reordering), pengaturan RACK di tcp_recovery - [misc/ss.c](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/misc/ss.c?h=v6.12.0) · iproute2 · ss -ti menampilkan reordering:nilai jika nilai reordering koneksi berbeda dari default 3, dan reord_seen:jumlah jika koneksi pernah mengalami urutan paket tertukar - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPSACKReorder, TcpExtTCPTSReorder (urutan paket tertukar terdeteksi), TcpExtTCPDSACKRecv (jumlah DSACK yang diterima), TcpExtTCPLostRetransmit (paket yang dikirim ulang hilang lagi) - [include/uapi/linux/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/tcp.h?h=v6.12) · Linux kernel · tcpi_reord_seen di tcp_info: berapa kali koneksi mengalami urutan paket tertukar - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Filter tampilan tcp.analysis.out_of_order #### rt-ack-path · ACK terlambat atau hilang (upload penuh) · ACK path congestion on asymmetric links Data sudah tiba dengan baik, tetapi jika ACK “sudah diterima” tertunda atau hilang di antrean upload yang penuh, pengirim menganggap data hilang lalu mengirimnya ulang. - Mengapa → Akibatnya → Di layar: Upload di rumah penuh oleh upload video atau backup cloud → ACK tertunda ratusan ms di antrean router, atau dibuang saat antrean meluap → Paket game dari server umumnya datang tepat waktu. Input Anda yang menumpuk di antrean upload yang sama terlambat terkirim sehingga terjadi input lag dan rubber banding, sesekali disertai retransmisi yang tidak perlu - Gejala: Input lag, Rubber banding / Faktor: Latensi, Packet loss - Siapa: Satu rumah / Kapan: Sesekali secara acak, Jam sibuk malam hari - Penanggung jawab utama: Pihak Eksternal (Pihak Eksternal) / Turut terlibat: Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Tampilkan status jaringan di layar saat ping melonjak, dan tampilkan petunjuk “periksa program yang sedang melakukan upload”. - Tugas Pihak Eksternal: Imbau pemain untuk memperpendek antrean upload dengan SQM di router, memprioritaskan paket kecil (ACK), dan membatasi kecepatan upload (upload video, backup cloud). - Kisaran angka: ACK yang datang belakangan ikut mengonfirmasi data yang sudah dikonfirmasi ACK sebelumnya, jadi beberapa ACK yang hilang biasanya tidak masalah. Masalahnya ada pada ACK yang tertunda di antrean. - Di grafik: Hanya sebagian yang tinggi (RTT (ping) per koneksi) - Yang diperiksa: Dari PC pemain, bandingkan ping ke server game saat upload (upload video, backup cloud) berjalan dan saat dihentikan. Di server, periksa rtt koneksi pemain itu dengan ss -ti - Cocok jika: Ping naik ke ratusan ms hanya selama upload, disertai input lag dan rubber banding, lalu segera pulih setelah upload dihentikan. Dari sisi server, rtt koneksi itu juga naik pada saat yang sama - Tidak cocok jika: Packet loss dan latensi muncul tanpa terkait upload: lebih mungkin “Packet loss di jalur nirkabel” atau penyebab di sisi rute. Hanya arah server ke pemain yang lambat dan tidak terkait upload: lebih mungkin “Antrean bottleneck meluap” - Sarana pemeriksaan: Lingkungan pemain sendiri - Sumber: - [RFC 3449: TCP Performance Implications of Network Path Asymmetry](https://www.rfc-editor.org/rfc/rfc3449) · IETF · Di jalur asimetris dengan upload sempit, ACK yang tertunda atau hilang menurunkan performa TCP; ACK bersifat kumulatif sehingga ACK berikutnya menggantikan yang hilang; solusi seperti penjadwalan yang memprioritaskan ACK - [Smart Queue Management](https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/) · Bufferbloat.net · Menjaga antrean router tetap pendek dengan pengelolaan antrean dan shaping - [tc-cake(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-cake.8.html) · iproute2 · CAKE memisahkan flow dan meminimalkan latensi untuk flow yang jarang mengirim (sparse flow) - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rtt (rata-rata round-trip time) dan rttvar (deviasi) di ss -i #### rt-rto-setting · Pengaturan RTO tidak sesuai dengan lingkungan · RTO min too low or too high Jika nilai minimum RTO diturunkan terlalu rendah, keterlambatan kecil saja sudah memicu retransmisi yang tidak perlu. Sebaliknya, nilai default (200 ms) terlalu panjang untuk game sehingga setiap kali paket hilang, game berhenti lama. - Mengapa → Akibatnya → Di layar: Nilai minimum RTO diturunkan drastis untuk keperluan data center, atau nilai default dipakai apa adanya di jalur internet → Terlalu rendah: retransmisi membanjir bahkan saat latensi naik sesaat. Terlalu tinggi: setiap packet loss harus ditunggu lama → Dengan nilai default, satu kali packet loss membuat freeze ratusan ms lalu fast forward; jika diturunkan terlalu rendah, freeze memendek, tetapi retransmisi yang tidak perlu melonjak dan memboroskan bandwidth - Gejala: Freeze, Fast forward, Input lag / Faktor: Latensi - Siapa: Seluruh server / Kapan: Selalu - Penanggung jawab utama: Infrastruktur server (Tim Infrastruktur) / Turut terlibat: Pengembangan server (Tim Pengembang Game) - Tugas Tim Pengembang Game: Di Linux 6.15 ke atas, pertimbangkan menurunkan batas atas RTO untuk koneksi game dengan TCP_RTO_MAX_MS (waktu sampai koneksi menyerah juga ikut memendek, jadi tentukan sekalian waktu deteksi terputus dengan TCP_USER_TIMEOUT), turunkan nilai minimum RTO hanya untuk koneksi internal antarserver dengan opsi socket TCP_RTO_MIN_US (6.15 ke atas), pertimbangkan opsi socket TCP_THIN_LINEAR_TIMEOUTS agar RTO berturut-turut tidak berlipat dua khusus pada koneksi game. - Tugas Tim Infrastruktur: Turunkan rto_min per rute hanya untuk koneksi internal antarserver, pertahankan nilai default di jalur internet dan lengkapi dengan RACK-TLP serta pengaturan thin stream (tcp_thin_linear_timeouts). - Kisaran angka: RTO di Linux = round-trip time + max(200 ms, deviasi RTT × 4). Nilainya berlipat dua setiap kali gagal, maksimal 120 detik. Di Linux 6.15 ke atas, batas atas ini bisa diturunkan hingga 1 detik dengan TCP_RTO_MAX_MS. - Di grafik: Selalu tinggi sejak awal (RTO per koneksi, jumlah RTO yang tidak perlu) - Yang diperiksa: Periksa pengaturan nilai minimum RTO di server (rto_min di ip route show; di Linux 6.11 ke atas, sysctl net.ipv4.tcp_rto_min_us) serta rto dan rtt di ss -ti, lalu periksa kenaikan TcpExtTCPSpuriousRTOs di nstat - Cocok jika: Di server yang nilai minimumnya diturunkan, rto koneksi internet menempel ketat pada rtt dan TcpExtTCPSpuriousRTOs naik banyak. Dengan nilai default, rto koneksi game 200 ms atau lebih di atas rtt, dan setiap packet loss membuat game berhenti selama itu - Tidak cocok jika: rto sesuai perhitungan default (sekitar rtt + 200 ms) dan RTO yang tidak perlu juga sedikit, tetapi jedanya sangat lama: lebih mungkin packet loss berturut-turut atau cara pemulihannya (“Pemulihan lambat pada thin stream”, “Opsi TCP dihapus oleh perangkat perantara”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · RTO = SRTT + max(G, 4·RTTVAR), minimum yang direkomendasikan 1 detik, berlipat dua setiap kali gagal, dan jika ada nilai maksimum, nilainya minimal 60 detik - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_RTO_MIN di Linux 200 ms, TCP_RTO_MAX 120 detik - [net/ipv4/tcp_input.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_input.c?h=v6.12) · Linux kernel · RTO di Linux adalah SRTT + rttvar, dan rttvar tidak pernah turun di bawah nilai minimum RTO (default 200 ms) - [tcp: add the ability to control max RTO](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54a378f43425085d0684679d99735696b69165bc) · Linux kernel · Penambahan opsi socket TCP_RTO_MAX_MS (1–120 detik), mulai Linux 6.15 - [tcp: add sysctl_tcp_rto_min_us](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f086edef71be7174a16c1ed67ac65a085cda28b1) · Linux kernel · Penambahan tcp_rto_min_us, nilai minimum RTO default untuk seluruh server, mulai Linux 6.11 - [tcp: support TCP_RTO_MIN_US for set/getsockopt use](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f38805c5d26fe4af97837c10d58074a7496638bf) · Linux kernel · Penambahan opsi socket TCP_RTO_MIN_US untuk menentukan nilai minimum RTO per socket, mulai Linux 6.15 - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Default tcp_rto_min_us 200000 (opsi rute rto_min dan opsi socket TCP_RTO_MIN_US lebih diutamakan), tcp_rto_max_ms 1.000–120.000 (default 120.000), tcp_thin_linear_timeouts - [ip-route(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ip-route.8.html) · iproute2 · Opsi rto_min per rute: nilai minimum RTO yang dipakai saat berkomunikasi dengan tujuan itu - [Thin-streams and TCP](https://docs.kernel.org/networking/tcp-thin.html) · Linux kernel · TCP_THIN_LINEAR_TIMEOUTS bisa mematikan exponential backoff khusus untuk koneksi thin stream - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_USER_TIMEOUT: lama menunggu data yang belum dikonfirmasi sebelum koneksi ditutup - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rto (ms) dan rtt di ss -i - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPSpuriousRTOs: RTO tidak perlu yang dideteksi F-RTO #### rt-thin · Pemulihan lambat pada thin stream · Thin streams fall back to RTO Jika game mengirim paket kecil secara jarang-jarang, RTO datang lebih dulu sebelum “3 paket susulan” terkumpul. Untuk packet loss yang sama, game berhenti jauh lebih lama daripada transfer data besar. - Mengapa → Akibatnya → Di layar: Interval paket sekitar 100 ms sehingga hanya ada sedikit paket yang belum mendapat ACK (in-flight) → Butuh lebih dari 300 ms untuk mengumpulkan 3 duplicate ACK sehingga RTO (ping + 200 ms) terpicu lebih dulu, dan berlipat dua jika packet loss terjadi berturut-turut → Satu kali packet loss membuat freeze sekitar 0,3 detik; jika paket yang dikirim ulang juga hilang, freeze hampir 1 detik lalu fast forward - Gejala: Freeze, Fast forward / Faktor: Packet loss, Stall - Siapa: Hanya saya, Seluruh server / Kapan: Sesekali secara acak - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: aktifkan TCP_NODELAY (jika Nagle aktif, RACK tidak punya paket susulan sebagai dasar penilaian), kirim paket real-time lewat UDP dengan retransmisi buatan sendiri. Klien: aktifkan TCP_NODELAY, kirim paket real-time dengan cara yang sama seperti server (UDP). - Tugas Tim Infrastruktur: Pakai RACK-TLP (default di Linux terbaru), aktifkan tcp_thin_linear_timeouts agar RTO berturut-turut tidak berlipat dua. - Kisaran angka: Dengan interval paket 100 ms dan ping 60 ms, fast retransmit butuh sekitar 360 ms (sampai 3 paket berikutnya tiba dan konfirmasinya kembali), sedangkan RTO sekitar 260 ms. Dengan RACK, paket langsung dikirim ulang di sekitar 160 ms, saat konfirmasi paket berikutnya kembali. Jika interval paket lebih dari 200 ms, RACK pun tidak lebih cepat daripada RTO. - Di grafik: Kosong lalu datang sekaligus (Volume terima per koneksi, jumlah RTO habis) - Yang diperiksa: Bandingkan kenaikan TcpExtTCPTimeouts (RTO habis), TcpExtTCPFastRetrans (fast retransmit), serta TcpExtTCPLossProbes dan TcpExtTCPLossProbeRecovery (TLP) di nstat, lalu periksa rto dan backoff koneksi game dengan ss -ti. Periksa juga nilai net.ipv4.tcp_recovery, tcp_early_retrans, dan tcp_sack di server - Cocok jika: Di antara retransmisi, RTO habis lebih banyak daripada fast retransmit, dan koneksi game sering menunjukkan backoff lebih dari 0 (sedang mengalami RTO). Volume terima 0 selama koneksi berhenti, lalu datang sekaligus saat pulih - Tidak cocok jika: Transfer data besar di server yang sama juga berhenti sama lamanya: masalah packet loss yang tidak terkait pola trafik koneksi. Terpusat pada koneksi tanpa SACK atau timestamp: lebih mungkin “Opsi TCP dihapus oleh perangkat perantara” - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: Linux dulu juga punya opsi retransmisi pada 1 duplicate ACK untuk thin stream (tcp_thin_dupack), tetapi opsi ini dihapus pada 2017, dan sekarang perannya digantikan oleh RACK. Jika Nagle aktif (TCP_NODELAY nonaktif), pengirim tidak mengirim paket baru selama menunggu konfirmasi paket yang hilang, sehingga RACK tidak punya paket susulan sebagai dasar penilaian dan koneksi harus menunggu sampai RTO. - Sumber: - [Thin-streams and TCP](https://docs.kernel.org/networking/tcp-thin.html) · Linux kernel · Thin stream yang mengirim secara jarang-jarang seperti game tidak memicu fast retransmit dengan baik sehingga bergantung pada timeout yang panjang; batasnya adalah kurang dari 4 paket yang belum mendapat ACK (in-flight) - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Fast retransmit pada duplicate ACK ketiga - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · RACK menilai packet loss dari terkirimnya paket yang dikirim belakangan; waktu tunggu TLP adalah 2·SRTT (ditambah kelonggaran delayed ACK jika hanya ada satu paket yang belum dikonfirmasi) - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_RTO_MIN 200 ms, penentuan thin stream (kurang dari 4 paket in-flight), dan 6 kali percobaan ulang linear - [tcp: remove thin_dupack feature](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a7f6009441144783e5925551c72e3f2e1b0839b) · Linux kernel · thin_dupack dihapus pada Januari 2017 (Linux 4.11), disertai penjelasan bahwa perannya digantikan oleh RACK - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_thin_linear_timeouts: pada thin stream, RTO tidak digandakan hingga maksimal 6 kali percobaan (default nonaktif) - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_NODELAY mematikan algoritma Nagle - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Nama counter yang ditampilkan nstat: TCPTimeouts, TCPFastRetrans, TCPLossProbes, TCPLossProbeRecovery - [net/ipv4/tcp_timer.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · TCPTimeouts naik saat timer retransmisi (RTO) habis - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPFastRetrans (retransmisi di luar state Loss), TcpExtTCPLossProbes (TLP dikirim), TcpExtTCPLossProbeRecovery (packet loss dipulihkan oleh TLP) - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rto (ms) dan backoff (berapa kali RTO digandakan) di ss -i #### rt-sack-stripped · Opsi TCP dihapus oleh perangkat perantara · Middlebox strips TCP options Jika sebagian firewall atau perangkat akselerator menghapus atau mengubah opsi TCP, saat beberapa paket hilang, pemulihannya hanya satu paket per round trip, atau window (jumlah yang bisa dikirim sekaligus) mengecil sehingga koneksi melambat. - Mengapa → Akibatnya → Di layar: “TCP normalization” di firewall atau perangkat akselerator lama menghapus opsi SACK, timestamp, dan window scaling → Jika beberapa paket hilang, pemulihannya satu paket per round trip, dan window dibatasi 64 KB → Freeze di setiap packet loss jauh lebih lama (tanpa SACK, RACK-TLP juga tidak bisa dipakai), lalu fast forward setelah pulih. Transfer data besar seperti patch juga lambat - Gejala: Freeze, Fast forward / Faktor: Stall, Latensi - Siapa: Wilayah/ISP tertentu, Seluruh server / Kapan: Selalu - Penanggung jawab utama: Infrastruktur jaringan (Tim Infrastruktur) / Turut terlibat: Infrastruktur server (Tim Infrastruktur) - Tugas Tim Infrastruktur: Jaringan: matikan pengaturan TCP normalization di perangkat terkait, periksa juga pengacakan nomor urut di firewall, bandingkan opsi di SYN lewat packet capture di kedua ujung. Server/OS: periksa di ss -ti apakah koneksi tanpa tanda sack atau wscale terpusat pada rute tertentu (PC Windows bisa tidak memakai ts tergantung pengaturannya, jadi jika hanya ts yang tidak ada, itu bisa normal), pastikan net.ipv4.tcp_sack di server bernilai 1. - Di grafik: Selalu tinggi sejak awal (Jumlah pemulihan yang dimulai tanpa SACK (TcpExtTCPRenoRecovery)) - Yang diperiksa: Periksa di ss -ti apakah setiap koneksi menampilkan sack dan wscale, lalu periksa rasio TcpExtTCPRenoRecovery (pemulihan yang dimulai tanpa SACK) terhadap TcpExtTCPSackRecovery serta TcpExtTCPSACKDiscard (jumlah blok SACK yang dibuang karena tidak konsisten) di nstat. Untuk rute yang dicurigai, capture SYN di kedua ujung lalu bandingkan opsinya (tcp.options.sack_perm di Wireshark dan sejenisnya) - Cocok jika: Hanya koneksi yang melewati rute atau perangkat tertentu yang tidak memiliki sack dan wscale, dan porsi TcpExtTCPRenoRecovery tinggi. Opsi SACK-permitted yang ada di SYN saat dikirim tidak ada lagi di SYN saat diterima. Jika penyebabnya pengacakan nomor urut, opsinya masih ada, tetapi TcpExtTCPSACKDiscard naik - Tidak cocok jika: sack tidak ada di semua koneksi: periksa nilai net.ipv4.tcp_sack di server lebih dulu. Opsi utuh dan TcpExtTCPSACKDiscard juga tidak berubah: pemulihan lambat karena sebab lain (“Pemulihan lambat pada thin stream”) - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Pelajari lebih lanjut: SACK bisa rusak walaupun opsinya masih ada. Jika pengacakan nomor urut (sequence randomization) di firewall hanya mengubah nomor urut di header dan membiarkan nomor di dalam SACK, pengirim membuang SACK yang tidak konsisten itu. Hasilnya sama jika tcp_sack=0 pernah diatur di server saat masalah keamanan SACK tahun 2019 lalu terlupakan. - Sumber: - [RFC 2018: TCP Selective Acknowledgment Options](https://www.rfc-editor.org/rfc/rfc2018) · IETF · Tanpa SACK, ACK kumulatif saja hanya bisa memberi tahu satu paket yang hilang per round trip - [RFC 7323: TCP Extensions for High Performance](https://www.rfc-editor.org/rfc/rfc7323) · IETF · Tanpa opsi window scaling, window maksimal 2^16 = 64 KiB - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · RACK-TLP wajib memakai SACK - [net/ipv4/tcp_output.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_output.c?h=v6.12) · Linux kernel · TLP di Linux hanya dijadwalkan pada koneksi yang memakai SACK - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Default tcp_sack 1 (aktif) - [misc/ss.c](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/misc/ss.c?h=v6.12.0) · iproute2 · ss -ti menampilkan ts, sack, dan wscale:kirim,terima sesuai opsi yang dipakai koneksi - [tcp: limit payload size of sacked skbs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b4929f65b0d8249f19a50245cd88ed1a2f78cff) · Linux kernel · Commit perbaikan kerentanan penanganan SACK tahun 2019 (CVE-2019-11477) - [Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service vulnerabilities (NFLX-2019-001)](https://raw.githubusercontent.com/Netflix/security-bulletins/master/advisories/third-party/2019-001.md) · Netflix · Saat itu tcp_sack=0 (mematikan pemrosesan SACK) dianjurkan sebagai mitigasi sementara - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPRenoRecovery (pemulihan dimulai tanpa SACK), TcpExtTCPSackRecovery (pemulihan dimulai dengan SACK), TcpExtTCPSACKDiscard (jumlah blok SACK yang tidak valid) - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Filter tampilan tcp.options.sack_perm (opsi SACK-permitted di SYN) #### rt-zero-window · Zero window (jeda yang terlihat seperti retransmisi) · Zero window, often mistaken for retransmission Jika program penerima tidak membaca socket tepat waktu sehingga buffer penuh, pengirim menghentikan pengiriman dan hanya mengirim zero window probe. Koneksinya sendiri baik-baik saja. - Mengapa → Akibatnya → Di layar: Frame di klien berhenti atau thread server tertahan sehingga socket tidak terbaca → Receive window menjadi 0 sehingga pengirim berhenti mengirim dan hanya mengirim probe (intervalnya makin panjang) → Freeze lalu fast forward. Packet capture menunjukkan “ZeroWindow” dan tidak ada packet loss - Gejala: Freeze, Fast forward / Faktor: Stall - Siapa: Hanya saya, Seluruh server / Kapan: Saat banyak pemain berkumpul, Sesekali secara acak - Penanggung jawab utama: Pengembangan klien (Tim Pengembang Game) / Turut terlibat: Pengembangan server (Tim Pengembang Game), Infrastruktur server (Tim Infrastruktur) - Tugas Tim Pengembang Game: Periksa dulu sisi yang mengirim ZeroWindow di packet capture (sisi yang tidak sempat membaca socket), terus baca data jaringan di thread terpisah, atur ukuran buffer terima yang sesuai. Klien: atasi penyebab frame berhenti seperti loading dan GC. Server: atasi penyebab thread pembaca socket tertahan. - Tugas Tim Infrastruktur: Tambahkan TcpExtTCPToZeroWindowAdv di nstat server (berapa kali server memberi tahu receive window 0) ke monitoring (jika naik, masalahnya di sisi server, jadi teruskan ke Pengembangan server), sediakan packet capture sisi server. - Di grafik: Kosong lalu datang sekaligus (Volume terima per koneksi, jumlah zero window) - Yang diperiksa: Di packet capture, cari sisi yang memberi tahu window 0 dengan filter Wireshark tcp.analysis.zero_window. Di nstat server, periksa terpisah TcpExtTCPToZeroWindowAdv (server memberi tahu window 0) dan TcpExtTCPWinProbe (server mengirim probe karena window pihak lawan 0), lalu periksa Recv-Q socket server (byte di ss yang belum dibaca program) - Cocok jika: Selama koneksi berhenti, tidak ada retransmisi, hanya paket zero window dan probe yang lalu-lalang. TcpExtTCPToZeroWindowAdv di server atau Recv-Q socket server naik: server tidak membaca tepat waktu. TcpExtTCPWinProbe naik: klien tidak membaca tepat waktu - Tidak cocok jika: Tidak ada zero window di capture dan data yang sama dikirim ulang: lebih mungkin packet loss atau retransmisi yang tidak perlu - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Kasus nyata: roblox-2021 - Sumber: - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Jika receive window 0, pengirim mengirim zero window probe dan interval probe diperpanjang secara eksponensial - [7.5. TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) · Wireshark · TCP ZeroWindow: paket tempat penerima memberi tahu window 0 sehingga pengirim berhenti mengirim - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Filter tampilan tcp.analysis.zero_window, tcp.analysis.zero_window_probe - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpExtTCPToZeroWindowAdv: berapa kali receive window diberitahukan berubah dari nilai lebih dari 0 menjadi 0 - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Nama counter yang ditampilkan nstat: TCPToZeroWindowAdv, TCPWinProbe - [net/ipv4/tcp_output.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_output.c?h=v6.12) · Linux kernel · TCPWinProbe: naik setiap kali probe (tcp_send_probe0) dikirim saat receive window pihak lawan 0 - [net/ipv4/tcp_diag.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Untuk socket yang terhubung, Recv-Q di ss adalah jumlah byte yang sudah diterima tetapi belum dibaca program #### rt-syn · Retransmisi permintaan koneksi (SYN) · SYN retransmission on connect Jika permintaan koneksi hilang karena antrean koneksi (backlog) meluap atau diblokir firewall, OS klien mengirimnya ulang mulai 1 detik kemudian dengan interval yang makin panjang. - Mengapa → Akibatnya → Di layar: Lonjakan koneksi tepat setelah maintenance membuat antrean koneksi server meluap, atau firewall dan proteksi DDoS membuang SYN → OS klien mengirim ulang SYN mulai 1 detik kemudian dengan interval yang sudah ditentukan (Linux versi lama: 1 detik → 2 detik → 4 detik) → Setelah tombol masuk ditekan, keterlambatannya pas dalam hitungan detik seperti 1 atau 3 detik, dan jika terus gagal, pemain tidak bisa masuk atau mengalami loading tanpa henti - Gejala: Tidak bisa masuk / loading tanpa henti / Faktor: Packet loss - Siapa: Seluruh server, Wilayah/ISP tertentu / Kapan: Tepat setelah login atau maintenance - Penanggung jawab utama: Pengembangan server (Tim Pengembang Game) / Turut terlibat: Infrastruktur server (Tim Infrastruktur), Infrastruktur jaringan (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game) - Tugas Tim Pengembang Game: Server: perbesar argumen backlog pada listen (bersama somaxconn), pastikan server game memanggil accept tepat waktu, gunakan sistem antrean login. Klien: perpanjang interval percobaan ulang koneksi (disebar secara acak). - Tugas Tim Infrastruktur: Server/OS: periksa apakah antrean koneksi server meluap lewat TcpExtListenOverflows dan TcpExtListenDrops di nstat serta peringatan “Possible SYN flooding” di log, perbesar somaxconn (bersama argumen listen), aktifkan SYN cookie. Jaringan: longgarkan batas SYN di firewall dan proteksi DDoS. - Kisaran angka: Di Linux (termasuk Android), retransmisi SYN pertama terjadi setelah 1 detik. Kernel lama kemudian menggandakan jedanya setiap kali dan mengirim ulang pada detik ke-1, 3, 7, 15 …, sedangkan kernel 6.5 ke atas mengirim ulang lima kali pada detik ke-1, 2, 3, 4, dan 5, lalu menggandakannya (7, 11, 19 detik …) (tcp_syn_linear_timeouts=4). Ponsel Android sering tetap memakai kernel bawaan saat rilis walaupun OS-nya diperbarui, sehingga perilakunya bisa berbeda antarperangkat walaupun versi Android-nya sama. Apa pun kernelnya, jika semua percobaan gagal, OS menyerah setelah sekitar 2 menit. Windows mulai dari 1 atau 3 detik tergantung versi dan pengaturan, dan mengirim ulang 2–4 kali, sehingga menyerah dalam 20–30 detik (nilai di PC tersebut bisa dilihat di Max SYN Retransmissions pada netsh int tcp show global). - Di grafik: Melonjak tepat setelah server dibuka (Jumlah percobaan koneksi, jumlah kejadian antrean koneksi meluap) - Yang diperiksa: Di nstat server, periksa TcpExtListenOverflows dan TcpExtListenDrops serta peringatan “Possible SYN flooding on port” di dmesg, lalu periksa dengan ss -lnt apakah Recv-Q socket listen (jumlah koneksi yang menunggu accept) mencapai Send-Q (batas backlog). Pastikan lewat capture di sisi server apakah SYN tiba dan apakah SYN-ACK dikirim balik - Cocok jika: Saat lonjakan koneksi tepat setelah maintenance, TcpExtListenOverflows naik dan Recv-Q menempel di Send-Q. Di capture, SYN dari klien yang sama datang lagi dengan interval hitungan detik, tetapi server tidak merespons - Tidak cocok jika: SYN tidak sampai ke server dan counter server juga tidak berubah: firewall atau proteksi DDoS di depan yang membuangnya, jadi periksa batas SYN dan log drop di perangkat itu. Server sudah mengirim SYN-ACK, tetapi koneksi tetap lambat: packet loss di arah balik - Sarana pemeriksaan: Tools infrastruktur (tanpa perlu kode game) - Sumber: - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · RTO pertama TCP_TIMEOUT_INIT = 1 detik (nilai awal dari RFC 6298) - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · RTO awal 1 detik, berlipat dua setiap kali retransmisi - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Default tcp_syn_retries 6, default tcp_syn_linear_timeouts 4 (RTO SYN 1, 1, 1, 1, 1, 2, 4 …), retransmisi terakhir pada detik ke-67 dan menyerah pada detik ke-131, default somaxconn 4.096, default tcp_syncookies 1 - [tcp: make the first N SYN RTO backoffs linear](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccce324dabfe2143519daf50ed8b1ef1d0c542f7) · Linux kernel · Commit yang mengubah bagian awal retransmisi SYN menjadi interval tetap, mulai Linux 6.5 (default 4 mengikuti cara macOS dan iOS) - [Android common kernels](https://source.android.com/docs/core/architecture/kernel/android-common) · Android (Google) · Common kernel 5.10–6.18 didukung bersamaan, dan kernel untuk platform sebelumnya (misalnya android14-6.1) bisa dipakai untuk peluncuran atau upgrade perangkat Android baru - [TcpMaxConnectRetransmissions](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938209(v=technet.10)) · Microsoft · Default Windows versi lama: 2 kali retransmisi SYN, dimulai dengan tunggu 3 detik lalu berlipat dua, dan setelah yang terakhir menunggu dua kali lipat lagi sebelum menyerah (3+6+12=21 detik) - [TCP/IP connectivity issues troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) · Microsoft · Jumlah retransmisi SYN berbeda tiap OS dan bisa dilihat di Max SYN Retransmissions pada netsh int tcp show global - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Argumen backlog pada listen dipotong ke somaxconn (default 4.096 sejak Linux 5.4, sebelumnya 128) - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · Jika antrean accept penuh, SYN dibuang dan TcpExtListenOverflows serta TcpExtListenDrops naik bersamaan; TcpExtTCPSynRetrans - [net/ipv4/tcp_input.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_input.c?h=v6.12) · Linux kernel · Pesan log “Possible SYN flooding on port …” - [net/ipv4/tcp_diag.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_diag.c?h=v6.12) · Linux kernel · Untuk socket listen, Recv-Q di ss adalah jumlah koneksi yang menunggu accept, dan Send-Q adalah batas backlog ## Sumber per bab ### #l-client-game - [Slow rendering](https://developer.android.com/topic/performance/vitals/render) · Android (Google) · Untuk mencapai 60 FPS, setiap frame harus digambar dalam 16 ms; frame yang terlambat dilewati dan terlihat sebagai patah-patah - [Interpolation and extrapolation (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/interpolation.html) · Unity · Interpolasi yang menyambung gambar di antara snapshot yang datang berselang, ekstrapolasi yang melanjutkan gerakan dengan arah dan kecepatan yang sama saat data terlambat, serta batas atas ekstrapolasi - [Introduction to prediction (Netcode for Entities 6.5)](https://docs.unity3d.com/Packages/com.unity.netcode@6.5/manual/intro-to-prediction.html) · Unity · Prediksi, yaitu klien bergerak lebih dulu berdasarkan input sendiri tanpa menunggu hasil dari server, lalu dikoreksi jika berbeda dari server - [Peeking into VALORANT's Netcode](https://technology.riotgames.com/news/peeking-valorants-netcode) · Riot Games · Meratakan data yang datang tidak beraturan dengan buffer membuat gerakan mulus, tetapi latensinya bertambah sebanyak itu, dan jika tebakan meleset, karakter melompat atau meluncur - [Garbage collection modes](https://docs.unity3d.com/Manual/performance-incremental-garbage-collection.html) · Unity · Lonjakan GC pada simulasi: jika GC inkremental dimatikan, main thread berhenti selama seluruh heap diperiksa sehingga melewati batas frame 16 ms - [Scripting.GarbageCollector.CollectIncremental](https://docs.unity3d.com/ScriptReference/Scripting.GarbageCollector.CollectIncremental.html) · Unity · Time slice GC inkremental 3 ms pada simulasi: nilai default incrementalTimeSliceNanoseconds adalah 3 ms - [Shader loading](https://docs.unity3d.com/Manual/shader-loading.html) · Unity · Loading area baru pada simulasi: saat varian shader pertama kali dipakai, game bisa berhenti sejenak karena driver membuatnya untuk GPU - [Frame Pacing library](https://developer.android.com/games/sdk/frame-pacing) · Android (Google) · Batas V-Sync pada simulasi: layar 60 Hz menampilkan frame sebelumnya sekali lagi jika tidak ada frame baru - [Set fixed timestep to optimize physics simulation frequency](https://docs.unity3d.com/Manual/physics-optimization-cpu-frequency.html) · Unity · Catch-up fixed step pada simulasi: jika satu frame lebih lama dari interval step, step dijalankan beberapa kali dalam satu frame sehingga beban bertambah - [Handling variation in time](https://docs.unity3d.com/Manual/time-handling-variations.html) · Unity · Batas catch-up pada simulasi (simulasi mengizinkan hingga 5 kali per frame): Unity membatasi waktu game dalam satu frame maksimal 1/3 detik untuk mencegah lingkaran setan catch-up, dan jam game tertinggal sebanyak kelebihannya ### #l-client-os - [Multitasking](https://learn.microsoft.com/en-us/windows/win32/procthread/multitasking) · Microsoft · Multitasking preemptive yang memberi setiap thread time slice (sekitar 20 ms, tergantung OS dan CPU) lalu beralih ke thread berikutnya setelah jatahnya habis - [Scheduling Priorities](https://learn.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities) · Microsoft · Di antara thread yang siap dijalankan, thread dengan prioritas tertinggi mendapat time slice secara bergiliran (round robin) - [Priority Boosts](https://learn.microsoft.com/en-us/windows/win32/procthread/priority-boosts) · Microsoft · Menaikkan prioritas proses milik jendela di depan (foreground) setidaknya setara dengan proses di latar belakang - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · Setiap socket punya buffer terima (SO_RCVBUF), dan ukuran default serta maksimumnya ditentukan oleh pengaturan sistem - [Wi-Fi low-latency mode](https://source.android.com/docs/core/connect/wifi-low-latency) · Android (Google) · Dalam mode Wi-Fi latensi rendah di Android 10 ke atas, framework secara eksplisit mematikan hemat daya Wi-Fi (doze) saat aplikasi berada di latar depan dan layar menyala - [Cached apps freezer](https://source.android.com/docs/core/perf/cached-apps-freezer) · Android (Google) · Android 14 ke atas membekukan aplikasi berstatus cached setelah 10 detik sehingga tidak bisa memakai CPU - [Extending your app’s background execution time](https://developer.apple.com/documentation/uikit/extending-your-app-s-background-execution-time) · Apple · iOS menangguhkan aplikasi beberapa detik setelah masuk ke latar belakang - [_WDF_TIMER_CONFIG (wdftimer.h)](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdftimer/ns-wdftimer-_wdf_timer_config) · Microsoft · Timer 15,6 ms pada simulasi: interval default clock tick sistem Windows adalah 15,6 ms - [timeBeginPeriod function (timeapi.h)](https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod) · Microsoft · Timer 1 ms pada simulasi: program bisa meminta resolusi timer yang lebih tinggi dengan timeBeginPeriod - [Customize the Windows performance power slider](https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/customize-power-slider) · Microsoft · Mode hemat daya pada simulasi: mode daya Windows mengubah pengaturan daya dan CPU untuk memperpanjang daya tahan baterai dengan mengorbankan performa - [Thermal API](https://developer.android.com/games/optimize/adpf/thermal) · Android (Google) · Ponsel panas pada simulasi: perangkat hanya bisa mempertahankan performa tinggi dalam waktu terbatas, lalu terkena thermal throttling akibat panas ### #l-memory - [Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Dasar tabel skala angka: cache L1 0,5 ns, L2 7 ns, memori utama 100 ns, pulang-pergi di data center yang sama 0,5 ms, seek disk 10 ms (data tahun 2009; angka cache di tabel adalah perkiraan yang sedikit berbeda) - [Solidigm™ D7-P5520 and D7-P5620 Product Brief](https://www.solidigm.com/products/data-center/product-briefs/d7-p5520-p5620-product-brief.html) · Solidigm · Latensi 99,99% (four-nines latency) SSD NVMe server 130 µs: dasar angka pembacaan SSD dan pembacaan ulang dari swap sekitar 100 µs di tabel - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Default tcp_rto_min_us 200.000 µs: waktu tunggu minimum retransmisi TCP di Linux 200 ms (baris retransmisi TCP di tabel) - [What is NUMA?](https://docs.kernel.org/mm/numa.html) · Linux kernel · Memori di sisi CPU lain (remote) lebih lambat diakses dan bandwidth-nya lebih rendah daripada memori lokal (baris NUMA di tabel) - [JEP 439: Generational ZGC](https://openjdk.org/jeps/439) · OpenJDK · Jeda G1 beberapa ms hingga beberapa detik, jeda ZGC 1 ms atau kurang (GC seluruh heap ratusan ms hingga beberapa detik di teks utama, GC heap besar 1 detik di tabel) - [Available Collectors](https://docs.oracle.com/en/java/javase/25/gctuning/available-collectors.html) · Oracle · ZGC mengorbankan sedikit throughput agar jeda maksimum di bawah 1 ms, dan jedanya tidak bergantung pada ukuran heap - [Garbage Collector Implementation](https://docs.oracle.com/en/java/javase/25/gctuning/garbage-collector-implementation.html) · Oracle · Generational collection: minor collection yang hanya mencakup young generation berlangsung singkat, sedangkan major collection yang mencakup seluruh heap jauh lebih lama (mode generational pada simulasi GC) - [The Z Garbage Collector](https://docs.oracle.com/en/java/javase/25/gctuning/z-garbage-collector1.html) · Oracle · ZGC mengerjakan pekerjaan berat secara konkuren sehingga tidak berhenti lebih dari 1 ms, tetapi jika pengambilan kembali memori tertinggal, aplikasi bisa berhenti menunggu GC (mode konkuren pada simulasi GC) - [A Guide to the Go Garbage Collector](https://go.dev/doc/gc-guide) · Go · Fase mark GC memakai 25% CPU sehingga program melambat selama itu, dan jika alokasi banyak, goroutine tertunda karena ikut membantu GC (assist) (mode konkuren pada simulasi GC) - [Go 1.8 Release Notes](https://go.dev/doc/go1.8) · Go · Jeda GC Go biasanya kurang dari 100 µs - [Debug a memory leak in .NET](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-memory-leak) · .NET · Meskipun ada GC, kebocoran tetap terjadi jika objek yang sudah tidak diperlukan terus direferensikan - [Concepts overview](https://docs.kernel.org/admin-guide/mm/concepts.html) · Linux kernel · Jika memori kurang, kernel mengambil kembali page cache dan halaman yang bisa di-swap, dan jika masih belum cukup, OOM killer menghentikan paksa sebuah proses (simulasi kebocoran) ### #l-disk - [Exos X18 Data Sheet](https://www.seagate.com/www-content/datasheets/pdfs/exos-x18-mango-DS2045-1N-2007US-en_US.pdf) · Seagate · Pembacaan acak 4K pada HDD 7.200 rpm 170 IOPS, latensi rotasi rata-rata 4,16 ms (angka HDD sedikit di atas 150 kali di teks utama, HDD pada simulasi disk) - [D3-S4520 SSD](https://www.solidigm.com/products/data-center/d3/s4520.html) · Solidigm · Baca/tulis acak 4 KB SSD SATA maksimal 92K/48K IOPS (puluhan ribu kali untuk SSD di teks utama) - [Solidigm™ D7-P5520 and D7-P5620 Product Brief](https://www.solidigm.com/products/data-center/product-briefs/d7-p5520-p5620-product-brief.html) · Solidigm · Baca/tulis acak SSD NVMe 1.000K/200K IOPS (ratusan ribu kali di teks utama) - [Amazon EBS General Purpose SSD volumes](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) · AWS · gp3 punya baseline 3.000 IOPS; gp2 melakukan burst hingga 3.000 IOPS dengan kredit I/O, lalu turun ke performa baseline saat kreditnya habis - [Amazon EBS-optimized instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html) · AWS · Instance kecil hanya mengeluarkan performa EBS maksimum selama 30 menit sekali dalam 24 jam, lalu kembali ke performa baseline (misalnya t4g.2xlarge dengan baseline 4.000 dan maksimum 15.700 IOPS; asumsi cloud tipe burst pada simulasi disk) - [Managed disk bursting](https://learn.microsoft.com/en-us/azure/virtual-machines/disk-bursting) · Microsoft Azure · Disk dan VM kecil bisa melakukan burst dengan kredit hingga 30 menit - [Concepts overview](https://docs.kernel.org/admin-guide/mm/concepts.html) · Linux kernel · Data yang ditulis ke file masuk ke page cache lebih dulu, ditandai dirty, lalu ditulis ke disk belakangan - [Documentation for /proc/sys/vm/](https://docs.kernel.org/admin-guide/sysctl/vm.html) · Linux kernel · Jika penulisan yang tertunda mencapai dirty_ratio, proses yang menulis harus mengerjakan penulisan ke disk sendiri (batas tulis OS pada simulasi disk) - [fsync(2) — Linux manual page](https://man7.org/linux/man-pages/man2/fsync.2.html) · Linux man-pages · fsync memblokir sampai perangkat melaporkan bahwa penulisan sudah selesai ### #l-db - [How MySQL Uses Indexes](https://dev.mysql.com/doc/refman/8.4/en/mysql-indexes.html) · MySQL · Tanpa indeks, seluruh tabel dibaca mulai dari baris pertama (full table scan) - [InnoDB Locking](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking.html) · MySQL · Permintaan untuk mengubah baris yang sama menunggu sampai transaksi yang memegang row lock selesai (hot row) - [Number Of Database Connections](https://wiki.postgresql.org/wiki/Number_Of_Database_Connections) · PostgreSQL · Setelah sumber daya DB habis terpakai, menambah koneksi justru menurunkan throughput (dasar simulasi DB: jika core CPU kurang, memperbesar pool membuat semuanya melambat) - [WAL Configuration (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-configuration.html) · PostgreSQL · Checkpoint adalah pekerjaan mahal yang menulis dirty page sekaligus setiap 5 menit atau setiap 1 GB WAL secara default; penulisan disebar untuk menghindari lonjakan I/O - [Semisynchronous Replication](https://dev.mysql.com/doc/refman/8.4/en/replication-semisync.html) · MySQL · Pada replikasi asinkron, jika DB primer mati, transaksi yang sudah di-commit bisa tidak ada di DB standby (terkena rollback setelah failover) - [Log-Shipping Standby Servers (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/warm-standby.html) · PostgreSQL · Streaming replication secara default bersifat asinkron sehingga ada jeda antara commit dan saat perubahan tercermin di replika (data yang baru ditulis tidak terlihat di replika) - [Asynchronous Commit (PostgreSQL Documentation)](https://www.postgresql.org/docs/current/wal-async-commit.html) · PostgreSQL · Kompromi saat penulisan dikumpulkan lalu dituliskan belakangan: lebih cepat, tetapi perubahan terbaru hilang saat terjadi gangguan (struktur yang sama dengan server game yang menyimpan setiap beberapa menit) ### #judge - [Service Level Objectives (Site Reliability Engineering, ch. 4)](https://sre.google/sre-book/service-level-objectives/) · Google · Persentil (ke-50, ke-95, ke-99) memperlihatkan bentuk dan ekor distribusi latensi yang tidak terlihat dari rata-rata - [The Tail at Scale](https://research.google/pubs/the-tail-at-scale/) · Google · Keterlambatan panjang yang sesekali terjadi (tail latency) makin menentukan kualitas layanan yang dirasakan secara keseluruhan seiring bertambahnya skala - [RFC 3550: RTP, A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550) · IETF · Definisi dan perhitungan interarrival jitter (jitter selang waktu kedatangan) - [RFC 1812: Requirements for IP Version 4 Routers](https://www.rfc-editor.org/rfc/rfc1812) · IETF · Router harus bisa membatasi frekuensi pesan error ICMP seperti Time Exceeded, dan boleh juga membatasi Echo Reply (hati-hati saat membaca hasil mtr dan ping) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · icmp_ratelimit, icmp_ratemask: Linux secara default membatasi respons ICMP seperti Time Exceeded dan Destination Unreachable - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · Field rtt (rata-rata round-trip time)/rttvar di ss -ti - [pidstat(1) — Linux manual page](https://man7.org/linux/man-pages/man1/pidstat.1.html) · sysstat · pidstat -t: utilisasi CPU per thread - [bcc tools: runqlat examples](https://raw.githubusercontent.com/iovisor/bcc/master/tools/runqlat_example.txt) · IO Visor · Pengukuran distribusi latensi run queue (waktu thread menunggu CPU) - [RIPE Atlas documentation](https://atlas.ripe.net/docs/) · RIPE NCC · Tool synthetic monitoring publik yang menjalankan ping dan traceroute dari titik pengukuran di seluruh dunia - [GeoLite2 Free Geolocation Data](https://dev.maxmind.com/geoip/geolite2-free-geolocation-data) · MaxMind · Database publik yang memetakan alamat IP ke negara dan ASN - [View CloudWatch metrics for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · Monitoring dasar berinterval 5 menit, monitoring detail berinterval 1 menit (interval agregasi menyembunyikan lonjakan singkat) ### #l-nic - [NAPI](https://docs.kernel.org/networking/napi.html) · Linux kernel · Saat perangkat memberi tahu adanya paket baru lewat interrupt, kernel mengambil dan memprosesnya dengan NAPI; penggabungan interrupt (coalescing) biasanya dilakukan oleh perangkat - [Scaling in the Linux Networking Stack](https://docs.kernel.org/networking/scaling.html) · Linux kernel · Struktur RSS yang membagi beberapa antrean terima ke beberapa core, dengan interrupt per antrean dan pemilihan antrean lewat hash - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · Paket yang dibuang perangkat karena tidak ada buffer (rx_missed_errors) dan statistik per driver di ethtool -S - [ethtool(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ethtool.8.html) · ethtool · Mengatur dan memeriksa ring buffer (-G), interrupt coalescing (-C), hash terima (-N), dan statistik (-S) - [How to receive a million packets per second](https://blog.cloudflare.com/how-to-receive-a-million-packets/) · Cloudflare · Pengukuran yang menunjukkan bahwa satu antrean dengan satu core mentok di sekitar 350.000–430.000 paket per detik, dan untuk menerima 1 juta pps antrean dan core harus ditambah (simulasi mengasumsikan throughput per core yang lebih longgar, yaitu 700.000 pps) - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Jika instance cloud melewati batas bandwidth, PPS, atau connection tracking, trafik dimasukkan ke antrean di luar instance lalu dibuang; counter pelampauan batas ### #l-server-os - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Antrean koneksi (backlog) dan batas somaxconn (default 4.096 sejak 5.4, sebelumnya 128) - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · Jika antrean accept penuh, Linux membuang permintaan koneksi (SYN) dan menaikkan TcpExtListenOverflows - [listen function (winsock2.h)](https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen) · Microsoft · Di Windows, jika antrean penuh, klien menerima WSAECONNREFUSED - [getrlimit(2) — Linux manual page](https://man7.org/linux/man-pages/man2/getrlimit.2.html) · Linux man-pages · RLIMIT_NOFILE: batas jumlah fd yang bisa dibuka proses; jika dilewati, hasilnya EMFILE - [systemd-system.conf(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd-system.conf.5.html) · systemd · Nilai default batas fd untuk service adalah 1024:524288 (salah konfigurasi fd 1.024 pada simulasi) - [The /proc Filesystem](https://docs.kernel.org/filesystems/proc.html) · Linux kernel · OOM killer memilih proses yang akan dihentikan berdasarkan skor (badness) dari porsi pemakaian memori, dan skornya bisa disesuaikan dengan oom_score_adj - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) · Linux kernel · Jika memory.max tercapai dan memori tidak bisa dikurangi, OOM killer berjalan di dalam cgroup itu; batas CPU diatur dengan cpu.max - [proc_stat(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_stat.5.html) · Linux man-pages · steal: waktu CPU yang direbut OS lain di lingkungan virtualisasi - [Exponential Backoff And Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) · AWS · Exponential backoff saja masih membuat percobaan ulang bergerombol, dan unsur acak (jitter) perlu ditambahkan agar perebutan berkurang (cara percobaan ulang pada simulasi) ### #l-socket - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · TCP adalah byte stream yang andal dan menjaga urutan; definisi Nagle dan delayed ACK - [RFC 768: User Datagram Protocol](https://www.rfc-editor.org/rfc/rfc768) · IETF · UDP tidak menjamin pengiriman dan tidak mencegah duplikat - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Aplikasi UDP yang butuh keandalan atau urutan harus mengimplementasikannya sendiri - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · Opsi socket TCP seperti TCP_NODELAY, TCP_USER_TIMEOUT, dan keepalive - [socket(7) — Linux manual page](https://man7.org/linux/man-pages/man7/socket.7.html) · Linux man-pages · Opsi socket SO_SNDBUF, SO_RCVBUF, SO_KEEPALIVE, SO_LINGER - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Fast retransmit pada 3 duplicate ACK, dan congestion window menjadi 1 segmen setelah retransmisi oleh timer (aturan buku teks pada simulasi) - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · RACK, yang mendeteksi packet loss dari waktu pengiriman tanpa menghitung jumlah duplicate ACK - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · Rekomendasi RTO minimum 1 detik, dengan backoff yang berlipat dua setiap kali RTO habis - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Default tcp_rto_min_us di Linux 200 ms; deteksi packet loss memakai RACK (tcp_recovery) - [include/net/tcp.h (Linux v6.12)](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · Delayed ACK Linux 40 ms pada simulasi: TCP_DELACK_MIN (HZ/25 = 40 ms), maksimum TCP_DELACK_MAX (HZ/5 = 200 ms) - [Design issues - Sending small data segments over TCP with Winsock](https://learn.microsoft.com/en-us/previous-versions/troubleshoot/windows/win32/data-segment-tcp-winsock) · Microsoft · Delayed ACK Windows 200 ms pada simulasi: setiap menerima data, timer delayed ACK 200 ms dipasang, dan jika bertemu Nagle, paket kecil menunggu ACK - [RFC 896: Congestion Control in IP/TCP Internetworks](https://www.rfc-editor.org/rfc/rfc896) · IETF · Tujuan awal aturan Nagle: masalah terminal jarak jauh, ketika setiap ketukan tombol 1 byte mengirim paket 41 byte - [send(2) — Linux manual page](https://man7.org/linux/man-pages/man2/send.2.html) · Linux man-pages · Jika buffer kirim penuh, send() yang blocking tidak kembali ### #journey - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Latensi propagasi kabel serat optik 5 µs/km (5 ms satu arah untuk 1.000 km); latensi satu arah 150 ms atau kurang hampir tidak terasa bagi kebanyakan aplikasi, tetapi pekerjaan yang sangat interaktif bisa terpengaruh bahkan di bawah 100 ms - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Skala jalur internet per lokasi server pada simulasi: dari Seoul, wilayah Busan 8 ms, Tokyo 30 ms, Singapura 68 ms, AS bagian barat 124–136 ms, Eropa 234–244 ms (median pulang-pergi) - [The Internet at the Speed of Light (HotNets 2014)](https://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final111.pdf) · ACM · Pengali rute 1,5 pada simulasi: rute router sebenarnya sekitar 1,5 kali jarak garis lurus kabel serat optik (median) - [Report ITU-R M.2134: Requirements related to technical performance for IMT-Advanced radio interface(s)](https://www.itu.int/pub/R-REP-M.2134-2008) · ITU · Persyaratan latensi satu arah jalur radio LTE-Advanced kurang dari 10 ms (tanpa beban, paket kecil; nilai LTE pada simulasi mengasumsikan tambahan beban dan waktu tunggu penjadwalan) - [Report ITU-R M.2410: Minimum requirements related to technical performance for IMT-2020 radio interface(s)](https://www.itu.int/pub/R-REP-M.2410-2017) · ITU · Persyaratan latensi satu arah jalur radio 5G (IMT-2020) 4 ms (eMBB, tanpa beban) - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · Antrean router pada simulasi: pada router rumah, jika upload dan download bertumpuk, waktu antre bisa naik hingga ratusan ms (maksimal sekitar 400 ms) - [Maximum transmission unit and maximum segment size](https://developers.cloudflare.com/magic-transit/reference/mtu-mss/) · Cloudflare · Rute lewat proteksi DDoS pada simulasi: hanya trafik masuk yang melewati jaringan proteksi, sedangkan respons server langsung keluar ke internet (DSR) ### #l-home - [RFC 7567: IETF Recommendations Regarding Active Queue Management](https://www.rfc-editor.org/rfc/rfc7567) · IETF · Antrean yang menumpuk di perangkat jaringan adalah penyebab utama latensi internet; rekomendasi untuk memakai pengelolaan antrean (AQM) secara default - [RFC 8289: Controlled Delay Active Queue Management](https://www.rfc-editor.org/rfc/rfc8289) · IETF · Target waktu antre CoDel 5 ms dan interval pengamatan 100 ms (antrean SQM sekitar 5 ms pada simulasi) - [RFC 8290: The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm](https://www.rfc-editor.org/rfc/rfc8290) · IETF · FQ-CoDel: membagi antrean per flow berdasarkan alamat dan port, lalu mendahulukan flow kecil yang tidak membentuk antrean - [What Can I Do About Bufferbloat?](https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/) · Bufferbloat.net · Pakai router yang mendukung SQM seperti cake atau fq_codel, lalu sesuaikan laju SQM sambil mengukur latensi saat ada beban - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · Pengukuran 34 router rumah: waktu antre maksimal sekitar 400 ms saat upload dan download bertumpuk, median masa hidup mapping UDP 90 detik - [Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi (USENIX ATC 2017)](https://www.usenix.org/system/files/conference/atc17/atc17-hoiland-jorgensen.pdf) · USENIX · Antrean radio Wi-Fi juga menambah latensi ratusan ms saat ada beban, dan perangkat yang lambat ikut menghabiskan waktu kirim (airtime) perangkat lain - [RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) · IETF · Persyaratan timer mapping UDP di NAT (minimal 2 menit, default 5 menit atau lebih direkomendasikan) dan pembaruan oleh paket yang keluar dari dalam - [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325) · IETF · Wi-Fi memakai CSMA/CA: menunda pengiriman saat channel sibuk dan mengirim setelah backoff acak - [Resolve Wi-Fi and Bluetooth issues caused by wireless interference](https://support.apple.com/en-us/102319) · Apple · Interferensi microwave pada simulasi: microwave, Bluetooth, dan perangkat sejenis mengganggu Wi-Fi 2,4 GHz, dan pindah ke 5 GHz membantu - [RFC 9438: CUBIC for Fast and Long-Distance Networks](https://www.rfc-editor.org/rfc/rfc9438) · IETF · Pengaturan laju upload pada simulasi: CUBIC mengecilkan window kirim menjadi 0,7 kali (turun sekitar 30%) setelah packet loss, lalu memperbesarnya lagi ### #l-isp - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Latensi propagasi kabel serat optik 5 µs/km: cahaya merambat di serat optik sekitar 200.000 km per detik, sehingga pulang-pergi 1.000 km minimal 10 ms - [The Internet at the Speed of Light (HotNets 2014)](https://conferences.sigcomm.org/hotnets/2014/papers/hotnets-XIII-final111.pdf) · ACM · Rute router sebenarnya sekitar 1,5 kali jarak garis lurus kabel serat optik (median), dan ping minimum 3,2 kali batas kecepatan cahaya (sekitar 2 kali jarak garis lurus kabel serat optik) - [Azure network round-trip latency statistics](https://learn.microsoft.com/en-us/azure/networking/azure-network-latency) · Microsoft Azure · Median pulang-pergi hasil pengukuran dari Seoul: Tokyo 30 ms, AS bagian barat 124–136 ms, Eropa 234–244 ms (Korea–Eropa sekitar 2,8 kali jarak garis lurus kabel serat optik) - [AAE-1 & SMW5 cable cuts impact millions of users across multiple countries](https://blog.cloudflare.com/aae-1-smw5-cable-cuts/) · Cloudflare · Trafik Eropa–Asia umumnya melewati Mesir, dan perbaikan kabel bawah laut memakan waktu beberapa hari hingga beberapa minggu - [Quantifying the Causes of Path Inflation (SIGCOMM 2003)](https://conferences.sigcomm.org/sigcomm/2003/papers/p113-spring.pdf) · ACM · Kebijakan peering antar-ISP dan routing antardomain sangat memperpanjang rute - [Inferring Persistent Interdomain Congestion (SIGCOMM 2018)](https://www.caida.org/catalog/papers/2018_inferring_persistent_interdomain_congestion/inferring_persistent_interdomain_congestion.pdf) · ACM · Sebagian titik interkoneksi antar-ISP mengalami kongesti berulang, dengan latensi dan packet loss naik pada jam sibuk setiap hari - [RFC 4271: A Border Gateway Protocol 4 (BGP-4)](https://www.rfc-editor.org/rfc/rfc4271) · IETF · BGP, protokol untuk bertukar informasi rute internet, dengan nilai default hold time yang disarankan 90 detik - [BGP updates in 2024](https://blog.apnic.net/2025/01/07/bgp-updates-in-2024/) · APNIC · Setelah rute berubah, waktu sampai routing stabil kembali rata-rata harian 25–35 detik di IPv4 dan 40–50 detik di IPv6 - [Delayed Internet Routing Convergence (SIGCOMM 2000)](https://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-5-2.pdf) · ACM · Setelah gangguan rute, konvergensi bisa memakan waktu sampai beberapa menit, dan selama itu packet loss serta latensi meningkat (pengukuran tahun 2000) ### #l-dc-net - [High-Resolution Measurement of Data Center Microbursts (IMC 2017)](https://conferences.sigcomm.org/imc/2017/papers/imc17-final60.pdf) · ACM · Latensi end-to-end di jaringan data center kurang dari 1 ms, dan lebih dari 70% burst selesai dalam puluhan µs sehingga tidak terlihat dari utilisasi rata-rata - [Data Center TCP (DCTCP) (SIGCOMM 2010)](https://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p63.pdf) · ACM · Switch umum membagi buffer dangkal ke banyak port, dan jika banyak flow terkumpul di satu port dalam waktu singkat, buffer meluap dan paket hilang - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Nilai default jumlah entri maksimum dan timeout tabel connection tracking (UDP 30 detik, stream 120 detik, TCP established 5 hari) - [Edit attributes for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-load-balancer-attributes.html) · AWS · Idle timeout ALB default 60 detik; saat habis, load balancer menutup koneksi - [Network Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html) · AWS · Nilai default load balancer pada simulasi: NLB TCP 350 detik, UDP 120 detik (tidak bisa diubah); setelah idle, NLB diam-diam berhenti melacak flow - [Configure load balancer TCP reset and idle timeout](https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-tcp-idle-timeout) · Microsoft Azure · Idle timeout Azure Load Balancer default 4 menit - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Nilai default connection tracking security group, dan penjelasan bahwa idle timeout TCP di load balancer dan firewall umumnya 60–90 menit - [Flow-Based Sessions](https://www.juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-flow-based-session-for-srx-series-devices.html) · Juniper Networks · Firewall kantor pada simulasi: timeout sesi default firewall SRX 1.800 detik (30 menit) untuk TCP dan 60 detik untuk UDP - [An Experimental Study of Home Gateway Characteristics (IMC 2010)](https://conferences.sigcomm.org/imc/2010/papers/p260.pdf) · ACM · TCP 1 jam pada router rumah di simulasi: median mapping TCP sekitar 60 menit. Mapping UDP berbeda-beda tiap perangkat, 30–691 detik, dengan median 90 detik untuk satu arah dan sekitar 180 detik untuk dua arah - [A Multi-perspective Analysis of Carrier-Grade NAT Deployment (IMC 2016)](https://www.icir.org/vern/papers/cgn-imc16.pdf) · ACM · UDP CGNAT 30 detik dan UDP router rumah 1 menit pada simulasi: median mapping UDP CGN 35 detik di jaringan kabel dan 65 detik di jaringan seluler, 74% NAT yang diukur 1 menit atau kurang, NAT router rumah (CPE) kebanyakan 65 detik - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · Keepalive TCP pada simulasi: secara default, setelah idle 2 jam (7.200 detik), keepalive memeriksa 9 kali dengan interval 75 detik dan memutus koneksi jika tidak ada respons - [Cached apps freezer](https://source.android.com/docs/core/perf/cached-apps-freezer) · Android (Google) · Latar belakang di ponsel pada simulasi: Android 14 ke atas membekukan proses aplikasi yang masuk ke status cached setelah 10 detik - [RFC 5880: Bidirectional Forwarding Detection (BFD)](https://www.rfc-editor.org/rfc/rfc5880) · IETF · BFD, yang mendeteksi gangguan rute lebih cepat daripada Hello protokol routing yang berskala detik - [RFC 2923: TCP Problems with Path MTU Discovery](https://www.rfc-editor.org/rfc/rfc2923) · IETF · Path MTU black hole, yaitu ICMP diblokir sehingga hanya paket besar yang hilang ### #basics - [Teletraffic Engineering Handbook (ITU-D Study Group 2 Question 16/2)](https://www.itu.int/dms_pub/itu-d/opb/stg/D-STG-SG02.16.2.1-2002-PDF-E.pdf) · ITU · Rata-rata waktu tunggu M/M/1 W = A·s/(1−A): pada utilisasi 50%, 80%, dan 90%, 1, 4, dan 9 kali waktu proses. Pada utilisasi yang sama, makin banyak worker (server) dan makin merata kedatangannya, makin singkat waktu tunggunya - [CloudWatch metrics that are available for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) · AWS · CPUUtilization EC2 adalah nilai untuk seluruh instance dan diagregasi per 5 menit secara default, atau per 1 menit dengan monitoring detail - [Designs, Lessons and Advice from Building Large Distributed Systems (Jeff Dean, LADIS 2009 keynote)](https://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) · Google · Referensi memori utama 100 ns, pulang-pergi di dalam data center yang sama 500.000 ns (0,5 ms) - [ITU-T G.114: One-way transmission time](https://www.itu.int/rec/T-REC-G.114-200305-I/en) · ITU · Latensi propagasi kabel serat optik 5 µs/km (dasar perhitungan batas kecepatan cahaya) - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Nilai default Half-Life: 20 update per detik, interpolasi 100 ms. Pada 10 update per detik, interpolasi 200 ms bisa menahan satu update yang hilang - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · Default tcp_rto_min_us 200000 (200 ms) - [Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015)](https://doi.org/10.3389/fnhum.2015.00131) · Frontiers · Rata-rata waktu reaksi sederhana sekitar 231 ms (213 ms setelah dikoreksi dengan latensi perangkat) - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · Latensi di bawah 100 ms pun memengaruhi performa dalam tugas game, dan untuk pekerjaan seperti drag, sekitar 10 ms pun sudah terasa - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Pemain mahir bisa merasakan selisih sekitar 10 ms dalam blind test - [Latency and Player Actions in Online Games (Communications of the ACM, 2006)](https://web.cs.wpi.edu/~claypool/papers/precision-deadline/final.pdf) · ACM · Toleransi latensi per genre: orang pertama sekitar 100 ms, orang ketiga (RPG, MMO) sekitar 500 ms, RTS sekitar 1.000 ms - [JEP 333: ZGC: A Scalable Low-Latency Garbage Collector](https://openjdk.org/jeps/333) · OpenJDK · Pada heap 128 GB, jeda G1 rata-rata 157 ms dan maksimal 544 ms, sedangkan ZGC sekitar 1–2 ms tanpa bergantung pada ukuran heap dan data hidup - [CommonNetworkParametersExtensions (Unity Transport 2.5)](https://docs.unity3d.com/Packages/com.unity.transport@2.5/api/Unity.Networking.Transport.CommonNetworkParametersExtensions.html) · Unity · disconnectTimeoutMS: koneksi diputus jika tidak ada data yang diterima selama waktu ini (default 30.000 ms) ### #lab - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Interpolasi mulus tetapi menampilkan masa lalu, sedangkan ekstrapolasi tidak bisa mengantisipasi perubahan arah sehingga melompat jika tebakannya salah. Kesalahan prediksi dikoreksi dengan hasil dari server - [UDP vs. TCP](https://gafferongames.com/post/udp_vs_tcp/) · Gaffer On Games · Jika satu paket hilang, TCP tidak meneruskan data baru yang sudah tiba sampai paket itu dikirim ulang (biasanya 2×RTT atau lebih) - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Jika input yang belum dikonfirmasi dikirim berulang di setiap paket, tidak perlu menunggu retransmisi (dalam kasus terburuk, input sebanyak 2 detik) - [Snapshot Interpolation](https://gafferongames.com/post/snapshot_interpolation/) · Gaffer On Games · Jika update langsung digambar begitu diterima, gerakan patah-patah karena jitter; buffer interpolasi sedikit menambah latensi, tetapi membuat gerakan mulus - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Jika gerakan klien hilang atau keliru karena masalah koneksi, server mengoreksi posisinya (rubber banding) - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Budget perintah yang bertambah setiap tick membatasi perintah yang datang bergerombol. Jika terlalu ketat, pemain normal pun mengalami patah-patah - [Introducing Time Dilation (TiDi)](https://www.eveonline.com/news/view/introducing-time-dilation-tidi) · CCP Games · Desain yang memperlambat waktu game saat server kelebihan beban (Time Dilation) sehingga semuanya berjalan lebih lambat - [CommonNetworkParametersExtensions (Unity Transport 2.5)](https://docs.unity3d.com/Packages/com.unity.transport@2.5/api/Unity.Networking.Transport.CommonNetworkParametersExtensions.html) · Unity · Timeout tanpa aktivitas (inactivity timeout) yang memutus koneksi jika tidak ada data yang diterima selama waktu tertentu ### #symptoms - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Jika update hilang, objek berhenti di posisi terakhir (patah-patah) atau diekstrapolasi lalu melompat (teleport). Waktu ekstrapolasi harus dibatasi - [Understanding Networked Movement in the Character Movement Component for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-networked-movement-in-the-character-movement-component-for-unreal-engine) · Epic Games · Jika gerakan klien hilang atau berbeda dari perhitungan server, server mengirim koreksi dan mengembalikan posisinya (rubber banding) - [UDP vs. TCP](https://gafferongames.com/post/udp_vs_tcp/) · Gaffer On Games · TCP menahan data berikutnya sampai paket yang hilang dikirim ulang, lalu meneruskannya sekaligus (fast forward) - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Jika input yang tertunda datang sekaligus, beberapa frame dihitung sekaligus untuk mengejar ketertinggalan - [Introducing Time Dilation (TiDi)](https://www.eveonline.com/news/view/introducing-time-dilation-tidi) · CCP Games · Time Dilation (TiDi), yang memperlambat waktu game saat server kelebihan beban, dan fenomena pekerjaan yang tertunda beberapa detik saat kelebihan beban - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Lama buffering bergantung pada tick rate server dan frame render klien - [Using Gameplay Abilities in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-gameplay-abilities-in-unreal-engine) · Epic Games · Server bisa membatalkan ability yang sudah dijalankan lewat prediksi (aksi hilang / rollback) - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Actor yang dianggap server tidak relevan tidak direplikasi atau dihapus di klien (tidak terlihat / objek hantu) - [CommonNetworkParametersExtensions (Unity Transport 2.5)](https://docs.unity3d.com/Packages/com.unity.transport@2.5/api/Unity.Networking.Transport.CommonNetworkParametersExtensions.html) · Unity · Koneksi diputus setelah timeout tanpa aktivitas terlewati (disconnect) ### #sync - [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001)](https://web.cs.wpi.edu/~claypool/courses/4513-B03/papers/games/bernier.pdf) · Valve · Prinsip server otoritatif, prediksi sisi klien dan rekonsiliasi server, interpolasi, serta lag compensation, dan kompromi seperti “kena dari balik sudut” - [What Every Programmer Needs To Know About Game Networking](https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/) · Gaffer On Games · Perkembangan netcode dari lockstep P2P ke model klien/server, lalu ke prediksi sisi klien - [Using Gameplay Abilities in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-gameplay-abilities-in-unreal-engine) · Epic Games · Kompromi antara responsivitas dan akurasi pada Local Predicted dan Server Initiated - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Otoritas server, prediksi, buffering, hit registration dengan rewind, dan batas rewind - [NetworkTime and ticks (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/advanced-topics/networktime-ticks.html) · Unity · Cara menjadwalkan event agar diputar sesuai waktu server - [1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond](https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond) · Game Developer · Lockstep: perintah dijadwalkan dua giliran ke depan, panjang giliran mengikuti komputer paling lambat; latensi 500 ms yang stabil tidak masalah, tetapi latensi yang naik turun terasa mengganggu - [Deterministic Lockstep](https://gafferongames.com/post/deterministic_lockstep/) · Gaffer On Games · Lockstep baru maju setelah semua input tiba, dan buffer penundaan pemutaran menyerap jitter - [GGPO Rollback Networking SDK](https://www.ggpo.net/) · GGPO · Rollback: game berjalan dengan memprediksi input lawan, lalu memutar mundur dan menghitung ulang jika prediksinya salah - [8 Frames in 16ms: Rollback Networking in 'Mortal Kombat' and 'Injustice 2'](https://www.gdcvault.com/play/1025471/8-Frames-in-16ms-Rollback) · GDC · Rollback menghilangkan input delay lokal pada lockstep, dengan perhitungan ulang maksimal 8 frame - [Latency and Player Actions in Online Games (Communications of the ACM, 2006)](https://web.cs.wpi.edu/~claypool/papers/precision-deadline/final.pdf) · ACM · Latensi yang sama berdampak berbeda tergantung presisi dan tenggat waktu aksi serta sudut pandang (orang pertama, orang ketiga, omnipresent) - [Networking Overview for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-overview-for-unreal-engine) · Epic Games · Keuntungan dan beban host listen server - [Factors influencing the latency of simple reaction time (Frontiers in Human Neuroscience, 2015)](https://doi.org/10.3389/fnhum.2015.00131) · Frontiers · Waktu reaksi sederhana manusia sekitar 0,23 detik ### #partial - [Peeking into VALORANT's Netcode](https://www.riotgames.com/en/news/peeking-valorants-netcode) · Riot Games · Jika satu pemain tidak sinkron, hanya pemain itu yang dikoreksi, dan sembilan pemain lainnya tetap melihat gerakan yang mulus. Hit registration dengan rewind diberi batas - [State Synchronization](https://gafferongames.com/post/state_synchronization/) · Gaffer On Games · Paket tiba bergerombol, misalnya 2 di satu frame dan 0 di frame berikutnya, lalu diratakan oleh jitter buffer - [Source SDK 2013: player.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player.cpp) · Valve · Budget perintah yang membagi perintah yang datang bergerombol ke beberapa tick, dan efek samping pembatasan yang ketat - [Source SDK 2013: player_lagcompensation.cpp](https://raw.githubusercontent.com/ValveSoftware/source-sdk-2013/master/src/game/server/player_lagcompensation.cpp) · Valve · Batas rewind di Source engine, sv_maxunlag, default 1 detik - [A Survey and Taxonomy of Latency Compensation Techniques for Network Computer Games (ACM Computing Surveys, 2022)](https://web.cs.wpi.edu/~claypool/papers/lag-taxonomy/paper.pdf) · ACM · “Kena dari balik sudut” pada lag compensation, dan input delay yang menyamakan waktu input semua pemain - [send(2) — Linux manual page](https://man7.org/linux/man-pages/man2/send.2.html) · Linux man-pages · Saat buffer kirim penuh, send() menunggu dalam mode blocking, dan dalam mode nonblocking langsung kembali dengan EAGAIN - [Networking Overview for Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-overview-for-unreal-engine) · Epic Games · Host listen server lebih diuntungkan daripada pemain lain - [Authority (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/manual/terms-concepts/authority.html) · Unity · Otoritas terdistribusi: setiap klien memegang dan menghitung sebagian objek - [Actor Relevancy in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-relevancy-in-unreal-engine) · Epic Games · Server hanya mengirim actor yang relevan ke setiap koneksi, dan menghapusnya di klien begitu tidak relevan lagi - [NetworkConfig class (Netcode for GameObjects 2.5)](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.5/api/Unity.Netcode.NetworkConfig.html) · Unity · Pesan untuk objek yang belum di-spawn ditahan, lalu dibuang setelah waktu tertentu (SpawnTimeout) - [RFC 8085: UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085) · IETF · Paket UDP yang terfragmentasi hilang seluruhnya meskipun hanya satu fragmen yang hilang - [Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE](https://learn.microsoft.com/en-us/windows/win32/winsock/using-so-reuseaddr-and-so-exclusiveaddruse) · Microsoft · Jika dua socket berbagi port yang sama, tidak bisa dipastikan socket mana yang menerima paket - [RFC 6269: Issues with IP Address Sharing](https://www.rfc-editor.org/rfc/rfc6269) · IETF · Jika banyak pelanggan berbagi satu alamat IP, pengguna tidak bisa dibedakan hanya dari IP - [Application.runInBackground](https://docs.unity3d.com/ScriptReference/Application-runInBackground.html) · Unity · Perilaku default aplikasi yang dijeda di latar belakang - [Actor Priority in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-priority-in-unreal-engine) · Epic Games · Jika bandwidth jenuh, hanya sebagian actor yang direplikasi menurut prioritas ### #retrans - [RFC 6298: Computing TCP's Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298) · IETF · RTO = SRTT + max(G, 4·RTTVAR), nilai awal 1 detik, nilai minimum 1 detik direkomendasikan, berlipat dua setiap kali habis, batas atas (jika dipasang) minimal 60 detik, paket retransmisi tidak dipakai sebagai sampel RTT (Karn) - [RFC 5681: TCP Congestion Control](https://www.rfc-editor.org/rfc/rfc5681) · IETF · Fast retransmit pada duplicate ACK ketiga; setelah RTO, congestion window mulai lagi dari 1 segmen (loss window) - [RFC 6675: A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP](https://www.rfc-editor.org/rfc/rfc6675) · IETF · Pemulihan packet loss yang memakai informasi SACK untuk menentukan paket yang hilang (sinyal duplicate ACK dan SACK untuk fast retransmit) - [RFC 8985: The RACK-TLP Loss Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc8985) · IETF · Toleransi urutan paket tertukar pada RACK (min_RTT/4) dan penyesuaiannya berdasarkan DSACK, waktu tunggu TLP 2·SRTT (ditambah kelonggaran delayed ACK jika hanya satu paket yang belum mendapat ACK), RTO diatur ulang setelah TLP dikirim, SACK wajib - [RFC 2018: TCP Selective Acknowledgment Options](https://www.rfc-editor.org/rfc/rfc2018) · IETF · SACK: penerima memberi tahu bagian yang hilang di tengah - [RFC 2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP](https://www.rfc-editor.org/rfc/rfc2883) · IETF · DSACK: penerima memberi tahu bahwa data yang sudah diterima datang lagi, sehingga retransmisi yang tidak perlu terungkap - [RFC 5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP](https://www.rfc-editor.org/rfc/rfc5682) · IETF · F-RTO: mendeteksi RTO yang tidak perlu - [RFC 3522: The Eifel Detection Algorithm for TCP](https://www.rfc-editor.org/rfc/rfc3522) · IETF · Timestamp dipakai untuk memastikan setelah kejadian apakah pemulihan sebenarnya tidak perlu (pembatalan penurunan congestion window di simulasi) - [RFC 7323: TCP Extensions for High Performance](https://www.rfc-editor.org/rfc/rfc7323) · IETF · Opsi timestamp dan window scaling; tanpa window scaling, window maksimal 64 KiB - [RFC 6937: Proportional Rate Reduction for TCP](https://www.rfc-editor.org/rfc/rfc6937) · IETF · PRR: selama pemulihan, jumlah data yang dikirim disesuaikan dengan jumlah data yang baru terkirim (batas kirim selama pemulihan di simulasi) - [RFC 9438: CUBIC for Fast and Long-Distance Networks](https://www.rfc-editor.org/rfc/rfc9438) · IETF · CUBIC memperkecil congestion window menjadi 0,7 kali saat packet loss (penurunan 30% di simulasi) - [RFC 9293: Transmission Control Protocol (TCP)](https://www.rfc-editor.org/rfc/rfc9293) · IETF · Zero window probe: probe tetap dikirim meskipun window bernilai 0, dengan interval yang bertambah secara eksponensial - [RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport](https://www.rfc-editor.org/rfc/rfc9000) · IETF · Di QUIC, packet loss hanya menahan stream yang dibawa paket itu, sedangkan stream lain tetap berjalan (pemisahan stream) - [RFC 2475: An Architecture for Differentiated Services](https://www.rfc-editor.org/rfc/rfc2475) · IETF · Definisi: shaping menunda paket, sedangkan policing membuang kelebihannya - [RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP](https://www.rfc-editor.org/rfc/rfc3168) · IETF · ECN: memberi tahu kongesti tanpa membuang paket - [Smart Queue Management](https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/) · Bufferbloat.net · SQM pada router: penjadwalan per flow, AQM, dan shaping mengurangi antrean meluap dan bufferbloat - [RFC 1191: Path MTU discovery](https://www.rfc-editor.org/rfc/rfc1191) · IETF · Path MTU ditemukan lewat ICMP pemberitahuan paket terlalu besar (tipe 3 kode 4) - [RFC 1812: Requirements for IP Version 4 Routers](https://www.rfc-editor.org/rfc/rfc1812) · IETF · Router boleh membatasi laju pembuatan pesan error ICMP (hasil mtr yang hanya menunjukkan packet loss di satu hop di tengah) - [RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop Selection](https://www.rfc-editor.org/rfc/rfc2991) · IETF · Di jaringan multipath, hasil diagnosis seperti ping dan traceroute sulit dipercaya; cara mengunci rute setiap flow dengan flow hash - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · tcp_recovery (default 0x1 RACK; sejak 6.17 RACK menjadi satu-satunya deteksi packet loss sehingga nilai 0 tidak berpengaruh), tcp_early_retrans (default 3, 0 mematikan TLP), tcp_sack, tcp_dsack, tcp_timestamps (aktif secara default), tcp_thin_linear_timeouts (kurang dari 4 paket in-flight, linear maksimal 6 kali), tcp_rto_max_ms, tcp_mtu_probing dan tcp_base_mss, tcp_rto_min_us, tcp_retries2 (default 15, sekitar 924,6 detik), tcp_syn_linear_timeouts, tcp_notsent_lowat - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · TcpOutSegs tidak mencakup retransmisi; arti TCPLossProbes, TCPLossProbeRecovery, TCPLostRetransmit, TCPSpuriousRTOs, TCPDSACKRecv, dan TCPSynRetrans - [net/ipv4/proc.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/proc.c?h=v6.12) · Linux kernel · Nama counter yang muncul di nstat (RetransSegs, TCPTimeouts, TCPLossProbes, TCPSpuriousRTOs, TCPDSACKRecv, dan lainnya) - [Thin-streams and TCP](https://docs.kernel.org/networking/tcp-thin.html) · Linux kernel · Thin stream seperti game sulit memicu fast retransmit sehingga bergantung pada timeout yang panjang; TCP_THIN_LINEAR_TIMEOUTS - [include/net/tcp.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/net/tcp.h?h=v6.12) · Linux kernel · TCP_RTO_MIN 200 ms, TCP_RTO_MAX 120 detik, TCP_TIMEOUT_INIT 1 detik, delayed ACK 40–200 ms (TCP_DELACK_MIN dan MAX), TCP_BASE_MSS 1.024, batas thin stream (kurang dari 4 paket in-flight) - [net/ipv4/tcp_input.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_input.c?h=v6.12) · Linux kernel · RTO = SRTT + rttvar (tidak kurang dari nilai minimum RTO), RACK hanya berlaku untuk koneksi SACK, PRR dipakai untuk memperkecil congestion window selama pemulihan - [net/ipv4/tcp_output.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_output.c?h=v6.12) · Linux kernel · TLP hanya untuk koneksi SACK, waktu tunggu 2·RTT, ditambah nilai minimum RTO jika hanya satu paket yang belum mendapat ACK - [net/ipv4/tcp_timer.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_timer.c?h=v6.12) · Linux kernel · Jika RTO terjadi berturut-turut sebanyak tcp_retries1, deteksi black hole memulai MTU probing; timeout linear untuk thin stream dan SYN - [net/ipv4/tcp_recovery.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_recovery.c?h=v6.12) · Linux kernel · Waktu toleransi RACK = min(min_RTT/4 × jumlah langkah, SRTT); retransmisi yang dikonfirmasi lebih cepat dari RTT minimum tidak dipakai sebagai acuan - [net/ipv4/tcp_ipv4.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_ipv4.c?h=v6.12) · Linux kernel · Inisialisasi nilai default: tcp_early_retrans 3, tcp_recovery RACK, tcp_syn_linear_timeouts 4, tcp_base_mss 1.024 (tcp_mtu_probing tidak diatur secara khusus sehingga bernilai 0) - [net/ipv4/tcp_bbr.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/tcp_bbr.c?h=v6.12) · Linux kernel · pacing_rate BBR = pacing_gain × bandwidth bottleneck (data dikirim merata lewat pacing) - [tcp: use RACK to detect losses](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f41b1c58a32537542f14c1150099131613a5e8a) · Linux kernel · Pengenalan RACK dan tcp_recovery (Linux 4.4), awalnya bekerja sebagai pelengkap metode yang sudah ada - [tcp: disable RFC6675 loss detection](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b38a51fec1c1f693f03b1aa19d0622123634d4b7) · Linux kernel · RACK dijadikan deteksi packet loss default (2018, Linux 4.18) - [tcp: remove obsolete and unused RFC3517/RFC6675 loss recovery code](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1c120191dcec510cc17d587ece48a7ae875a90c5) · Linux kernel · Penghapusan kode pemulihan packet loss RFC6675 (Linux 6.17), dengan penjelasan bahwa RACK-TLP sudah menjadi default sejak 2018 - [tcp: make the first N SYN RTO backoffs linear](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ccce324dabfe2143519daf50ed8b1ef1d0c542f7) · Linux kernel · Empat backoff pertama RTO SYN tidak digandakan (RTO pertama 1 detik, lalu empat kali lagi masing-masing 1 detik, setelah itu 2, 4 detik …; Linux 6.5) - [tcp: add sysctl_tcp_rto_min_us](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f086edef71be7174a16c1ed67ac65a085cda28b1) · Linux kernel · Nilai minimum RTO untuk seluruh server, tcp_rto_min_us (Linux 6.11) - [tcp: add the ability to control max RTO](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54a378f43425085d0684679d99735696b69165bc) · Linux kernel · Opsi socket TCP_RTO_MAX_MS, 1–120 detik (Linux 6.15) - [tcp: support TCP_RTO_MIN_US for set/getsockopt use](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f38805c5d26fe4af97837c10d58074a7496638bf) · Linux kernel · Opsi socket TCP_RTO_MIN_US untuk mengatur nilai minimum RTO per koneksi (Linux 6.15) - [Android common kernels](https://source.android.com/docs/core/architecture/kernel/android-common) · Android (Google) · Android common kernel yang masih didukung adalah 5.10 ke atas (lebih baru dari 4.18, versi saat RACK menjadi default) - [tcp(7) — Linux manual page](https://man7.org/linux/man-pages/man7/tcp.7.html) · Linux man-pages · TCP_NODELAY (mematikan Nagle), TCP_USER_TIMEOUT (hanya menentukan kapan menyerah, tanpa mengubah waktu retransmisi), TCP_KEEPIDLE, TCP_INFO - [ip-route(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ip-route.8.html) · iproute2 · Opsi rto_min per rute - [tc-fq(8) — Linux manual page](https://man7.org/linux/man-pages/man8/tc-fq.8.html) · iproute2 · Pacing per koneksi pada antrean fq (qdisc) dan SO_MAX_PACING_RATE - [iptables-extensions(8) — Linux manual page](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) · netfilter · TCPMSS --clamp-mss-to-pmtu: mengatasi jalur yang memblokir ICMP dengan menyesuaikan MSS pada SYN - [ss(8) — Linux manual page](https://man7.org/linux/man-pages/man8/ss.8.html) · iproute2 · rto (ms), backoff (jumlah exponential backoff), rtt/rttvar, dan cwnd pada ss -i - [misc/ss.c](https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/misc/ss.c?h=v6.12.0) · iproute2 · Output ss -ti untuk retrans:saat ini/kumulatif, lost, reordering, bytes_sent, dan bytes_retrans - [nstat(8) — Linux manual page](https://man7.org/linux/man-pages/man8/nstat.8.html) · iproute2 · Secara default, nstat menampilkan kenaikan sejak eksekusi sebelumnya - [Demonstrations of tcpretrans, the Linux eBPF/bcc version](https://raw.githubusercontent.com/iovisor/bcc/master/tools/tcpretrans_example.txt) · IO Visor · Satu baris per retransmisi berisi alamat, port, dan state; -c untuk agregasi per flow, -l untuk menyertakan percobaan TLP - [Interface statistics](https://docs.kernel.org/networking/statistics.html) · Linux kernel · Memeriksa error hingga ke detail dengan ip -s -s link, arti rx_missed_errors dan rx_crc_errors, serta statistik per driver di ethtool -S - [drivers/net/ethernet/intel/igb/igb_ethtool.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/igb/igb_ethtool.c?h=v6.12) · Linux kernel · Contoh nama counter per driver: rx_missed_errors, rx_no_buffer_count, rx_crc_errors - [Ethtool counters](https://docs.kernel.org/networking/device_drivers/ethernet/mellanox/mlx5/counters.html) · Linux kernel · rx_out_of_buffer dan rx_discards_phy pada mlx5 - [net/core/net-procfs.c](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/net-procfs.c?h=v6.12) · Linux kernel · /proc/net/softnet_stat berisi satu baris per CPU dalam heksadesimal; kolom ke-2 adalah dropped, kolom ke-3 adalah time_squeeze - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Arti bw_in, bw_out, pps, conntrack, dan linklocal_allowance_exceeded; untuk melihatnya di CloudWatch, CloudWatch agent harus dipasang - [High-Resolution Measurement of Data Center Microbursts](https://research.facebook.com/publications/high-resolution-measurement-of-data-center-microbursts/) · Meta · Sebagian besar burst selesai dalam puluhan µs sehingga penyebab paket dibuang tidak terlihat dari utilisasi rata-rata per menit (IMC 2017) - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · -T (--tcp) untuk TCP SYN, -P (--port) untuk menentukan port tujuan - [pathping](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping) · Microsoft · Perintah diagnosis rute di Windows yang mengirim probe berkali-kali lalu menghitung packet loss dan latensi per hop - [Display Filter Reference: Transmission Control Protocol](https://www.wireshark.org/docs/dfref/t/tcp.html) · Wireshark · Filter tampilan tcp.analysis.retransmission, fast_retransmission, spurious_retransmission, duplicate_ack, lost_segment, dan zero_window - [7.5. TCP Analysis](https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html) · Wireshark · Kriteria penandaan retransmisi, fast retransmit, retransmisi yang tidak perlu, dan ZeroWindow - [Network-Related Performance Counters](https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) · Microsoft · TCPv4 Segments Retransmitted/sec·Segments Sent/sec, Network Interface Packets Received Discarded - [TCP/IP connectivity issues troubleshooting](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting) · Microsoft · Memeriksa pengaturan TCP global (Max SYN Retransmissions) dengan netsh int tcp show global, dan memastikan packet loss di tengah jalur dengan capture serentak di kedua ujung - [Packet Monitor (Pktmon)](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon) · Microsoft · Tool bawaan yang menunjukkan lokasi dan alasan paket dibuang di berbagai titik network stack Windows - [Pktmon command formatting](https://learn.microsoft.com/en-us/windows-server/networking/technologies/pktmon/pktmon-syntax) · Microsoft · Tersedia bawaan di Windows 10 dan Windows Server 2019 (1809 ke atas) sebagai pktmon.exe - [TCP improvements in the Windows network stack (IETF 98 TCPM)](https://datatracker.ietf.org/meeting/98/materials/slides-98-tcpm-tcp-improvements-in-windows-01) · Microsoft · Windows 10 Anniversary Update (1607) dan Server 2016 mengaktifkan TLP dan RACK secara default (untuk koneksi dengan RTT lebih dari 10 ms); saat hanya satu paket tersisa, TLP memperhitungkan delayed ACK 200 ms - [Algorithmic improvements boost TCP performance on the Internet](https://techcommunity.microsoft.com/blog/networkingblog/algorithmic-improvements-boost-tcp-performance-on-the-internet/2347061) · Microsoft · TLP aktif secara default sejak Windows Server 2016, RACK baru yang juga memulihkan retransmisi yang hilang disertakan di Server 2022, PRR aktif secara default sejak Windows 10 1903 - [TcpMaxConnectRetransmissions](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938209(v=technet.10)) · Microsoft · Retransmisi SYN di Windows versi lama: 2 kali, mulai dari 3 detik dan berlipat dua ### #owners - [RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP](https://www.rfc-editor.org/rfc/rfc4787) · IETF · Mapping NAT wajib diperbarui oleh paket yang keluar dari dalam (REQ-6), sedangkan pembaruan oleh paket yang masuk dari luar bersifat opsional (untuk UDP). Karena itu, heartbeat dikirim oleh klien - [RFC 5382: NAT Behavioral Requirements for TCP](https://www.rfc-editor.org/rfc/rfc5382) · IETF · NAT boleh menghapus sesi TCP yang idle, dan idle timeout yang direkomendasikan minimal 2 jam 4 menit (pengaturan bisa berbeda per perangkat) - [Amazon EC2 security group connection tracking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) · AWS · Idle timeout TCP pada connection tracking security group (350 detik untuk tipe instance Nitro v6, 5 hari untuk lainnya, bisa diatur 60 detik hingga 5 hari), rekomendasi keepalive lebih pendek dari 5 menit, 350 detik untuk TCP yang melewati NLB - [Control subnet traffic with network access control lists](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) · AWS · Network ACL tidak menyimpan state (tanpa connection tracking) sehingga trafik respons juga harus diizinkan dengan aturan tersendiri - [Monitor network performance for ENA settings on your EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html) · AWS · Counter instance untuk pelampauan batas connection tracking dan paket per detik (conntrack_allowance_exceeded, pps_allowance_exceeded) - [listen(2) — Linux manual page](https://man7.org/linux/man-pages/man2/listen.2.html) · Linux man-pages · Argumen backlog pada listen adalah ukuran antrean sebenarnya, dan jika lebih besar dari somaxconn, nilainya dipotong menjadi somaxconn (default 4.096 sejak 5.4) - [IP Sysctl](https://docs.kernel.org/networking/ip-sysctl.html) · Linux kernel · somaxconn (batas atas listen backlog), tcp_max_syn_backlog, tcp_syncookies (default 1, cadangan yang dipakai saat antrean SYN meluap), tcp_keepalive_time (default 2 jam) - [SNMP counter](https://docs.kernel.org/networking/snmp_counter.html) · Linux kernel · Saat antrean accept penuh, SYN dibuang dan TcpExtListenOverflows serta TcpExtListenDrops naik - [Netfilter Conntrack Sysfs variables](https://docs.kernel.org/networking/nf_conntrack-sysctl.html) · Linux kernel · Menghitung utilisasi conntrack dari nf_conntrack_count dan nf_conntrack_max - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) · Linux kernel · nr_throttled di cpu.stat: jumlah throttling akibat batas CPU container - [proc_stat(5) — Linux manual page](https://man7.org/linux/man-pages/man5/proc_stat.5.html) · Linux man-pages · steal di /proc/stat: waktu CPU dipakai OS lain di lingkungan virtualisasi - [RFC 2992: Analysis of an Equal-Cost Multi-Path Algorithm](https://www.rfc-editor.org/rfc/rfc2992) · IETF · ECMP memilih jalur berdasarkan hash field header yang mengidentifikasi flow (flow yang sama melewati jalur yang sama, flow yang berbeda bisa melewati jalur yang berbeda) - [mtr(8) manual page source](https://raw.githubusercontent.com/traviscross/mtr/master/man/mtr.8.in) · mtr · Mengukur rute dengan protokol dan port yang sama dengan game (-T, -u, -P) ### #l-server-proc - [VALORANT's 128-Tick Servers](https://www.riotgames.com/en/news/valorants-128-tick-servers) · Riot Games · Tick budget: pada 128 tick, satu frame harus selesai dalam 7,8125 ms; frame time diukur per subsistem dan budget dibagi untuk masing-masing - [Introducing Time Dilation (TiDi)](https://www.eveonline.com/news/view/introducing-time-dilation-tidi) · CCP Games · Simulasi fisika EVE Online diperbarui sekali per detik; saat kelebihan beban, waktu game diperlambat untuk menurunkan beban yang terikat waktu secara proporsional - [HED-GP Technical Retrospective: What a HED-ache](https://www.eveonline.com/news/view/what-a-hed-ache) · CCP Games · Batas bawah Time Dilation 10%; pengiriman O(n²), yaitu aksi n pemain dikabarkan ke n pemain, menjadi faktor pembatas dalam pertempuran besar - [Handling variation in time](https://docs.unity3d.com/Manual/time-handling-variations.html) · Unity · Model pada simulasi tick budget: jika update dengan interval tetap tertinggal, langkah catch-up dijalankan sekaligus (fast forward), dan waktu yang melewati batas dibuang sehingga waktu game melambat (slow motion) - [Comparing Interest Management Algorithms for Massively Multiplayer Games](https://www.sable.mcgill.ca/~clump/papers/boulanger-06-comparing.pdf) · ACM · Makalah NetGames 2006 (versi yang diunggah penulis). Membandingkan jarak semua pasangan tidak sanggup lagi saat jumlah pemain bertambah; jika dunia dibagi menjadi grid, cukup sel di sekitarnya yang diperiksa - [Replication Graph in Unreal Engine](https://dev.epicgames.com/documentation/en-us/unreal-engine/replication-graph-in-unreal-engine) · Epic Games · Jika dunia dibagi menjadi grid dan penerima dipilih dari daftar per sel, CPU server tetap hemat meskipun pemain dan actor banyak - [Amdahl's Law in the Multicore Era](https://research.cs.wisc.edu/multifacet/papers/ieeecomputer08_amdahl_multicore.pdf) · IEEE · Batas throughput pada simulasi lock: jika porsi pekerjaan yang hanya bisa dijalankan satu per satu adalah 1−f, percepatan tidak bisa melebihi 1/(1−f) - [Runtime locking correctness validator](https://docs.kernel.org/locking/lockdep-design.html) · Linux kernel · Deadlock pada simulasi lock: jika dua lock dipegang dengan urutan yang saling berlawanan, terjadi saling tunggu melingkar (circular wait) dan deadlock - [Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) · Kubernetes · Watchdog pada simulasi lock: kondisi deadlock dideteksi dengan liveness probe lalu proses dimulai ulang; secara default pemeriksaan dilakukan setiap 10 detik dan restart terjadi setelah 3 kali gagal berturut-turut (sekitar 30 detik) - [ASP.NET Core Best Practices](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/best-practices) · Microsoft · Pemanggilan sinkron: panggil akses data dan I/O secara asinkron; pemanggilan blocking menyebabkan thread pool habis dan respons lambat ### #l-infra - [Site Reliability Engineering, Chapter 22: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) · Google · Kegagalan berantai: backend yang lambat menahan thread dan sumber daya di lapisan depan, lalu retry, kegagalan health check, dan restart dengan cache kosong menyebarkan gangguan, serta cara menanganinya - [Circuit Breaker Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker) · Microsoft Azure · State closed, open, dan half-open pada circuit breaker serta batas jumlah kegagalan; jika timeout panjang, thread tertahan sampai circuit breaker memutus - [Bulkhead Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead) · Microsoft Azure · Mengisolasi sumber daya per fitur dan per tujuan pemanggilan agar gangguan di satu tempat tidak menyebar - [Timeouts, retries, and backoff with jitter](https://d1.awsstatic.com/builderslibrary/pdfs/timeouts-retries-and-backoff-with-jitter.pdf) · AWS · Amazon Builders' Library. Timeout membebaskan sumber daya, dan retry dibatasi jumlahnya serta diberi jitter - [The Unique Architecture behind Amazon Games’ Seamless MMO New World](https://aws.amazon.com/blogs/gametech/the-unique-architecture-behind-amazon-games-seamless-mmo-new-world/) · AWS · Contoh arsitektur server MMO: server entry point, server simulasi per grid (hub), pool server bersama untuk sesi, dan DB penyimpan state - [Working with DB instance read replicas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) · AWS · Replication lag pada simulasi arsitektur server: replika baca diperbarui secara asinkron sehingga data lama bisa terbaca - [Site Reliability Engineering, Chapter 20: Load Balancing in the Datacenter](https://sre.google/sre-book/load-balancing-datacenter/) · Google · Deploy dan restart: alihkan permintaan baru dengan status lame duck sebelum server dimatikan, dan lakukan warm-up tepat setelah restart - [Amazon EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) · AWS · Saat scale-out dan scale-in, instance ditahan dalam status menunggu untuk menyelesaikan pekerjaan persiapan dan pembersihan (secara default hingga 1 jam) - [systemd.service(5) — Linux manual page](https://man7.org/linux/man-pages/man5/systemd.service.5.html) · systemd · Watchdog pada simulasi arsitektur server: menghentikan layanan yang berhenti mengirim sinyal hidup (heartbeat) dan memulainya ulang secara otomatis ## Pola grafik - **Melonjak secara berkala** (`periodic`): Biasanya rendah, lalu melonjak dengan selang yang sama, misalnya setiap beberapa detik, setiap beberapa menit, atau tepat di awal jam. - **Melonjak acak sesekali** (`random`): Melonjak tidak beraturan tanpa selang yang tetap, lalu segera kembali normal. - **Naik seperti anak tangga** (`step`): Naik satu tingkat sejak waktu tertentu, seperti patch, perubahan konfigurasi, atau perubahan rute, lalu bertahan di level itu. - **Naik perlahan** (`ramp`): Naik sedikit demi sedikit selama beberapa jam atau beberapa hari. Makin lama menyala, makin tinggi. - **Naik perlahan lalu anjlok** (`sawtooth`): Naik perlahan, lalu anjlok saat restart atau pembersihan, dan pola ini berulang. - **Tinggi hanya di jam tertentu** (`peak`): Naik membentuk bukit hanya pada jam yang sama setiap hari, misalnya jam sibuk malam. - **Naik mengikuti beban** (`load`): Saat jumlah pemain online bersamaan atau pemain yang berkumpul di satu tempat bertambah, grafik ikut naik dengan lebih curam. - **Mendatar di batas** (`ceiling`): Throughput atau jumlah koneksi tidak bisa naik lagi setelah mencapai nilai tertentu, dan sejak itu antrean dan error bertambah. - **Selalu tinggi sejak awal** (`high`): Terus bertahan di nilai tinggi tanpa lonjakan. Penyebabnya struktural, seperti jarak, rute, atau desain. - **Hanya sebagian yang tinggi** (`outlier`): Sebagian besar normal; hanya pemain, wilayah, ISP, atau perangkat tertentu yang tinggi sendiri. - **Kosong lalu datang sekaligus** (`gap`): Jumlah data yang diterima turun ke 0 selama beberapa saat, lalu datang menumpuk sekaligus. - **Koneksi putus serentak** (`drop`): Jumlah koneksi anjlok, atau jumlah disconnect melonjak seketika. - **Melonjak tepat setelah server dibuka** (`surge`): Melonjak tinggi tepat setelah server dibuka atau event dimulai, lalu turun perlahan. ## Prosedur per situasi ### Lag setelah patch Saat laporan lag bertambah sejak patch atau deploy tertentu. Pakai prosedur ini saat laporan seperti “sejak update ini jadi aneh” mulai berdatangan, atau saat grafik naik seperti anak tangga pada suatu waktu lalu bertahan di level itu. 1. **Pastikan waktu mulainya, lalu kumpulkan semua perubahan di sekitarnya**: Cari waktu laporan mulai membanjir dan waktu grafik naik seperti anak tangga, lalu catat semua perubahan yang dirilis sebelum dan sesudahnya tanpa terlewat. Periksa sekaligus patch klien, deploy server, perubahan konfigurasi, perubahan skema DB (DDL) dan restart, pekerjaan jaringan dan firewall, serta penggantian infrastruktur (jenis instance, kernel, driver). Jika setiap deploy ditandai garis vertikal di semua grafik dengan fitur anotasi (annotation) di tools monitoring, langkah ini cepat selesai. Jika patch game dan pekerjaan infrastruktur dirilis di jadwal maintenance yang sama, pertahankan keduanya sebagai kandidat. Pihak yang dihubungi pertama: Tim Pengembang Game dan Tim Infrastruktur, masing-masing untuk perubahan yang mereka rilis. (penyebab: in-deploy, so-os-update, db-ddl-lock, db-plan-flip, db-cold-cache) 2. **Pilah cakupannya: build, perangkat, server, wilayah**: Periksa dimensi tempat masalah menumpuk. Jika hanya pemain dengan build baru yang terdampak, curigai klien lebih dulu; jika hanya OS, kartu grafis, atau perangkat tertentu, curigai performa klien atau driver; jika hanya server, channel, atau zona tertentu, curigai server; jika hanya negara atau ISP tertentu, curigai rute jaringan; jika semua terdampak bersamaan, curigai sumber daya bersama (DB, load balancer, gateway) atau deploy server yang baru saja dirilis. Jika telemetri klien mencatat nomor build, bandingkan ping, FPS, lonjakan frame, dan jumlah disconnect antara build lama dan build baru secara berdampingan. Jika ping tetap dan hanya FPS yang memburuk, penyebabnya lebih mungkin performa klien daripada jaringan. Pihak yang dihubungi pertama: jika menumpuk di build atau perangkat, Tim Pengembang Game (klien); jika menumpuk di server atau channel, Tim Pengembang Game (server) bila metrik host normal, atau Tim Infrastruktur (server/OS) bila metrik host tidak normal; jika menumpuk di negara atau ISP, Tim Infrastruktur (jaringan). (penyebab: cg-hitch, cg-sync-load, co-vram, cg-crash) 3. **Bandingkan versi baru dan versi lama pada jam yang sama**: Jika hanya membandingkan sebelum dan sesudah deploy, perubahan akibat hari, jam, dan event ikut tercampur sehingga penilaian menjadi kabur. Jika memungkinkan, pasang versi baru lebih dulu di sebagian server (canary), lalu bandingkan secara berdampingan dengan server versi lama (kelompok kontrol) pada jam yang sama: waktu tick p50 dan p99, jumlah tick overrun, CPU, memori, dan tingkat error. Jika sudah telanjur di-deploy ke semua server, bandingkan dengan hari dan jam yang sama minggu lalu. Rata-rata seluruh server menutupi masalah di sebagian server atau zona, jadi pisahkan per server dan per zona. Pihak yang dihubungi pertama: Tim Pengembang Game (server). (penyebab: sp-tick-overrun, mem-alloc, mem-leak, sp-broadcast) 4. **Bandingkan profil trafik sebelum dan sesudah patch**: Tanpa mengetahui kode server pun, nilai yang terlihat dari sisi jaringan bisa menunjukkan apakah patch mengubah bentuk trafik. Bandingkan sebelum dan sesudah patch: jumlah paket per detik (pps) dan byte per pemain, ukuran paket rata-rata dan maksimum, jumlah koneksi, serta ukuran burst pengiriman yang keluar sekaligus setiap tick. Jika paket UDP mulai melebihi path MTU (biasanya 1.500 byte), terjadi fragmentasi IP. Kehilangan satu fragmen saja berarti seluruh paket hilang, dan ada NAT atau firewall yang membuang fragmen sama sekali. Bagi pemain yang melewati segmen dengan MTU kecil di tengah jalur (tunnel, VPN), hanya paket besar yang hilang. Jika pps naik, periksa apakah batas PPS instance cloud atau batas pemrosesan firewall dan perangkat proteksi DDoS sudah tercapai. Pihak yang dihubungi pertama: jika profil trafik berubah, Tim Pengembang Game (server) dengan bukti terlampir; jika profil trafik tetap tetapi packet loss dan retransmisi naik, Tim Infrastruktur (jaringan). (penyebab: sp-patch-traffic, sk-fragment, rt-mtu, nic-cloud-pps, rt-appliance-pps, rt-burst) 5. **Bandingkan jenis dan jumlah query DB sebelum dan sesudah patch**: Jika latensi DB naik, periksa dulu apakah jumlah query (QPS) juga ikut naik. Ringkasan digest di MySQL Performance Schema dan pg_stat_statements di PostgreSQL mengelompokkan query yang hanya berbeda nilainya menjadi satu jenis serta mengumpulkan jumlah eksekusi dan total waktunya. Jika daftar query teratas sebelum dan sesudah patch dibandingkan, akan terlihat query yang baru muncul, query yang jumlah eksekusinya naik beberapa kali lipat (N+1), dan query yang membaca seluruh tabel tanpa indeks (di MySQL, kolom SUM_NO_INDEX_USED). Pihak yang dihubungi pertama: jika QPS atau bentuk query berubah, Tim Pengembang Game (server); jika query-nya sama tetapi latensinya naik, Tim Infrastruktur (DB: query plan, IOPS, lock). (penyebab: db-no-index, db-login-storm, db-plan-flip, db-cache-stampede) 6. **Pilah lapisan lewat metrik host dan proses server**: Tanpa membaca kode, gunakan nilai yang terlihat di OS untuk memisahkan masalah di dalam proses server dari masalah host. Jika antrean terima (Recv-Q) socket server menumpuk, proses server tidak membacanya tepat waktu (tick terhenti, GC, lock); jika hanya satu thread yang 100%, ada bottleneck single-thread; jika waktu jeda di log GC bertambah, pola pemakaian memori sudah berubah. Periksa juga apakah deploy dilakukan dengan level log yang dibiarkan tinggi sehingga penulisan log bertambah. Sebaliknya, jika CPU steal, throttling, atau drop di NIC bertambah, periksa infrastruktur yang berubah pada waktu yang sama (jenis instance, kernel, batas container). Pihak yang dihubungi pertama: jika sinyalnya dari dalam proses, Tim Pengembang Game (server); jika sinyalnya dari host, Tim Infrastruktur (server/OS). (penyebab: mem-gc, sp-hotzone, dk-sync-log, so-cpu-quota, so-steal, so-os-update) 7. **Pastikan dengan rollback, lalu catat hasilnya**: Kembalikan perubahan yang paling dicurigai hanya di sebagian server atau untuk sebagian pemain (rollback, mematikan feature flag), atau kembalikan konfigurasi ke nilai sebelumnya, lalu lihat apakah gejalanya ikut hilang. Jika hanya sisi yang dikembalikan yang membaik, penyebabnya terkonfirmasi. Proses pengembalian juga bisa membuat sistem melambat sesaat karena restart dan cold cache, jadi jika tidak mendesak, lakukan di jam sepi. Catat hasilnya di catatan insiden beserta ID penyebab, lalu jadikan batas ukuran paket, jumlah query, dan waktu tick sebagai item pemeriksaan sebelum deploy untuk patch berikutnya. Pihak yang dihubungi pertama: tim yang merilis perubahan. (penyebab: in-deploy, db-cold-cache) ### Membuka layanan di negara atau wilayah baru Saat membuka layanan di negara baru atau menambah region atau data center baru. Pakai juga untuk pemeriksaan sebelum peluncuran dan untuk memilah laporan seperti “di Korea lancar, tetapi hanya pemain di negara baru yang lag”. 1. **Ukur kualitas rute per ISP setempat sebelum peluncuran**: Untuk setiap ISP utama (ASN) di negara tujuan, ukur distribusi round-trip time (RTT), jitter, dan packet loss sampai lokasi kandidat server game. Satu nilai rata-rata menyembunyikan perbedaan antar-ISP, jadi periksa median dan persentil ke-95 per ISP, dipisah antara jam sibuk malam dan dini hari. Di RIPE Atlas, jaringan pengukuran publik, Anda bisa memilih negara dan ASN lalu mengirim ping dan traceroute dari probe di seluruh dunia. Anda juga bisa menjalankan VM sementara di region kandidat untuk mengukur. Perangkat di tengah jalur kadang membatasi respons ICMP, jadi jika memungkinkan, ukur juga dengan protokol dan port yang sama dengan game. Jika hanya ISP tertentu yang melewati kota yang jauh, itu masalah peering atau rute. ISP memilih rute yang lebih murah meskipun latensinya lebih tinggi, sehingga tujuan yang dekat pun bisa memutar jauh. Pihak yang dihubungi pertama: Tim Infrastruktur (jaringan); jika masalah rutenya di sisi ISP, Pihak Eksternal (ISP, IX). (penyebab: isp-distance, isp-routing, isp-peak, isp-cable) 2. **Bandingkan hasil pengukuran dengan batas yang sanggup ditoleransi desain game**: Bandingkan RTT dan jitter hasil pengukuran dengan timing window game (waktu reaksi untuk dodge, parry, dan sejenisnya), batas lag compensation, panjang buffer interpolasi, dan ukuran buffer input. Misalnya, jika parry window 0,2 detik, pemain dari ISP yang jumlah latensi pulang-pergi dan buffer interpolasinya lebih panjang dari itu tetap terlambat walaupun bereaksi tepat waktu. Jika lag compensation diperlebar untuk menutupinya, giliran pihak yang diserang yang makin sering melaporkan “sudah di balik tembok, tetapi tetap kena”. Jika banyak ISP yang melewati batas, Tim Infrastruktur menimbang opsi menempatkan region atau edge PoP lebih dekat, dan Tim Pengembang Game meninjau nilai timing window, interpolasi, dan lag compensation. Bab “Ping sama, rasa berbeda: model sinkronisasi” dalam buku putih ini berisi tabel acuannya. Pihak yang dihubungi pertama: Tim Pengembang Game (server dan klien: batas desain), Tim Infrastruktur (jaringan: lokasi region dan PoP). (penyebab: sy-short-window, sy-no-lagcomp, sy-lagcomp-overreach, cg-no-buffer) 3. **Periksa MTU dan apakah UDP bisa lewat**: Periksa apakah paket terbesar game bisa melewati jaringan setempat secara utuh. Kirim ping bertanda larangan fragmentasi (DF) dengan berbagai ukuran untuk mengukur path MTU, dan periksa apakah ada segmen yang lebih kecil dari 1.500 byte seperti PPPoE, tunnel, atau jaringan seluler. Standar untuk transport datagram seperti UDP (RFC 8899) menganjurkan 1.200 byte sebagai ukuran dasar yang bisa melewati sebagian besar jalur di IPv4, jadi jika paket terbesar game melebihi ukuran ini, putuskan bersama Tim Pengembang Game apakah paket diperkecil atau dipecah. Periksa juga apakah UDP atau port game diblokir atau dibatasi kecepatannya di Wi-Fi publik, jaringan kantor, atau ISP tertentu, dan apakah ada rute cadangan (TCP, port 443) yang bisa dipakai saat diblokir. Pihak yang dihubungi pertama: Tim Infrastruktur (jaringan) dan Tim Pengembang Game (server: ukuran paket). (penyebab: dc-mtu, rt-mtu, sk-fragment, isp-udp-block, hn-captive, isp-shaping) 4. **Ukur idle timeout NAT dan CGNAT, lalu sesuaikan interval heartbeat**: Ukur berapa lama router rumah dan jaringan seluler (CGNAT) setempat menyimpan mapping koneksi UDP yang idle sebelum menghapusnya. Pada setiap uji, kirim satu paket dari perangkat uji ke server untuk membuat mapping, lalu biarkan perangkat tidak mengirim apa pun, dan minta server mengirim paket ke perangkat setelah waktu yang ditentukan (30 detik, 60 detik, 120 detik …). Waktu saat perangkat mulai tidak menerima paket itu adalah idle timeout jaringan tersebut. Standar (RFC 4787) menetapkan bahwa mapping UDP tidak boleh kedaluwarsa sebelum 2 menit dan menganjurkan default minimal 5 menit, tetapi nilainya sangat berbeda antarperangkat dan ada perangkat yang menghapusnya lebih cepat. Mapping hanya diperbarui dengan pasti oleh paket yang keluar dari perangkat, jadi heartbeat dikirim oleh klien. Periksa apakah intervalnya maksimal setengah dari nilai terpendek di antara hasil pengukuran dan idle timeout load balancer serta security group cloud. Pihak yang dihubungi pertama: Tim Pengembang Game (klien: interval heartbeat; server: nilai timeout), Tim Infrastruktur (konfigurasi load balancer dan security group). (penyebab: hn-nat, isp-cgnat, rt-mapping, dc-lb-idle, dc-cloud-conntrack) 5. **Periksa layanan eksternal dan perangkat keamanan yang dilalui trafik setempat**: Periksa apakah login platform setempat, pembayaran, dan verifikasi identitas merespons dengan kecepatan normal, apakah DNS setempat menerjemahkan nama server login dan server patch ke alamat yang benar, dan apakah CDN mengirim patch dari lokasi yang dekat dengan negara itu. Periksa apakah rentang IP negara baru terkena aturan blokir negara dan pembatasan laju (rate limit) di proteksi DDoS dan firewall, terutama apakah rentang CGNAT, tempat banyak pelanggan berbagi satu IP, terblokir sekaligus. Pihak yang dihubungi pertama: Tim Infrastruktur (perangkat keamanan, DNS, CDN), Pihak Eksternal (platform, penyedia pembayaran, ISP). (penyebab: in-external, isp-dns, dc-ddos, isp-cgnat) 6. **Setelah peluncuran, pantau per negara dan ASN**: Tandai IP klien di log koneksi dan log load balancer dengan negara dan ASN, lalu periksa RTT, retransmisi, jumlah disconnect, dan alasannya (timeout heartbeat, RST, kick dari server) per negara dan ISP. Database gratis seperti MaxMind GeoLite ASN bisa mengubah IP menjadi ASN dan nama organisasi. Sesuai aturan privasi setempat, simpan IP dalam bentuk yang diringkas ke unit /24 atau ASN. Jika masalah menumpuk di satu ASN saja, periksa dulu rute ISP itu (Tim Infrastruktur, Pihak Eksternal); jika seluruh negara baru buruk, periksa jarak dan batas desain (Tim Infrastruktur, Tim Pengembang Game); jika hanya memburuk di malam hari, periksa kongesti peering. Jika hanya sebagian pemain yang ping-nya selalu tinggi, periksa bersama Tim Pengembang Game (server) apakah mereka ditempatkan di region yang jauh karena GeoIP yang keliru, VPN, atau penempatan berdasarkan lokasi ketua party. Jika synthetic monitoring normal tetapi hanya pemain yang mengalami masalah, penyebabnya ada di lingkungan pemain atau di sisi klien. (penyebab: isp-peak, isp-routing, rt-queue-drop, pt-isp-validation, in-region-match) 7. **Periksa dampak pemain dari wilayah jauh terhadap pemain lain**: Saat pemain yang tersambung dari jauh bertambah, masalahnya tidak berhenti di layar mereka sendiri. Input dari pemain yang lambat tiba sekaligus, sehingga di layar pemain lain hanya karakter itu yang bergerak fast forward, dan pemeriksaan kecepatan serta cooldown di server memicu rubber banding atau skill ditolak. Dalam mekanik party, reaksi terlambat dari satu pemain yang lambat menjadi kegagalan seluruh party, dan pada lockstep semua pemain menunggu pemain yang paling lambat. Setelah membuka negara baru, periksa apakah laporan “hanya satu karakter yang terlihat aneh” dari pemain lama bertambah, lalu putuskan bersama Tim Pengembang Game soal buffer input, batas toleransi validasi, dan pemisahan wilayah matchmaking. Pihak yang dihubungi pertama: Tim Pengembang Game (server). (penyebab: pt-slow-burst, pt-isp-validation, pt-raid-member, sy-lockstep) ## Kasus insiden nyata ### eve-hedgp-2014 · CCP Games 2014: Kelebihan beban server dalam pertempuran armada besar HED-GP di EVE Online - Apa yang terjadi: Dalam pertempuran armada besar di sistem bintang HED-GP yang dibahas tulisan retrospektif Januari 2014, server mengalami kelebihan beban yang parah. Bahkan setelah Time Dilation (fitur yang memperlambat waktu game saat kelebihan beban) mencapai batas bawahnya, yaitu 10%, dan seluruh medan pertempuran menjadi slow motion, beban terus menumpuk. Keterlambatan pekerjaan yang memproses penghentian dan siklus berulang modul (Dogma Lateness) mencapai puncak 193 detik waktu game, atau sekitar 32 menit waktu nyata. Pertempuran 6VDT pada Juli 2013, yang skalanya hampir sama, mencapai puncak 42 detik (sekitar 7 menit waktu nyata). - Penyebab: CCP menegaskan bahwa penyebabnya belum bisa dipastikan, karena tools analisis performa ikut menambah beban sehingga tidak dijalankan dalam situasi seperti ini. Dengan catatan itu, CCP menyebut dua penyebab yang paling mungkin. Pertama, beban yang tidak sempat diproses terus menumpuk selama pertempuran berlangsung lama. Kedua, penggunaan drone meningkat: jumlah drone unik yang dikerahkan selama pertempuran mencapai 21.123 di 6VDT dan 38.852 di HED-GP, atau 84% lebih banyak. Aksi seorang pemain harus diberitahukan kepada semua orang yang melihatnya, sehingga jumlah pengiriman tumbuh sebanding dengan kuadrat jumlah pemain (O(n²)), dan drone menghasilkan lebih banyak pesan untuk setiap serangan. Kode yang dipakai drone untuk memilih target juga sering memeriksa semua target yang bisa diserang di medan pertempuran yang sama, sehingga biayanya tumbuh mendekati n². - Pelajaran: Jika throughput satu area yang dipadati pemain melewati batasnya, seluruh area itu menjadi slow motion. Makin lama pertempuran berlangsung, makin banyak pemrosesan tertunda yang menumpuk, dan input lag makin besar. Sinyal yang perlu diperiksa adalah waktu tick dan jumlah pekerjaan tertunda di server (node) yang menangani area itu, serta jumlah pemain dan objek. Cirinya, area lain tetap normal. Penanggung jawab utama adalah Tim Pengembang Game (server), dan yang perlu diperbaiki adalah cakupan penerima pemberitahuan untuk satu aksi serta biaya pencarian target oleh AI. Desain yang memperlambat waktu game tidak menghilangkan kelebihan beban. Namun, desain ini membuat semua pemain melambat dengan kecepatan yang sama, sehingga tidak ada aksi tertentu yang tertunda tanpa batas. - Penyebab terkait: sp-broadcast, sp-tick-overrun, sp-queue, sp-hotzone - Sumber asli: [CCP Games](https://www.eveonline.com/news/view/what-a-hed-ache) ### riot-direct-2015 · Riot Games 2015: Trafik League of Legends yang memutar jauh dan Riot Direct - Apa yang terjadi: Tulisan teknis Riot Games yang menjelaskan mengapa internet tidak cocok untuk game real-time. Trafik nyata yang dilaporkan seorang pemain League of Legends seharusnya berjalan langsung dari San Francisco ke Portland, tetapi malah melewati Los Angeles, Denver, dan Seattle, sehingga perjalanan yang cukup 14 ms jika langsung menjadi 70 ms. Riot menjelaskan bahwa jika router meluap dan paket dibuang, champion lain terlihat melompat-lompat di layar dan proyektil terlihat teleport. - Penyebab: Riot menyebut rute dan router sebagai penyebabnya. Penyedia backbone dan ISP mengirim trafik lewat rute yang biayanya paling murah, yang belum tentu rute dengan latensi terendah, dan jika rute yang ditentukan BGP memutar jauh, jumlah router yang dilewati juga bertambah. Beban pemrosesan router bergantung pada jumlah paket, berapa pun ukurannya. Paket game berukuran sekitar 55 byte, sehingga untuk volume data yang sama jumlahnya 27 kali lipat paket 1.500 byte dan buffer input router pun lebih cepat penuh. Menurut penjelasan Riot, banyak router juga membuang paket UDP lebih dulu saat kelebihan beban. Sebagai solusinya, Riot membangun jaringan sendiri bernama Riot Direct dengan menempatkan router di 10 hub internet besar di Amerika Serikat dan terhubung langsung (peering) dengan sebanyak mungkin ISP. Menurut tulisan bagian kedua, porsi pemain yang bermain dengan ping di bawah 80 ms naik dari 31% menjadi 50% dalam sedikit lebih dari 9 bulan, lalu menjadi 80% dalam semalam setelah server game dipindahkan ke Chicago. - Pelajaran: Jika hanya pemain dari ISP tertentu yang ping-nya jauh lebih tinggi, bahkan di dalam satu negara, curigai rutenya. Sinyal yang perlu diperiksa adalah distribusi RTT per ISP (ASN) dan kota transit yang muncul di traceroute. Penanggung jawab utama adalah Tim Infrastruktur (jaringan), dan perbaikannya lewat peering langsung dengan ISP, koneksi ke IX, dan pemilihan lokasi server. Kebijakan rute di sisi ISP perlu dibicarakan dengan Pihak Eksternal (ISP). Kasus ini juga menunjukkan bahwa memindahkan server lebih dekat ke pusat sebaran pemain saja sudah memberi dampak besar. - Penyebab terkait: isp-routing, isp-distance, rt-queue-drop - Sumber asli: [Riot Games](https://www.riotgames.com/en/news/fixing-internet-real-time-applications-part-i) ### riot-edge-2020 · Riot Games 2020: Host edge kelebihan beban di server League of Legends Eropa dan Brasil - Apa yang terjadi: Pada akhir Februari 2020, server League of Legends EUW, EUNE, dan BR beberapa kali mengalami gangguan, dan jumlah game baru yang dimulai turun tajam. Semua layanan backend seperti matchmaking dan server game berstatus normal, tetapi hampir tidak ada trafik yang masuk. Riot menunda jadwal mode turnamen (Clash) selama satu minggu agar tidak membukanya di cluster yang mungkin tidak stabil. Tulisan retrospektifnya tidak mencantumkan berapa lama setiap gangguan berlangsung. - Penyebab: Tiga hal terjadi bersamaan. Request ke satu layanan dibuat dengan keliru sehingga dalam kasus tertentu terus gagal dan terus dicoba ulang, dan jumlah request melonjak. Masalah kompatibilitas yang sudah diketahui antara sistem container dan versi OS membuat memori di dalam OS bocor. Upgrade baru selesai di sekitar 60% seluruh lingkungan container Riot, sedangkan cluster Eropa dan Amerika Latin masih dalam proses. Container edge, yang menerima trafik internet, menyaringnya, lalu meneruskannya ke backend, ditempatkan terpisah di dalam shard (kelompok server) yang sama, tetapi tidak ada yang mencegah container dari shard yang berbeda berkumpul di satu host. Akibatnya, setiap kali gangguan terjadi, container edge dari minimal tiga shard menumpuk di satu host. Lonjakan retry menghantam host itu, lalu kebocoran memori membuat host itu berhenti. - Pelajaran: Jika semua layanan backend menjawab “normal, tetapi trafik tidak masuk”, periksa bagian di depannya (edge, gateway, load balancer). Sinyal yang perlu diperiksa adalah jumlah koneksi masuk yang menumpuk di host tertentu, serta rasio kegagalan dan retry untuk request tertentu. Penanggung jawab utama adalah Tim Pengembang Game (server: request yang keliru dan cara retry), sedangkan aturan penempatan container, upgrade OS, dan alert penumpukan ditangani Tim Infrastruktur (server/OS). Riot memperbaiki kode request-nya, mengubah retry agar tidak melonjak, dan memasang alert penumpukan sampai penyebaran ke shard yang berbeda selesai diimplementasikan. - Penyebab terkait: in-gateway, in-cascade - Sumber asli: [Riot Games](https://www.leagueoflegends.com/en-gb/news/riot-games/incident-report-recent-outages-in-europe-brazil/) ### riot-euw-2021 · Riot Games 2021: Gangguan 5 jam di League of Legends EUW: satu DB pendukung menghentikan seluruh server - Apa yang terjadi: Pada 22 Januari 2021, server League of Legends EUW tidak berfungsi dengan benar selama sedikit lebih dari 5 jam. Metrik jumlah pemain yang login dan jumlah pemain yang sedang bermain terputus bersamaan, dan di antara dua kali restart, jumlah login bertambah tetapi hampir tidak ada game yang dimulai. - Penyebab: Server primer dari DB yang menangani fitur tidak penting mengalami kerusakan hardware, dan DB itu tidak dikonfigurasi untuk failover otomatis ke server cadangan. Setiap DB punya connection pool sendiri, tetapi semua pool memakai thread pool yang sama. Pekerjaan yang dikirim ke DB yang rusak tidak pernah selesai dan terus menahan thread, sampai seluruh sistem kehabisan thread. Di tengah banjir alert, tim lebih dulu mencurigai serangan jaringan berbahaya yang baru saja dialami dan pekerjaan hardware di region lain, sehingga alert dari DB yang rusak baru diperhatikan sekitar 1 jam kemudian. Semua sistem berjalan di satu JVM, jadi ketika GC berulang kali menghentikan proses selama beberapa detik di tengah beban reconnect setelah restart, pengumpulan metrik juga mengalami celah besar. Antrean login juga tidak mematuhi batas yang dikonfigurasi, sehingga arus pemain yang masuk naik turun tidak beraturan. - Pelajaran: Satu DB pendukung yang dianggap tidak penting pun bisa menghentikan semuanya lewat sumber daya bersama seperti thread pool. Sinyal yang perlu diperiksa adalah jumlah request yang menunggu per DB, utilisasi thread pool, serta rasio game yang dimulai terhadap jumlah login yang terlalu rendah. Penanggung jawabnya Tim Pengembang Game (server: isolasi thread pool dan timeout) dan Tim Infrastruktur (DB: failover otomatis). Saat alert membanjir, orang cenderung lebih dulu mencurigai masalah yang baru saja dialami (misalnya serangan), jadi singkirkan kemungkinan satu per satu sesuai urutan diagnosis (cakupan → waktu → lapisan). Setelah restart, periksa juga apakah antrean login benar-benar membatasi arus masuk sesuai konfigurasi. - Penyebab terkait: sp-threadpool, db-failover, in-cascade, mem-gc - Sumber asli: [Riot Games](https://www.riotgames.com/en/news/keeping-legacy-software-alive-case-study) ### roblox-2021 · Roblox 2021: Gangguan 73 jam di Roblox: perebutan sumber daya di cluster service discovery (Consul) - Apa yang terjadi: Gangguan dimulai pada sore hari 28 Oktober 2021 (waktu Pasifik) dengan beban CPU tinggi di satu server Consul. Pada pukul 16.35, jumlah pemain yang sedang online turun menjadi setengah dari biasanya, lalu seluruh layanan berhenti. Baru pada 31 Oktober pukul 16.45 semua pemain bisa masuk kembali, 73 jam sejak gangguan dimulai. Roblox menyebut layanannya dipakai 50 juta orang setiap hari. - Penyebab: Roblox memakai HashiCorp Consul untuk service discovery (fungsi yang dipakai layanan untuk saling menemukan alamat), health check, dan penyimpanan KV, dan satu cluster Consul menangani beberapa workload sekaligus. Ada dua akar penyebab. Pertama, fitur streaming baru di Consul, yang cakupannya diperluas selama beberapa bulan, diaktifkan juga untuk layanan routing trafik sehari sebelum gangguan, dan jumlah node layanan itu ditambah 50%. Di bawah beban baca dan tulis yang sama-sama sangat tinggi, fitur ini menimbulkan perebutan pada satu sumber daya bersama (channel Go). Di server dual socket (NUMA) dengan jumlah core lebih banyak yang dipasang sebagai pengganti selama gangguan, perebutannya makin parah. Kedua, pengelolaan daftar halaman kosong (freelist) di BoltDB, yang dipakai Consul untuk menyimpan log Raft, melambat secara tidak wajar: setiap penambahan data 16 kB atau kurang menulis 7,8 MB ke disk. Median latensi tulis KV yang biasanya di bawah 300 ms menjadi 2 detik, dan zero window (buffer TCP penuh) juga terlihat di server leader yang lambat. Karena telemetri bergantung pada Consul, metrik yang dibutuhkan untuk mencari penyebab ikut hilang. - Pelajaran: Jika sistem dasar yang diandalkan banyak layanan sekaligus (service discovery, penyimpanan konfigurasi, autentikasi) melambat, semua fitur berhenti bersamaan. Sinyal yang perlu diperiksa adalah latensi tulis, pergantian leader, dan CPU sistem itu, serta perubahan konfigurasi tepat sebelum gangguan. Penanggung jawabnya kedua tim, yaitu Tim Pengembang Game (server) dan Tim Infrastruktur (server/OS). Monitoring perlu dipisahkan agar tidak bergantung pada sistem yang dipantaunya, supaya metrik tetap bisa dilihat saat gangguan. Saat pemulihan, cache masih kosong sehingga sistem bisa runtuh lagi jika semua pemain masuk sekaligus. Karena itu Roblox mengatur porsi pemain yang boleh masuk lewat DNS dan menaikkannya sekitar 10% setiap tahap. - Penyebab terkait: in-cascade, sp-lock, rt-zero-window, db-cold-cache - Sumber asli: [Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021) ### ffxiv-2021 · Square Enix 2021: Kepadatan server saat rilis ekspansi FINAL FANTASY XIV dan error antrean login - Apa yang terjadi: Sejak early access ekspansi Endwalker pada Desember 2021, setiap World sangat padat. Antrean login memanjang, dan Error 2002 sering muncul saat login dari layar pemilihan karakter atau saat menunggu di antrean. Sebagian World dan zona juga down (Error 3001), dan antrean mengalami timeout (Error 4004). Saat pengumuman 11 Desember, pada hari ke-8 early access, kepadatan masih berlanjut. - Penyebab: Error 2002 muncul dalam dua kasus. Kasus pertama terjadi saat jumlah pemain yang menunggu di satu data center logis melebihi 17.000 orang. Ini adalah batas atas untuk mencegah server login down karena antrean terlalu panjang, dan saat batas ini tercapai, klien tertutup sepenuhnya. Pada 7 Desember, hardware cadangan untuk keperluan pengembangan dipasang ke server lobi untuk menaikkan batas itu. Error ini berkurang, tetapi antreannya justru makin panjang. Kasus kedua terjadi saat koneksi pemain yang sedang menunggu tidak stabil. Makin lama waktu tunggu, makin sering koneksi putus sesaat akibat packet loss di jalur internet atau Wi-Fi yang tidak stabil. Server lobi menunggu reconnect selama puluhan detik hingga sekitar 1 menit. Pemain yang tersambung kembali dalam waktu itu melanjutkan dari posisinya di antrean, sedangkan yang melewati batas itu harus mulai lagi dari paling belakang. Square Enix menyebut sebagian besar laporan termasuk kasus ini. Akibat kekurangan chip semikonduktor, World juga tidak bisa langsung ditambah. - Pelajaran: Makin panjang antrean, makin sering koneksi yang putus sesaat pada pemain yang sedang menunggu berubah menjadi error koneksi. Dalam kepadatan yang sama, error menumpuk pada pemain yang memakai Wi-Fi atau koneksi tidak stabil, sehingga masalahnya menjadi masalah yang “hanya dialami sebagian pemain”. Sinyal yang perlu diperiksa adalah panjang antrean dan waktu tunggu, serta porsi koneksi yang putus saat menunggu di antrean di antara semua alasan koneksi terputus. Penanggung jawab utama adalah Tim Pengembang Game (server: batas atas antrean dan masa tenggang reconnect), dan Tim Infrastruktur ikut menambah server lobi dan server World. Dengan masa tenggang reconnect yang longgar, koneksi pemain yang putus sesaat lebih jarang berujung pada hilangnya nomor antrean. - Penyebab terkait: in-login-queue, hn-wifi, rt-wireless - Sumber asli: [Square Enix](https://na.finalfantasyxiv.com/lodestone/news/detail/6a94b30182b6d963994fdc0b789264ac9f24986f) ### cloudflare-2020 · Cloudflare 2020: Trafik hilang di sebagian kota akibat kesalahan konfigurasi backbone Cloudflare - Apa yang terjadi: Banyak game menyerahkan web, API, dan proteksi DDoS kepada penyedia CDN, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Pada 17 Juli 2020 pukul 21.12–21.39 (UTC), selama 27 menit, trafik di seluruh jaringan Cloudflare turun sekitar 50%. Dampaknya terbatas pada sebagian lokasi di kota-kota Amerika Serikat, Eropa, Rusia, dan Brasil yang terhubung ke backbone. Lokasi lain normal. - Penyebab: Gangguan di segmen backbone Newark–Chicago membuat segmen Atlanta–Washington mengalami kongesti, sehingga seorang engineer mengubah konfigurasi router untuk mengurangi trafik backbone di Atlanta. Seharusnya seluruh entri kebijakan (term) dinonaktifkan, tetapi yang dinonaktifkan hanya kondisi di dalamnya (prefix-list). Akibatnya, router Atlanta menyebarkan semua rute BGP ke seluruh backbone dengan prioritas lebih tinggi (local-preference 200). Prioritas yang diberikan setiap lokasi untuk rute ke servernya sendiri adalah 100, sehingga semua trafik dari lokasi yang terhubung ke backbone tersedot ke Atlanta. Atlanta kelebihan beban, sedangkan lokasi yang terdampak hampir tidak punya trafik untuk diproses. Layanan pulih setelah router Atlanta dikeluarkan dari backbone. Cloudflare menyatakan gangguan ini tidak berkaitan dengan serangan atau pembobolan. - Pelajaran: Jika hanya pemain di kota atau wilayah tertentu yang serentak mengalami disconnect atau tidak bisa masuk / loading tanpa henti, sementara pemain lain normal, curigai dulu perubahan konfigurasi rute yang baru saja dilakukan. Di grafik, CPU dan trafik melonjak hanya di satu lokasi, sedangkan lokasi yang terdampak justru turun mendekati 0. Penanggung jawab utama adalah Tim Infrastruktur (jaringan), atau Pihak Eksternal jika gangguannya ada di sisi penyedia. Cloudflare memutuskan untuk memasang batas jumlah rute yang boleh diterima setiap sesi BGP backbone (maximum-prefix), dan menyesuaikan prioritas agar satu lokasi tidak bisa menarik trafik lokasi lain. - Penyebab terkait: isp-bgp, rt-path - Sumber asli: [Cloudflare](https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/) ### fastly-2021 · Fastly 2021: Error global pada CDN Fastly - Apa yang terjadi: Banyak game mendistribusikan file patch, launcher, dan halaman web lewat CDN, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Mulai 8 Juni 2021 pukul 09.47 (UTC), 85% jaringan Fastly mengembalikan error. Dalam 49 menit, 95% jaringan kembali normal, dan gangguan selesai ditangani pada pukul 12.35. - Penyebab: Deploy software yang dimulai pada 12 Mei mengandung bug yang terpicu saat konfigurasi pelanggan tertentu bertemu kondisi tertentu. Pada 8 Juni, seorang pelanggan mengunggah perubahan konfigurasi yang valid, dan kondisi itu terpenuhi. Fastly mendeteksi anomali dalam 1 menit, dan pemulihan dimulai setelah konfigurasi pelanggan penyebabnya ditemukan dan dinonaktifkan. Deploy perbaikan bug dimulai pada hari yang sama pukul 17.25. - Pelajaran: Kode yang sudah di-deploy beberapa minggu sebelumnya pun bisa seketika menjadi gangguan global saat bertemu kondisi langka. Di sisi game, sinyal yang perlu diperiksa adalah tingkat error HTTP untuk request patch, launcher, dan web yang naik serentak di semua wilayah, serta halaman status penyedia CDN. Cirinya, koneksi game yang sudah tersambung tetap normal jika tidak lewat CDN, dan yang terblokir hanya koneksi baru, unduhan patch, dan login web. Penanggung jawab utama adalah Pihak Eksternal (penyedia CDN), sedangkan Tim Pengembang Game dan Tim Infrastruktur menyiapkan rute cadangan, misalnya memakai lebih dari satu CDN atau mengambil langsung dari server origin. - Penyebab terkait: in-external - Sumber asli: [Fastly](https://www.fastly.com/blog/summary-of-june-8-outage) ### meta-2021 · Meta 2021: Gangguan Facebook: satu perintah di backbone sampai menghilangkan DNS - Apa yang terjadi: Gangguan infrastruktur yang pelajarannya berlaku juga untuk jaringan dan DNS milik perusahaan game sendiri. Pada 4 Oktober 2021, layanan Facebook (kini Meta) tidak bisa diakses di seluruh dunia. Backbone yang menghubungkan data center-nya terputus seluruhnya, dan server DNS Facebook tidak bisa ditemukan dari internet. Tulisan retrospektifnya tidak mencantumkan berapa lama gangguan berlangsung. - Penyebab: Dalam pekerjaan maintenance rutin, sebuah perintah yang dijalankan untuk memeriksa kapasitas backbone global secara tidak sengaja memutus semua koneksi backbone, dan tools audit yang seharusnya memblokir perintah semacam itu gagal mencegahnya karena bug. Server DNS di lokasi kecil dirancang untuk menganggap dirinya tidak sehat dan menarik pengumuman rute BGP jika tidak bisa berkomunikasi dengan data center, sehingga server DNS tidak bisa dijangkau dari internet padahal masih berjalan. Jalur akses biasa dan akses out-of-band sama-sama terputus, dan tools internal juga kehilangan DNS, sehingga engineer harus dikirim langsung ke data center, dan prosedur keamanan membuat prosesnya makin lama. Saat pemulihan, konsumsi daya di setiap data center sudah turun puluhan MW, dan mengembalikan semuanya sekaligus dinilai berisiko bagi banyak hal, dari instalasi listrik sampai cache. Karena itu beban dinaikkan secara bertahap. - Pelajaran: Jika gejala tidak bisa masuk / loading tanpa henti muncul serentak di semua wilayah dan semua ISP, periksa DNS dan rute BGP sebelum memeriksa server game. Hal ini bisa dipastikan juga dari luar perusahaan, lewat lookup DNS eksternal dan informasi rute BGP yang terbuka untuk publik. Penanggung jawab utama adalah Tim Infrastruktur (jaringan). Periksa lebih dulu bahwa jalur akses out-of-band dan tools internal yang dipakai saat gangguan tidak bergantung pada DNS dan jaringan yang sama, dan saat pemulihan, naikkan beban secara bertahap agar reconnect tidak datang sekaligus. - Penyebab terkait: isp-bgp, isp-dns - Sumber asli: [Meta](https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/) ### aws-2021 · AWS 2021: Kongesti jaringan internal AWS us-east-1 - Apa yang terjadi: Banyak game menempatkan server, login, dan data di cloud publik, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Pada 7 Desember 2021 pukul 07.30 PST, jaringan internal region Virginia Utara (us-east-1) mengalami kongesti. Mulai pukul 07.33, error dan latensi API EC2 meningkat sehingga instance baru sulit dijalankan (peluncuran instance pulih pukul 14.40), lalu menyusul kegagalan login konsol, perubahan konfigurasi Route 53 yang tidak bisa dilakukan, serta metrik CloudWatch yang terlambat dan sebagian hilang. Perangkat jaringan pulih sepenuhnya pukul 14.22. Instance EC2 yang sudah berjalan dan respons DNS yang sudah ada tidak terdampak. - Penyebab: Proses otomatis untuk menambah kapasitas sebuah layanan di jaringan utama memicu perilaku tak terduga dari banyak sekali klien di jaringan internal, sehingga upaya koneksi melonjak. Perangkat yang menghubungkan jaringan internal dan jaringan utama meluap sehingga komunikasi melambat, dan keterlambatan itu kembali menambah upaya koneksi dan retry, sehingga kongesti terus berlanjut. Klien sebenarnya punya mekanisme backoff yang memperpanjang jarak waktu di antara request saat kongesti seperti ini, tetapi mekanisme itu tidak bekerja dengan benar karena cacat tersembunyi. Monitoring internal juga bergantung pada jaringan yang sama, sehingga tim operasional menangani gangguan tanpa metrik real-time dan hanya mengandalkan log. - Pelajaran: Jika retry tidak bisa memperpanjang jedanya, kongesti singkat bisa menjadi gangguan berjam-jam. Dari sisi game, server game yang sudah berjalan mungkin baik-baik saja, tetapi penambahan server baru (autoscaling), login, matchmaking, dan pembayaran yang memakai API cloud, serta monitoring bisa ikut terblokir. Sinyal yang perlu diperiksa adalah halaman status penyedia cloud, tingkat error API cloud, dan kegagalan peluncuran instance. Penanggung jawab utama adalah Pihak Eksternal (penyedia cloud). Tim Pengembang Game memasang exponential backoff dengan jeda acak dan batas jumlah percobaan pada semua retry, sedangkan Tim Infrastruktur menyiapkan kapasitas cadangan agar tetap bertahan saat penambahan server terblokir, serta alternatif di region lain. - Penyebab terkait: in-cascade, in-autoscale, in-external - Sumber asli: [AWS](https://aws.amazon.com/message/12721/) ### cloudflare-dns-2025 · Cloudflare 2025: Gangguan DNS publik Cloudflare 1.1.1.1 - Apa yang terjadi: Gangguan pada resolver DNS publik yang diatur sendiri oleh pemain di perangkat atau router. Pada jenis gangguan ini, semua game dan layanan ikut terblokir, tetapi hanya bagi pemain yang memakai pengaturan itu. Pada 14 Juli 2025 pukul 21.52–22.54 (UTC), selama 62 menit, resolver 1.1.1.1 tidak merespons di seluruh dunia. Cloudflare menyatakan bahwa bagi banyak pengguna, ini praktis berarti tidak bisa memakai layanan internet apa pun. Query UDP, TCP, dan DNS over TLS terdampak, sedangkan DNS over HTTPS, yang tersambung lewat nama domain, relatif stabil. - Penyebab: Pada 6 Juni, saat menyiapkan topologi layanan (konfigurasi yang menentukan lokasi mana yang mengumumkan rentang IP tertentu) untuk layanan lain yang akan dipakai nanti, rentang IP resolver 1.1.1.1 tidak sengaja ikut dimasukkan ke konfigurasi itu. Pada 14 Juli, saat konfigurasi layanan tersebut diubah, lokasi yang mengumumkan rentang resolver menyusut dari semua lokasi menjadi satu lokasi yang sedang offline, dan rute BGP-nya ditarik di seluruh dunia. Perubahan ini langsung menyebar ke semua data center tanpa melalui canary deployment. Setelah konfigurasi dikembalikan pada pukul 22.20, trafik kembali hingga sekitar 77%, tetapi selama itu konfigurasi IP yang diperlukan sudah terhapus dari sekitar 23% server edge. Konfigurasi ulangnya membuat layanan baru normal pada pukul 22.54. Cloudflare menyatakan ini kesalahan konfigurasi internal yang tidak berkaitan dengan serangan atau pembajakan BGP (BGP hijacking). - Pelajaran: Jika server game dan pemain lain normal, tetapi hanya sebagian pemain yang mengalami tidak bisa masuk / loading tanpa henti ke server login atau server patch, curigai DNS yang dipakai pemain tersebut. Cirinya, sesi yang sudah tersambung tetap bertahan dan hanya koneksi baru yang gagal. Penyebabnya langsung terpilah jika pemain diminta mengganti pengaturan DNS atau melakukan lookup alamat server secara langsung. Penanggung jawab utama adalah Pihak Eksternal (operator DNS, ISP). Jika Tim Pengembang Game (klien) membedakan kegagalan resolusi nama dari error lain dalam pesan ke pemain, tim CS bisa langsung menentukan penyebabnya. - Penyebab terkait: isp-dns, isp-bgp - Sumber asli: [Cloudflare](https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/) ### aws-2025 · AWS 2025: Gangguan DNS DynamoDB di AWS us-east-1 dan pemulihan yang lama - Apa yang terjadi: Banyak game menempatkan server, login, dan data di cloud publik, jadi ini termasuk jenis gangguan infrastruktur yang ikut berdampak pada game. Dari 19 Oktober 2025 pukul 23.48 sampai 20 Oktober pukul 14.20 (PDT), region Virginia Utara terdampak dalam tiga tahap. Error API DynamoDB meningkat sampai pukul 02.40 tanggal 20; peluncuran instance EC2 baru gagal dari pukul 02.25 sampai 10.36 (masalah koneksi pada sebagian instance baru teratasi pukul 13.50); dan error koneksi di sebagian Network Load Balancer (NLB) meningkat dari pukul 05.30 sampai 14.09. - Penyebab: Otomatisasi yang mengelola DNS DynamoDB mengandung race condition tersembunyi. Di antara eksekutor yang menerapkan rencana DNS di availability zone yang berbeda (DNS Enactor), satu eksekutor yang tertunda sangat lama menimpa rencana baru dengan rencana lama. Tepat setelah itu, proses pembersihan dari eksekutor lain menghapus rencana lama tersebut, sehingga record DNS untuk endpoint region (dynamodb.us-east-1.amazonaws.com) menjadi kosong. Otomatisasi tidak bisa memperbaikinya, sehingga pemulihan harus dilakukan manual. Sistem pengelola server fisik EC2 bergantung pada DynamoDB, sehingga selama itu lease yang dipegang untuk setiap server fisik kedaluwarsa. Setelah DynamoDB pulih, jumlah server fisik terlalu banyak sehingga proses membuat ulang lease mengalami timeout sebelum selesai, dan pekerjaan retry kembali menumpuk hingga sistem masuk ke kondisi “congestive collapse” (runtuh akibat kongesti). Konfigurasi jaringan untuk instance yang baru dijalankan menyebar dengan lambat, sehingga health check NLB bolak-balik antara berhasil dan gagal, dan node yang sehat pun berulang kali keluar dari DNS lalu masuk kembali. - Pelajaran: Kesalahan record DNS di satu tempat menjalar ke layanan lain yang bergantung pada layanan itu, dan setelah penyebabnya teratasi pun, pemulihan masih butuh beberapa jam lagi karena pekerjaan yang tertunda dan health check yang tidak stabil. Dari sisi game, server yang sudah berjalan mungkin bertahan, tetapi server baru tidak bisa dijalankan sehingga autoscaling berhenti, dan health check yang tidak stabil bisa membuat load balancer mengeluarkan server yang sebenarnya normal. Sinyal yang perlu diperiksa adalah halaman status cloud, tingkat error API layanan terkelola (managed service), kegagalan peluncuran instance, dan jumlah target sehat di load balancer. Penanggung jawab utama adalah Pihak Eksternal (penyedia cloud), sedangkan Tim Infrastruktur membatasi jumlah server yang boleh keluar sekaligus karena gagal health check dan menyiapkan alternatif di region lain. - Penyebab terkait: in-external, in-cascade, in-autoscale, dc-lb-imbalance, isp-dns - Sumber asli: [AWS](https://aws.amazon.com/message/101925/) ## Istilah - **Ping** (Ping, RTT): Waktu yang dibutuhkan sinyal dari Anda untuk sampai ke server dan kembali lagi (pulang-pergi). Ping yang ditampilkan game kadang juga mencakup waktu tunggu pemrosesan di server. - **Latensi** (Latency): Waktu yang dibutuhkan paket dari berangkat sampai tiba. Istilah ini sering dipakai untuk satu arah saja, jadi nilainya kira-kira separuh ping. - **Jitter** (Jitter): Variasi selang waktu kedatangan paket. Dengan rata-rata ping yang sama pun, jitter yang besar membuat gambar patah-patah. - **Paket** (Packet): Satu kesatuan data yang dikirim sekaligus lewat jaringan. Ukurannya biasanya maksimal 1.500 byte; update game umumnya hanya puluhan hingga ratusan byte. - **Packet loss** (Packet loss): Paket yang dikirim hilang dan tidak pernah sampai. Pada game yang memakai TCP, packet loss 1% saja sudah terasa sebagai tersendat sesaat setiap beberapa detik hingga belasan detik sekali. Pada game UDP yang punya interpolasi dan pengiriman input berulang, packet loss sampai beberapa persen pun kadang masih bisa ditutupi. - **Bandwidth** (Bandwidth): Jumlah data maksimum yang bisa dikirim sebuah koneksi dalam 1 detik (Mbps). Konsep ini berbeda dari seberapa cepat data tiba (latensi). - **Tick** (Tick): Satuan satu kali server menghitung state game. Server 20 tick menghitung 20 kali per detik, yaitu setiap 50 ms. - **Tick rate** (Tick rate): Berapa kali tick dijalankan dalam 1 detik. Makin tinggi, makin cepat responsnya, tetapi biaya server dan volume data yang dikirim ikut naik. Untuk menghemat volume kiriman, frekuensi pengiriman paket kadang dibuat lebih rendah dari tick rate. - **Tick budget** (Tick budget): Batas waktu untuk menyelesaikan satu tick. Jika terlewati, tick berikutnya terlambat dan interval tick memanjang. - **FPS** (Frames per second): Berapa kali layar digambar dalam 1 detik. Pada 60 FPS, satu frame berarti 16,7 ms. - **Frame time** (Frame time): Waktu yang dibutuhkan untuk menggambar satu frame. Bagi rasa bermain, frame yang sesekali melonjak lebih berpengaruh daripada rata-rata FPS. - **Snapshot** (Snapshot): Ringkasan “state game saat ini” yang dikirim server setiap tick. Isinya posisi, HP, status, dan sebagainya. Biasanya yang dikirim hanya bagian yang berbeda dari state yang sudah dimiliki penerima (kompresi delta). - **Interpolasi** (Interpolation): Teknik menggambar transisi di antara dua snapshot yang diterima agar gerakan terlihat mulus. Konsekuensinya, yang ditampilkan sedikit tertinggal dari kondisi terkini. - **Buffer interpolasi** (Interpolation buffer): Penundaan yang sengaja diberikan sebelum menggambar agar interpolasi bisa dilakukan. Ini ruang cadangan untuk meredam jitter dan satu atau dua paket yang hilang. Biasanya 2 kali selang paket (100 ms jika menerima 20 kali per detik), dan ada game yang menambahnya sendiri saat jitter membesar. - **Ekstrapolasi** (Extrapolation, Dead reckoning): Teknik menebak posisi berikutnya dari kecepatan terakhir saat paket baru belum datang, lalu menggambarnya. Jika tebakannya meleset, hasilnya terlihat seperti teleport, sehingga banyak game hanya menebak sampai sekitar 0,25 detik lalu berhenti (nilai default Source engine 0,25 detik). - **Prediksi sisi klien** (Client-side prediction): Teknik menggerakkan karakter Anda lebih dulu di layar tanpa menunggu konfirmasi server. - **Rekonsiliasi server** (Reconciliation): Proses membandingkan hasil dari server dengan prediksi, lalu mengoreksi posisi karakter Anda. Mulai dari posisi yang sudah dikonfirmasi server, input Anda yang belum dikonfirmasi diterapkan ulang. Jika selisihnya besar, hasilnya terlihat sebagai rubber banding. - **Lag compensation** (Lag compensation): Teknik hit registration: server memutar mundur waktu ke momen yang dilihat penyerang untuk memastikan serangan itu kena atau tidak. Agar pihak yang terkena tidak dirugikan, rentang putar mundurnya diberi batas atas. Game shooter kompetitif umumnya memakai sekitar 0,2–0,25 detik, dan ada juga yang memutar mundur sampai 1 detik seperti nilai default Source engine. - **Server otoritatif** (Authoritative server): Desain yang menyerahkan keputusan akhir hanya kepada server. Cara ini mencegah cheating, tetapi setiap hasil harus menunggu pulang-pergi ke server. Karena itu, waktu tunggunya ditutupi dengan prediksi dan feedback sisi klien. - **Lockstep** (Deterministic lockstep): Model yang hanya bertukar input, lalu semua pihak menghitung hal yang sama pada giliran yang sama. Setiap input diberi input delay tetap, dan jika input satu orang saja terlambat, semua pemain menunggu. - **Buffer input di server** (Server-side input buffer): Buffer tempat server menampung sedikit input dari tiap pemain, lalu mengambilnya satu per tick. Pemain dengan jitter besar pun terlihat mulus di mata pemain lain, tetapi aksi pemain itu dipastikan server lebih lambat sebesar waktu tampungnya. - **Listen server** (Listen server): Model ketika PC salah satu pemain menjalankan game sekaligus berperan sebagai server. Ping host bernilai 0, tetapi jika koneksi atau PC host lambat, semua pemain mengalami lag. - **Phasing** (Phasing): Fitur yang menampilkan NPC dan medan yang berbeda di lokasi yang sama sesuai progres quest. Jika progres dua karakter berbeda, wajar bila NPC tidak ada di layar salah satunya. - **Rollback netcode** (Rollback netcode (GGPO)): Model yang memprediksi input lawan dan menjalankan game lebih dulu; jika input sebenarnya berbeda, game diputar mundur ke frame sebelumnya lalu dihitung ulang. Banyak dipakai di game fighting. Istilah ini berbeda dari rollback di DB. - **Input buffering** (Input buffer, spell queue): Input berikutnya yang ditekan sesaat sebelum cooldown atau animasi selesai disimpan dulu, lalu dijalankan tepat saat selesai. Dengan begitu, waktu pulang-pergi tidak menyela di antara rangkaian combo. - **Feedback sisi klien** (Client-side feedback): Animasi, suara, dan efek diputar lebih dulu tanpa menunggu konfirmasi server. Hanya hasil yang perlu dipastikan, seperti damage dan hadiah, yang menunggu jawaban server. Jika server menolak, apa yang sudah ditampilkan harus dibatalkan. - **TCP** (Transmission Control Protocol): Protokol yang mengirim data secara berurutan dan lengkap. Paket berikutnya tidak diteruskan ke game sampai paket yang hilang diterima ulang. - **UDP** (User Datagram Protocol): Protokol yang meneruskan data apa adanya tanpa jaminan apa pun. Tidak ada waktu tunggu, tetapi packet loss dan urutan harus ditangani sendiri oleh game. - **Reliable UDP** (Reliable UDP (KCP, ENet…)): Pendekatan yang mengimplementasikan sendiri retransmisi dan jaminan urutan di atas UDP, sebatas yang diperlukan. - **HOL blocking** (Head-of-line blocking): Kondisi saat satu data di depan tertahan sehingga semua data di belakangnya ikut menunggu. Inilah penyebab fast forward pada TCP. - **RTO** (Retransmission timeout): Timer retransmisi. Waktu tunggu sebelum TCP menganggap paket hilang lalu mengirimnya ulang. Di Linux minimal ping + 200 ms, dan menjadi dua kali lipat setiap kali gagal. - **Algoritma Nagle** (Nagle’s algorithm): Fitur TCP yang menghemat jumlah paket dengan menampung data kecil sampai ACK untuk data sebelumnya datang, lalu mengirimnya sekaligus. Di game, fitur ini biasanya harus dimatikan. - **TCP_NODELAY** (TCP_NODELAY): Opsi socket untuk mematikan algoritma Nagle. Pesan kecil langsung dikirim. - **Delayed ACK** (Delayed ACK): Fitur yang sedikit menunda konfirmasi terima agar bisa dikirim bersama data lain. Di Linux biasanya 40 ms (maksimal 200 ms); di Windows, versi lama memakai 200 ms dan versi baru 40 ms. - **Buffer socket** (SO_SNDBUF / SO_RCVBUF): Ukuran ruang tunggu kirim dan terima yang disediakan OS untuk setiap socket. Jika terlalu kecil, buffer meluap; jika terlalu besar, data lama menumpuk dan harus menunggu. - **keepalive** (SO_KEEPALIVE): Fitur TCP untuk memeriksa apakah koneksi idle masih hidup. Secara default nonaktif, dan meski diaktifkan, dengan nilai default pemeriksaan baru dilakukan setelah 2 jam. - **RST** (TCP reset): Sinyal TCP yang memutus koneksi secara paksa saat itu juga. Data yang belum terkirim dibuang. - **Heartbeat** (Heartbeat): Sinyal “masih hidup” yang dikirim game sendiri secara berkala. Dipakai untuk mendeteksi koneksi yang terputus dan menjaga koneksi di perangkat yang ada di tengah jalur. - **Timeout** (Timeout): Batas waktu: jika tidak ada respons selama waktu ini, dianggap gagal. Terlalu pendek memicu salah deteksi, terlalu panjang membuat deteksi terlambat. - **NAT** (Network Address Translation): Fitur router yang membuat banyak perangkat di rumah keluar ke internet dengan satu IP publik, sambil mencatat setiap koneksi di tabel NAT. - **CGNAT** (Carrier-grade NAT): NAT berskala besar milik ISP yang membagi satu IP untuk banyak pelanggan. - **MTU** (Maximum Transmission Unit): Ukuran paket maksimum yang bisa dikirim sekaligus. Biasanya 1.500 byte, dan lebih kecil di jalur VPN atau PPPoE. - **Bufferbloat** (Bufferbloat): Kondisi saat perangkat menumpuk antrean terlalu besar sehingga latensi membengkak hingga ratusan ms. - **SQM** (Smart Queue Management (fq_codel, CAKE)): Fitur router yang menjaga antrean tetap pendek dan mengirim data secara adil per aliran. Solusi untuk bufferbloat. - **QoS** (Quality of Service): Fitur yang memberi prioritas agar trafik penting dikirim lebih dulu. - **Peering** (Peering): Titik tempat jaringan antar-ISP saling terhubung. Mudah padat pada malam hari. - **BGP** (Border Gateway Protocol): Aturan yang dipakai antar-ISP untuk saling memberi tahu lewat rute mana data dikirim di internet. Jika berubah, rute dan ping ikut berubah. - **DDoS** (Distributed Denial of Service): Serangan yang melumpuhkan layanan dengan mengirim trafik dalam jumlah besar dari banyak sumber. - **Scrubbing center** (DDoS scrubbing center): Lokasi milik penyedia proteksi DDoS yang lebih dulu menerima trafik menuju server saat terjadi serangan, menyaring trafik serangan, lalu hanya meneruskan trafik normal. Jika lokasinya jauh, rutenya menjadi lebih panjang. - **Firewall** (Firewall): Perangkat atau program yang hanya meloloskan koneksi yang diizinkan. Koneksi dilacak di tabel sesi. - **Load balancer** (Load balancer): Perangkat yang membagi koneksi masuk ke beberapa server. - **Tabel sesi** (Session table, conntrack): Tabel tempat perangkat atau OS melacak koneksi yang sedang aktif. Ukurannya terbatas. - **Microburst** (Microburst): Lonjakan trafik dalam waktu sangat singkat (1 ms atau kurang), meskipun rata-ratanya rendah. - **NIC** (Network Interface Card): Kartu jaringan pada server. - **Ring buffer** (Ring buffer): Buffer yang menampung paket yang diterima NIC sampai diambil CPU. Buffer ini memakai slot dalam jumlah tetap secara bergiliran; jika semua slot penuh, paket baru dibuang. - **Interrupt** (Interrupt): Sinyal dari perangkat keras yang memberi tahu CPU bahwa “ada pekerjaan baru”. - **RSS** (Receive Side Scaling): Fitur NIC yang membagi paket masuk ke beberapa antrean terima (RX queue) agar diproses oleh beberapa core CPU. - **PPS** (Packets per second): Jumlah paket per detik. Server game sering lebih dulu mencapai batas di angka ini daripada di bandwidth. - **Kernel** (Kernel): Inti sistem operasi. Mengurus jaringan, memori, dan pembagian CPU. - **backlog** (Listen backlog): Antrean tempat permintaan koneksi baru menunggu sampai diambil server. Jika antrean penuh, Linux membuang permintaan baru diam-diam, sedangkan Windows mengirim respons penolakan. - **TIME_WAIT** (TIME_WAIT): Status ketika pihak yang lebih dulu menutup koneksi menahan kombinasi port tersebut untuk sementara (60 detik di Linux) untuk berjaga-jaga terhadap paket yang datang terlambat. - **CPU steal** (Steal time): Waktu tunggu sebuah virtual machine yang ingin memakai CPU, karena server fisik sedang memberikan CPU ke virtual machine lain. Terlihat di nilai st pada top. - **CPU throttling** (CFS throttling): Mekanisme yang memaksa container berhenti sampai periode berikutnya jika kuota CPU (quota) sudah habis dalam satu periode (CFS period, biasanya 100 ms). - **File descriptor** (File descriptor): Nomor (fd) yang diberikan untuk setiap file dan koneksi yang dibuka proses. Jumlahnya terbatas. - **Thread** (Thread): Unit kerja yang berjalan secara independen di dalam program. Beberapa thread bisa berjalan bersamaan. - **Context switching** (Context switch): Pergantian thread yang sedang dijalankan CPU ke thread lain. Proses ini memakan biaya (overhead). - **Lock** (Lock, Mutex): Penguncian agar data bersama hanya bisa dipakai oleh satu thread pada satu waktu. - **Deadlock** (Deadlock): Kondisi saat beberapa thread saling menunggu lock yang dipegang thread lain sehingga berhenti selamanya. - **Thread pool** (Thread pool): Kumpulan worker thread yang dibuat lebih dulu. Jika semuanya sibuk, pekerjaan baru harus menunggu. - **I/O asinkron** (epoll, IOCP, io_uring): Cara kerja yang tidak menunggu operasi input/output selesai: program mengerjakan hal lain dan menerima notifikasi saat operasi itu selesai. - **AOI** (Area of Interest): “Jangkauan yang bisa dilihat” oleh setiap pemain. Hanya perubahan di dalam jangkauan ini yang dikirim, sehingga volume data berkurang. Untuk menekan biaya menghitung siapa saja yang ada di dalam jangkauan, peta biasanya dibagi menjadi grid dan hanya sel-sel terdekat yang diperiksa. - **Broadcast** (Broadcast, fan-out): Pengiriman satu perubahan ke banyak pemain yang bisa melihatnya. Jika semua pemain yang berkumpul saling melihat, volume yang harus dikirim naik sebanding dengan kuadrat jumlah pemain. - **GC** (Garbage collection): Fitur yang otomatis mengambil kembali memori yang sudah tidak dipakai. Selama GC berjalan, program kadang berhenti. - **Heap** (Heap): Area memori yang dialokasikan untuk program setiap kali dibutuhkan selama program berjalan. - **Kebocoran memori** (Memory leak): Bug yang membuat pemakaian memori terus naik karena memori yang sudah selesai dipakai tidak dikembalikan. Meski ada GC, bug ini tetap terjadi jika objek yang sudah tidak dipakai masih direferensikan di suatu tempat. - **Swap** (Swap, paging): Pemindahan sebagian isi memori ke disk karena RAM tidak cukup. Mengakses kembali memori yang sudah dipindahkan itu lebih dari 1.000 kali lebih lambat daripada RAM. - **OOM killer** (Out-of-memory killer): Fitur Linux yang memilih proses dengan pemakaian memori terbesar lalu menghentikannya secara paksa saat memori habis. Pada container, fitur ini sudah bekerja begitu batas memorinya tercapai. - **Cache miss** (Cache miss): Kondisi saat data tidak ada di cache dekat CPU sehingga harus diambil dari memori yang lebih lambat. - **IOPS** (I/O operations per second): Jumlah operasi baca dan tulis yang bisa diproses disk dalam 1 detik. Pada disk cloud, batasnya ditentukan oleh besar biaya yang dibayar. - **fsync** (fsync): Perintah yang menunggu sampai data benar-benar tersimpan di disk. Penulisan biasa masuk dulu ke memori OS lalu baru ditulis ke disk belakangan, sehingga data bisa hilang jika listrik server mati di antaranya. fsync aman, tetapi lambat. - **Burst credit** (Burst credits): Saldo kredit yang dikumpulkan disk atau server cloud agar sesaat bisa bekerja di atas performa dasarnya. Jika habis, performanya turun ke tingkat dasar. - **Indeks** (Index): Struktur pencarian cepat di DB. Tanpa indeks, seluruh tabel harus dibaca. - **Full table scan** (Full table scan): Query yang memeriksa semua baris tabel tanpa memakai indeks. - **Query plan** (Query plan): Cara yang dipilih DB untuk menjalankan query: urutan langkahnya dan indeks yang dipakai. Meski kodenya tidak berubah, query yang sama bisa tiba-tiba lambat jika DB mengganti rencananya. - **Transaksi** (Transaction): Sekelompok operasi DB yang diikat menjadi satu: “berhasil semua atau gagal semua”. Trade antarpemain wajib diproses dalam transaksi. Baris yang diubah tetap terkunci sampai transaksi selesai, jadi makin singkat makin baik. - **Connection pool** (Connection pool): Kumpulan koneksi DB yang dibuka lebih dulu. Jika semuanya terpakai, permintaan baru harus menunggu. - **Hot row** (Hot row): Satu baris yang ingin diubah banyak permintaan sekaligus. Penyebab perebutan lock. - **Replication lag** (Replication lag): Selisih waktu ketika DB replika tertinggal dan belum menyusul DB primer. - **Rollback** (Rollback): Penyimpanan dibatalkan dan data kembali ke kondisi sebelumnya. Pemain merasakannya sebagai “item hilang”. - **Cache** (Cache (Redis etc.)): Salinan data yang sering dipakai di tempat yang lebih cepat diakses. Mengurangi beban DB. - **Checkpoint** (Checkpoint): Proses berkala ketika DB menulis sekaligus ke disk perubahan yang dikumpulkan di memori. Saat itu, penyimpanan dan pembacaan data bisa melambat sebentar. - **Failover** (Failover): Peralihan ke server atau DB cadangan saat server atau DB utama down. Selama peralihan, data tidak bisa disimpan untuk sementara, dan jika replikasinya tertinggal, data terakhir bisa hilang. - **MVCC** (Multi-version concurrency control): Cara DB menyimpan versi lama data untuk sementara agar proses yang membaca dan yang mengubah tidak saling menghalangi. Jika ada transaksi yang terbuka lama, versi lama menumpuk dan DB melambat. - **Cache stampede** (Cache stampede): Kondisi saat cache kosong serentak sehingga permintaan membanjiri sumber aslinya (DB). - **Gateway** (Gateway): Server perantara yang menerima koneksi klien dan meneruskannya ke server game di belakangnya. - **Circuit breaker** (Circuit breaker): Mekanisme yang memutus sementara pemanggilan ke layanan yang terus gagal dan langsung menganggapnya gagal, untuk mencegah kegagalan berantai. Setelah beberapa saat, layanan itu dipanggil satu atau dua kali sebagai percobaan; jika sudah pulih, pemanggilan diizinkan lagi. - **Kegagalan berantai** (Cascading failure): Gangguan di satu titik yang merambat ke layanan lain mengikuti rantai pemanggilan. - **Autoscaling** (Autoscaling): Fitur yang menambah dan mengurangi jumlah server secara otomatis sesuai beban. Penambahan server butuh waktu. - **Watchdog** (Watchdog): Timer yang memantau apakah server berhenti. Jika game loop berhenti lebih lama dari batas yang ditentukan (beberapa hingga puluhan detik), watchdog menyimpan catatan kondisi (dump), lalu menghentikan server secara paksa agar dinyalakan ulang. - **Utilisasi** (Utilization): Persentase waktu sibuk worker (pemroses permintaan, seperti core CPU, thread, atau koneksi DB). Di atas 80–90%, antrean bertambah drastis. - **p99** (99th percentile): Nilai yang 99 dari 100 kejadian lebih cepat darinya, dan sekitar 1 kejadian lebih lambat. Menggambarkan lag yang dirasakan pemain lebih baik daripada rata-rata. - **V-Sync** (Vertical sync): Fitur yang mengirim frame mengikuti siklus refresh layar. Screen tearing hilang, tetapi muncul input lag, dan jika FPS turun di bawah refresh rate, FPS bisa bolak-balik antara 60 dan 30 sehingga gambar patah-patah. - **Variable refresh rate** (VRR, G-Sync, FreeSync): Fitur monitor yang mengganti gambar tepat saat frame siap. Mengurangi patah-patah dan input lag yang muncul saat V-Sync bolak-balik antara 60 dan 30. - **Anti-cheat** (Anti-cheat): Modul keamanan yang mencegah cheat. Pemeriksaan berkala atau heartbeat ke server yang gagal bisa menyebabkan patah-patah atau disconnect. - **Overlay** (Overlay): Fitur program chat, perekam layar, atau penampil FPS yang menggambar tambahan di atas layar game. Karena menyela proses render game, overlay bisa menyebabkan patah-patah. - **Kompilasi shader** (Shader compilation): Proses mengubah program efek grafis ke bentuk yang bisa dijalankan GPU. Jika tidak dilakukan lebih dulu, layar tersendat sesaat saat efek pertama kali muncul. Setelah driver grafis diperbarui, hasil yang tersimpan tidak berlaku lagi sehingga kompilasi diulang. - **Main thread** (Main thread, Game thread): Thread utama game yang secara berurutan menghitung aturan game dan menyiapkan gambar. Jika ada satu saja pekerjaan yang lama di sini, layar berhenti selama itu. - **Resolusi timer** (Timer resolution): Selang terpendek yang bisa dipakai sistem operasi untuk membangunkan program yang sedang tidur (sleep). Nilai default Windows 15,6 ms, jadi jika program tidak mengubahnya sendiri, permintaan “bangunkan setelah 1 ms” pun terlambat dipenuhi. - **Thermal throttling** (Thermal throttling): Fitur perlindungan yang menurunkan kecepatan CPU dan GPU secara otomatis saat perangkat panas. Di ponsel, ini sering terjadi setelah bermain beberapa menit hingga puluhan menit. - **VRAM** (Video memory): Memori khusus pada kartu grafis. Tekstur dan model dimuat di sini untuk digambar. Jika tidak cukup, data harus dipertukarkan dengan memori PC lewat jalur yang lambat sehingga gambar patah-patah. - **Net graph** (Net graph): Tampilan pengembangan dan debug yang menampilkan ping, packet loss, FPS, dan tick sebagai grafik real-time di layar game. Jika ikut terekam di video laporan lag, penyebabnya jauh lebih mudah dicari. - **Tingkat retransmisi** (Retransmission rate): Persentase paket TCP yang dikirim ulang dari semua paket yang dikirim. Tidak ada standar resmi, tetapi rata-rata seluruh server di bawah 0,1% tergolong sehat, dan di atas 1% banyak pemain mudah merasakan lag. Periksa juga berapa kali lipat kenaikannya dibanding nilai biasanya. - **SACK** (Selective ACK): Fitur TCP yang memungkinkan penerima memberi tahu secara rinci “bagian ini sudah diterima, hanya bagian ini yang hilang”. Meski beberapa paket hilang, semuanya bisa dipulihkan sekaligus. - **RACK-TLP** (Recent ACK, Tail Loss Probe): Fitur TCP yang menentukan packet loss berdasarkan waktu, dan jika ACK tidak datang selama beberapa saat, mengirim paket terakhir sekali lagi untuk mempercepat pemulihan. Fitur ini default di Linux dan Android terbaru. Di Windows, TLP dan RACK default sejak Windows 10 (1607) dan Windows Server 2016, sedangkan RACK versi baru yang juga memulihkan retransmisi yang hilang tersedia sejak Windows Server 2022. Hanya bekerja pada koneksi yang mengaktifkan SACK. - **Retransmisi yang tidak perlu** (Spurious retransmission): Paket yang terlambat atau urutannya tertukar, lalu dianggap hilang dan dikirim ulang, padahal sebenarnya tidak hilang. Bandwidth terbuang dan laju kirim turun tanpa alasan. - **Zero window** (Zero window): Kondisi saat buffer penerima penuh dan penerima memberi tahu “jangan kirim dulu”. Gejalanya mirip retransmisi, padahal koneksinya baik-baik saja; program di sisi penerima tidak membaca data tepat waktu. - **thin stream** (Thin stream): Koneksi yang mengirim paket kecil secara jarang, seperti pada game. Sinyal untuk fast retransmit sulit terkumpul, sehingga saat terjadi packet loss, aliran data berhenti lama. - **Policer** (Policer): Metode pembatasan kecepatan yang langsung membuang paket yang melebihi batas kecepatan tanpa memasukkannya ke antrean. Metode yang memasukkan paket ke antrean lalu mengirimnya perlahan disebut shaper. - **Pacing** (Pacing): Pengiriman paket yang dibagi merata dari waktu ke waktu, tanpa ditumpahkan sekaligus. Mencegah buffer kecil meluap. - **ECN** (Explicit Congestion Notification): Fitur yang, saat terjadi kongesti, menandai paket dengan tanda “padat” tanpa membuangnya, sehingga pengirim menurunkan lajunya. Kongesti diberitahukan tanpa packet loss. Fitur ini baru efektif jika kedua ujung dan perangkat di jalur yang padat sama-sama mendukungnya. - **MSS** (Maximum Segment Size): Ukuran maksimum data yang dimuat TCP dalam satu paket. Biasanya 1.460 byte; jika dikecilkan sesuai jalur tunnel, MTU black hole bisa dicegah. - **Handover** (Handover): Pergantian BTS yang terhubung dengan ponsel saat ponsel bergerak. - **Persentil** (Percentile (p50, p95, p99)): Nilai yang berada di urutan persen tertentu jika semua nilai diurutkan dari yang terkecil. p50 adalah median, p99 adalah nilai di sekitar 1 kejadian paling lambat dari 100. Persentil memperlihatkan lonjakan yang tersembunyi di balik rata-rata. - **Tail latency** (Tail latency): Latensi panjang yang sesekali muncul meski sebagian besar permintaan cepat. Hampir tidak terlihat di rata-rata, tetapi inilah yang diingat pemain sebagai lag. - **Synthetic monitoring** (Synthetic monitoring): Pengukuran kualitas rute oleh perangkat atau server khusus yang secara berkala mengirim ping, traceroute, dan sebagainya dari lokasi yang sudah ditentukan, sebagai pengganti pemain sungguhan. RIPE Atlas adalah tool publik yang paling dikenal. - **Interval agregasi** (Aggregation interval): Rentang waktu (berapa detik atau menit) yang digabung menjadi satu titik di grafik. Makin panjang intervalnya, lonjakan singkat makin tersamar karena tercampur ke rata-rata. - **Postmortem** (Postmortem): Dokumen yang disusun setelah insiden selesai, berisi apa yang terjadi, mengapa terjadi, dan apa yang akan diubah. Ditulis tanpa menyalahkan siapa pun, dengan tujuan mencegah insiden terulang. - **C-state** (CPU idle state): Mode hemat daya yang dimasuki CPU saat idle. Makin dalam levelnya, makin hemat listrik, tetapi makin lama waktu untuk bangun kembali. - **Live migration** (Live migration): Pemindahan virtual machine yang sedang berjalan ke host lain oleh penyedia cloud, misalnya untuk maintenance host. Saat dipindahkan, VM bisa berhenti sejenak. - **SNAT** (Source NAT): NAT yang mengganti alamat asal paket keluar menjadi alamat publik. Jumlah port yang bisa dipakai satu alamat publik terbatas; jika habis, koneksi baru gagal. - **NAT gateway** (NAT gateway): Komponen cloud yang membuat server-server di jaringan privat bisa memakai satu alamat publik bersama saat keluar ke internet. Jumlah koneksi simultan per tujuan dibatasi. - **Internet satelit orbit rendah** (LEO satellite internet): Internet yang terhubung lewat satelit di ketinggian ratusan hingga ribuan km. Latensinya jauh lebih rendah daripada satelit geostasioner, tetapi bisa melonjak saat satelit yang terhubung berganti. - **GeoIP** (IP geolocation): Database untuk memperkirakan negara, kota, dan ISP dari alamat IP. Ada entri yang salah atau usang, sehingga kadang pemain diarahkan ke server di wilayah yang jauh. - **Sertifikat TLS** (TLS certificate): Dokumen elektronik yang membuktikan bahwa server itu memang server yang asli. Masa berlakunya terbatas; jika kedaluwarsa, koneksi terenkripsi gagal dan pemain tidak bisa masuk. - **Frame generation** (Frame generation): Teknologi kartu grafis yang menyisipkan frame hasil prediksi di antara frame yang benar-benar digambar untuk menaikkan FPS. Gambar menjadi lebih halus, tetapi latensi dari input sampai tampil di layar bisa bertambah.