WIKI TKJ

Mikrotik : Bandwidth Test dan Pengukuran Throughput

Revision as of 07:01, 20 October 2026 by Maintenance script (talk | contribs) (Protected "Mikrotik : Bandwidth Test dan Pengukuran Throughput": Proteksi editorial: edit/move sysop ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

🎯 Tujuan

Setelah membaca dan mempraktikkan artikel ini, kamu bisa:

  • membedakan bandwidth, throughput, latency, dan packet loss;
  • memakai `/tool bandwidth-test` dan `/tool speed-test` dengan aman;
  • membaca hasil `tx`, `rx`, average, `lost-packets`, dan `cpu-load`;
  • mengukur kapasitas forwarding router dengan tiga router berantai;
  • menjelaskan kenapa hasil tes sering lebih rendah dari angka di brosur.

Mengukur jaringan itu keterampilan yang membedakan "merasa lambat" dari "terbukti lambat di titik mana". Tanpa angka, perbaikan hanya tebak-tebakan.

📍 Konteks nyata

Bayangkan pintu kelas. Lebar pintu 120 cm itu **bandwidth** — kapasitas maksimal. Jumlah siswa yang benar-benar lewat dalam satu menit itu **throughput** — hasil nyata. Kalau ada yang berhenti di tengah pintu, lebar pintu tidak berubah, tapi yang lewat jadi sedikit.

  • Analogi: bandwidth itu lebar jalan tol, throughput itu jumlah mobil yang sampai di gerbang keluar. Macet, jalan berlubang, dan satu lajur ditutup tidak mengubah lebar jalan, tapi mengubah hasil.

🔥 Kasus nyata: Sebuah SMK punya uplink 100 Mbps. Guru melaporkan upload nilai rapor "lambat sekali", sementara teknisi mengetes dari router dan mendapat 92 Mbps — lalu menyimpulkan internet normal.

Yang terukur waktu itu adalah 20 koneksi paralel sekaligus. Aplikasi rapor memakai satu koneksi, dan koneksi tunggal itu hanya dapat 9–12 Mbps karena latency 45 ms ditambah packet loss 1 persen. Setelah diuji dengan `connection-count=1` dan uji loss memakai UDP, ketahuan ada interferensi di link wireless antar gedung.

🧠 Konsep singkat

Mengukur throughput artinya mengirim trafik uji secara sengaja, lalu mencatat berapa yang benar-benar sampai. Yang diukur bukan "internet", tapi satu jalur tertentu pada satu waktu tertentu.

🔹 Empat angka yang wajib dibedakan

| Istilah | Arti | Analogi | Terlihat di | |---|---|---|---| | Bandwidth | kapasitas maksimal link | lebar pintu | spesifikasi port, `1Gbps` | | Throughput | data yang benar-benar lewat | siswa yang lewat per menit | hasil tes | | Latency | waktu pulang-pergi paket | waktu antar-jemput | `ping-min-avg-max` | | Loss | paket yang tidak sampai | siswa yang tersesat | `lost-packets`, `loss` |

Jitter adalah variasi latency — kalau latency naik-turun, video call jadi patah-patah meski bandwidth masih longgar.

📊 Angka penting: link 1 Gbps tidak akan pernah menghasilkan 1 Gbps di tes TCP. TCP hanya menghitung payload, sedangkan UDP menghitung seluruh paket IP termasuk header. Selisihnya beberapa persen, dan ACK yang mengalir balik tidak dihitung sama sekali.

🔹 Tiga alat ukur di RouterOS

| Alat | Kelebihan | Kapan dipakai | |---|---|---| | `/tool/bandwidth-test` | pilih protokol, arah, limit, ukuran paket | diagnosis rinci satu jalur | | `/tool/speed-test` | 5 fase otomatis dalam satu perintah | cek cepat kualitas link antar situs | | `iperf3` di PC/Linux | lintas platform, dari perangkat siswa | uji dari sisi client, bukan router |

`/tool/speed-test` sebenarnya membungkus ping dan bandwidth test. Ia menjalankan lima fase berurutan: ping, TCP download, TCP upload, UDP download, UDP upload.

  • Default `test-duration` 10 detik per fase, dengan jeda sekitar satu detik antar fase. Total satu putaran kurang lebih 55 detik.
  • Nilai minimum `test-duration` adalah 5 detik.
  • Fase ping mengirim 20 paket per detik, jadi 200 ping pada durasi default.

⚠️ Hati-hati: fase ping dijalankan **sebelum** trafik besar, saat link masih sepi. Jadi angka latency di situ bukan latency saat jaringan sedang sibuk.

🔹 Kenapa hasil tes sering menipu

  • **CPU penuh.** Membuat dan menerima trafik uji jauh lebih berat daripada meneruskan trafik. Kalau `local-cpu-load` mendekati 100 persen, yang membatasi adalah router, bukan kabel.
  • **Satu core sibuk.** Beban total 30 persen tidak menjamin aman. Satu core bisa 100 persen sementara core lain menganggur, jadi cek `/system/resource/cpu/print`.
  • **Jumlah koneksi.** Default 20 koneksi (atau jumlah core kalau lebih dari 20). Dua puluh koneksi bisa mengumpulkan 900 Mbps, sementara satu koneksi hanya 40 Mbps.
  • **Protokol.** UDP menunjukkan kapasitas jalur dan loss, TCP menunjukkan yang didapat aplikasi setelah koreksi loss.
  • **Ukuran paket.** Paket 1500 byte mengukur bit rate, paket 64 byte mengukur berapa paket per detik yang sanggup dilewatkan router.
  • **Queue atau limit aktif.** Kalau Simple Queue 50 Mbps terpasang di jalur, hasil tes akan mentok di 50 Mbps — itu bukan kerusakan.
  • **Data yang bisa dikompresi.** Di link berkompresi, hasil bisa terlihat lebih tinggi dari kenyataan. Pakai `random-data=yes`.

💡 Tips: curigai hasil yang "terlalu bagus". Tes yang mengukur CPU router, bukan jalur, sering muncul sebagai angka tinggi dengan `cpu-load` rendah di satu sisi dan tinggi di sisi lain.

🔹 Mengukur router, bukan kabel

Kalau tujuanmu mengetahui berapa kapasitas **forwarding** sebuah router, jangan menjalankan tes dari router itu. Pasang tiga router berantai: server di ujung, client di ujung, dan router yang diuji di tengah.

Trafik harus melewati router tengah, bukan berhenti di situ. Subnet kedua ujung diarahkan lewat router tengah, lalu bandingkan `local-cpu-load` dan `remote-cpu-load`. Kalau ujungnya menyentuh 100 persen, ujung itulah yang membatasi.

🧩 Istilah penting

| Istilah | Arti singkat | |---|---| | Bandwidth test server | layanan di router yang melayani permintaan tes, default aktif | | `authenticate` | wajib login atau tidak, default `yes` | | `allocate-udp-ports-from` | port UDP awal untuk tes, default `2000` | | `max-sessions` | jumlah tes serentak, default `100` | | `direction` | arah tes: `transmit`, `receive`, atau `both` | | `local-tx-speed` | batas kirim dari sisi client | | `remote-tx-speed` | batas kirim dari sisi server | | `connection-count` | jumlah koneksi/stream paralel | | `lost-packets` | paket hilang pada detik terakhir, bukan total | | `device-mode` | mode keamanan perangkat; sebagian mematikan bandwidth test |

🔧 Praktik: mengukur throughput jalur lab

Siapkan dua router yang terhubung langsung lewat kabel, atau dua CHR di Proxmox. Contoh di bawah memakai alamat privat lab: 

Router A (client)  ether2 = 10.20.20.1/24
Router B (server)  ether2 = 10.20.20.2/24

🔹 Persiapan di router B (server)

Cek dulu apakah layanan tes hidup dan tidak dimatikan device mode. 

/tool/bandwidth-server/print
/system/device-mode/print

Nilai normal: `enabled: yes`, `authenticate: yes`, `allocate-udp-ports-from: 2000`, `max-sessions: 100`, dan `bandwidth-test: yes`.

Buat user khusus tes dengan dua policy saja. Server memeriksa `test` **dan** `winbox` sekaligus. 

/user/group/add name=btest policy=test,winbox
/user/add name=btest group=btest password=UjiLab2026!

🔹 Langkah 1: tes dasar UDP

Tanpa parameter protokol, tes berjalan UDP dengan server yang mengirim (`direction=receive`) dan paket 1500 byte. 

/tool/bandwidth-test address=10.20.20.2 user=btest \
  password=UjiLab2026! duration=10s

Perhatikan tiga hal: `rx-total-average`, `lost-packets`, dan `local-cpu-load`. Kalau loss besar sementara rx mentok, itu tanda jalur sudah di kapasitasnya.

🔹 Langkah 2: tes TCP dua arah dengan limit

Tes tanpa limit akan memakai seluruh bandwidth dan sebagian besar CPU. Di link yang sedang dipakai, batasi kecepatan. 

/tool/bandwidth-test address=10.20.20.2 user=btest \
  password=UjiLab2026! protocol=tcp direction=both \
  local-tx-speed=50M remote-tx-speed=50M duration=10s

Kalau hasil keduanya mendekati 50 Mbps dan CPU rendah, jalur sehat untuk beban itu. `local-tx-speed` membatasi kiriman client, `remote-tx-speed` membatasi kiriman server.

💡 Tips: tanpa `duration`, tes berjalan terus sampai kamu tekan Ctrl+C. Selalu pasang durasi supaya tidak lupa meninggalkan trafik uji.

🔹 Langkah 3: uji loss di bawah kapasitas

Mengetes loss paling adil dilakukan **di bawah** kapasitas link. Kirim UDP pada angka yang seharusnya aman, lalu lihat `lost-packets`. 

/tool/bandwidth-test address=10.20.20.2 user=btest \
  password=UjiLab2026! direction=receive remote-tx-speed=200M duration=10s

📊 Angka penting: pada 491 Mbps dengan paket 1500 byte, ada sekitar 41.000 paket per detik. Tiga paket hilang dalam satu detik berarti loss di bawah 0,01 persen — masih wajar. Loss yang konsisten di angka persen pada laju rendah adalah gejala masalah, bukan kebetulan.

🔹 Langkah 4: bandingkan 1 koneksi vs 20 koneksi

Ini uji yang paling sering menjelaskan keluhan "lambat padahal speed test besar". 

/tool/bandwidth-test address=10.20.20.2 user=btest \
  password=UjiLab2026! protocol=tcp direction=receive \
  connection-count=1 duration=10s

Ulangi dengan `connection-count=20`, lalu bandingkan `rx-total-average`. Selisih besar antara keduanya berarti aplikasi yang memakai satu koneksi akan terasa jauh lebih lambat daripada hasil tes agregat.

🔹 Langkah 5: versi cepat dengan speed-test

Kalau hanya butuh gambaran menyeluruh, satu perintah ini sudah cukup. 

/tool/speed-test address=10.20.20.2 user=btest \
  password=UjiLab2026! test-duration=5s

Hasilnya berisi `ping-min-avg-max`, `jitter-min-avg-max`, `loss`, lalu empat baris throughput: `tcp-download`, `tcp-upload`, `udp-download`, `udp-upload`. Download dan upload dilihat dari router yang menjalankan tes.

🔹 Langkah 6: bersih-bersih

Tes selesai, hapus user dan grup uji supaya tidak jadi pintu yang terlupakan. 

/user/remove btest
/user/group/remove btest

🔹 Versi Winbox

  1. Buka **Tools → Bandwidth Test**.
  2. Isi **Server address**, **User**, dan **Password**.
  3. Pilih **Protocol** (tcp/udp), **Direction**, dan **Duration**.
  4. Isi **Local Tx Speed** dan **Remote Tx Speed** kalau ingin membatasi.
  5. Klik **Start**, lalu baca kolom Tx/Rx Current dan Average.

Untuk **Tools → Speed Test**, cukup isi alamat, user, password, dan durasi. Semua fase berjalan otomatis.

🔹 Membaca hasil tanpa bingung

| Kolom | Artinya | |---|---| | `tx-current` | yang dikirim client pada detik terakhir | | `rx-current` | yang diterima client pada detik terakhir | | `tx-10-second-average` | rata-rata 10 detik terakhir | | `tx-total-average` | rata-rata seluruh tes | | `lost-packets` | paket hilang pada detik terakhir (UDP) | | `local-cpu-load` | beban CPU router yang menjalankan tes | | `remote-cpu-load` | beban CPU router lawan |

🧪 Uji cepat: kalau `lost-packets` selalu di atas nol tanpa limit, turunkan `remote-tx-speed` sedikit demi sedikit. Titik saat loss mulai nol adalah kapasitas nyata jalur itu.

🏭 Dipakai di dunia kerja

  • **Sekolah:** membuktikan apakah kelambatan CBT berasal dari uplink ISP atau dari switch/AP lab, sebelum mengajukan upgrade yang mahal.
  • **Kantor cabang:** mengukur kualitas VPN antar kantor; hasil rendah dengan CPU tinggi berarti router cabang yang jadi batas, bukan internetnya.
  • **ISP dan warnet:** memvalidasi paket layanan pelanggan dan membuktikan ada tidaknya loss di jalur akses.
  • **Industri:** memeriksa link wireless antar gedung pabrik, tempat interferensi lebih sering daripada kabel putus.
  • **Tim proyek dan data center:** uji terima jalur baru sebelum serah terima; angka throughput dan loss masuk berita acara.
  • **NOC:** membandingkan hasil tes berkala untuk mendeteksi penurunan perlahan sebelum pengguna mengeluh.

✅ Verifikasi

  • `status: done testing` muncul di akhir tes, bukan `disconnected`.
  • `local-cpu-load` dan `remote-cpu-load` jauh di bawah 100 persen saat mengukur jalur.
  • Hasil tes berulang tidak berbeda jauh; selisih ekstrem biasanya berarti link sedang dipakai.
  • `direction=both` pada link wireless tidak otomatis dua kali angka satu arah — air time dibagi.
  • User uji dan rule firewall sementara sudah dihapus setelah selesai.
/tool/bandwidth-server/session/print
/tool/bandwidth-server/print
/user/print where name=btest

⚠️ Kesalahan umum & troubleshooting

| Gejala | Penyebab | Perbaikan | |---|---|---| | `authentication failed` | user/password salah, atau grup tanpa policy `test`/`winbox` | cek `/user/group/print` di server | | `can not connect` | server mati, port TCP 2000 tertutup, alamat client tidak diizinkan, atau `max-sessions` penuh | cek server dan `allowed-addresses4` | | `disconnected` | koneksi putus saat tes, atau koneksi tes melebihi `max-sessions` | turunkan `connection-count` | | `not allowed by device-mode` | device mode mematikan bandwidth test | aktifkan lewat akses fisik ke router | | UDP receive 0 bps | paket UDP server tidak sampai ke client karena NAT/firewall | pakai TCP, atau izinkan UDP di client | | Hanya hasil ping tanpa throughput | bandwidth server mati atau port 2000 diblok | cek server dan firewall | | Hasil rendah, CPU mendekati 100% | router jadi sumber/penerima trafik | tes menembus router, bukan dari router | | Hasil mentok di angka bulat | queue atau limit aktif | cek `/queue simple print` dan `/queue tree print` | | Paket besar selalu loss | fragmentasi karena MTU jalur lebih kecil | pakai `local-udp-tx-size` lebih kecil | | TCP terlihat lebih rendah dari UDP | TCP menghitung payload dan melambat saat loss | bandingkan UDP untuk kapasitas, TCP untuk pengalaman aplikasi |

Penjelasan singkat untuk dua gejala yang paling sering salah dibaca:

  • `can not connect` bukan berarti kabel putus. Di lab, penyebab tersering adalah user uji belum dibuat di router server.
  • UDP receive 0 bps hampir selalu soal arah paket. Client di belakang NAT bisa mengirim UDP, tapi tidak bisa menerima UDP yang datang tanpa izin.

🔐 Catatan keamanan & etika

  • Jangan pernah memasang `authenticate=no` di router yang bisa dijangkau internet. Siapa pun bisa membebani router dan linkmu.
  • Batasi penguji dengan `allowed-addresses4` dan `allowed-addresses6`. Setelan alamat pada user **tidak** membatasi login bandwidth test.
  • `max-sessions` default 100. Kecilkan di router produksi supaya tidak bisa dijadikan alat serangan.
  • Hapus user uji dan rule firewall sementara segera setelah tes. User `btest` yang tertinggal adalah akun dengan akses `winbox`.
  • Bandwidth test ke jaringan milik orang lain tanpa izin bukan latihan — itu tindakan yang bisa melanggar hukum dan etika. Batasi praktik di lab sendiri.
  • Tes tanpa limit di jam kerja mengganggu pengguna lain. Pilih waktu sepi atau pasang batas kecepatan.

📌 Kesimpulan

Bandwidth test bukan alat pembanding angka brosur, melainkan alat menjawab "di titik mana jalur ini melambat". Bandingkan selalu tiga hal: throughput, loss, dan beban CPU.

Kalau CPU tinggi, yang diukur adalah router. Kalau loss tinggi di laju rendah, yang diukur adalah masalah fisik atau interferensi. Kalau satu koneksi jauh lebih rendah dari dua puluh koneksi, yang diukur adalah pengalaman aplikasi nyata.

Langkah berikutnya: pakai angka ini untuk memutuskan apakah masalahnya di link, di router, atau di aplikasi — lalu buktikan dengan praktikum pengukuran dan pencatatan hasil.

🔗 Materi terkait

📚 Referensi

Retrieved from "https://noctkj.net/index.php?title=Mikrotik_:_Bandwidth_Test_dan_Pengukuran_Throughput&oldid=1446"