Kalkulator Latensi & Jitter
Angka ping berapa yang masih wajar untuk VoIP dan game
Nilai hasil ping terhadap ambang yang berlaku untuk tiap layanan: web, VoIP, konferensi video, dan game. Menghitung dampak packet loss terhadap kecepatan TCP, dan memisahkan jitter dari latensi.
Seluruh perhitungan berjalan di browser Anda. Alamat IP, nama interface, dan password yang Anda masukkan tidak pernah dikirim ke server CoreNet.
Satu angka ping, empat kesimpulan berbeda
Latensi 120 ms adalah angka yang baik-baik saja untuk membuka situs, masih dapat diterima untuk panggilan suara, dan tidak layak untuk game kompetitif. Menilainya dengan satu ambang tunggal — "di bawah 100 bagus" — membuang informasi yang justru dibutuhkan.
Tool ini menilai angka Anda terhadap ambang yang berlaku untuk masing-masing keperluan.
Jitter sering lebih penting daripada latensi
Untuk panggilan suara, sambungan dengan latensi 150 ms yang stabil terdengar jauh lebih baik daripada sambungan 60 ms yang naik-turun antara 20 dan 200. Alasannya: penerima menyimpan sedikit suara di penyangga sebelum memutarnya. Latensi tetap hanya menggeser seluruh percakapan sedikit; latensi yang berubah-ubah membuat penyangga kehabisan isi, dan itulah yang terdengar sebagai suara terputus-putus.
Karena itu, keluhan "teleponnya patah-patah" hampir tidak pernah selesai dengan menambah bandwidth. Yang perlu dicari adalah penyebab jitter — biasanya queue yang penuh karena ada unduhan besar berjalan bersamaan.
Packet loss menghukum lebih berat daripada dugaan
Packet loss 1% terdengar sepele. Bagi TCP, tidak. TCP menafsirkan paket hilang sebagai tanda jalur penuh, lalu memperlambat diri secara drastis dan naik kembali perlahan. Pendekatan Mathis memperkirakan batas atasnya:
throughput ≈ MSS / (RTT × √kehilangan)Pada latensi 100 ms, kehilangan 1% membatasi satu sambungan di sekitar 1,2 Mbps — sekalipun jalurnya 100 Mbps. Kehilangan 0,1% menaikkannya sekitar tiga kali lipat. Angka kecil, dampaknya besar.
Ambang yang dipakai
Setiap ukuran dinilai dua tingkat: baik dan masih dapat diterima. Di atas angka kedua, layanan itu akan terasa terganggu.
| Keperluan | Latensi | Jitter | Kehilangan |
|---|---|---|---|
| Browsing & aplikasi kantor | baik ≤ 100 ms, batas 300 ms | ≤ 50 ms, batas 100 ms | ≤ 1%, batas 3% |
| Panggilan suara | baik ≤ 80 ms, batas 150 ms | ≤ 20 ms, batas 30 ms | ≤ 0,5%, batas 1% |
| Rapat video | baik ≤ 100 ms, batas 200 ms | ≤ 30 ms, batas 50 ms | ≤ 0,5%, batas 2% |
| Game online | baik ≤ 50 ms, batas 100 ms | ≤ 10 ms, batas 20 ms | ≤ 0,1%, batas 0,5% |
Angka untuk suara mengikuti anjuran umum ITU-T; sisanya berdasar pengalaman lapangan.
Cara memakai
Jalankan ping ke tujuan yang benar-benar Anda pakai — bukan ke 8.8.8.8, kecuali yang ingin dinilai memang jalur ke Google:
ping -n 50 tujuan.exampleLalu salin angka minimum, rata-rata, maksimum, dan persentase kehilangan ke formulir.
Pertanyaan yang sering diajukan
Ping ke 8.8.8.8 bagus tetapi aplikasi tetap lambat. Kenapa? Karena yang diukur bukan jalur yang dipakai aplikasi. Ping ke server aplikasinya sendiri, dan gunakan traceroute untuk melihat di lompatan mana angkanya melonjak.
Latensi tinggi hanya saat jam sibuk? Itu queue, bukan jarak. Jalur yang penuh membuat paket menunggu. Simple Queue atau Queue Tree dengan PCQ menolong dengan mendahulukan traffic kecil yang peka waktu.
Bisakah latensi diperbaiki dengan menambah bandwidth? Hanya bila penyebabnya memang jalur penuh. Bila penyebabnya jarak, tidak ada bandwidth yang menolong — cahaya sudah berjalan secepat yang ia bisa.