Bandwidth test menjawab satu pertanyaan: berapa angka yang keluar dari alat ukur ini. Bukan otomatis menjawab "berapa kapasitas link saya". Praktikum ini membongkar delapan kondisi yang membuat angka tes terlihat bagus (atau buruk) padahal penyebabnya bukan kabel.
🎯 Tujuan
Setelah menyelesaikan praktikum ini, kamu bisa:
- Membedakan **kapasitas link**, **hasil tes**, dan **pengalaman satu pengguna** — tiga hal yang sering dianggap sama.
- Menyiapkan lab dua router dengan angka pembanding yang sudah diketahui, sehingga hasil tes bisa dinilai benar atau salah.
- Menjalankan **delapan uji rusak terkontrol** dan menjelaskan lapis mana yang membatasi hasil.
- Mengukur latency **saat link penuh**, bukan hanya saat sepi.
- Menyusun laporan tes yang bisa dipertanggungjawabkan ke guru, klien, atau atasan.
📍 Konteks nyata
Sebuah yayasan sekolah punya uplink 300 Mbps. Operator melaporkan: "Tes sudah 292 Mbps, ping 4 ms, link sehat." Tapi tiap jam 09.30, rapat guru lewat Zoom tersendat dan suara terputus-putus. Tes diulang berkali-kali, hasilnya tetap bagus.
Analogi yang enak dipakai: tes bandwidth itu seperti mengukur pintu kelas dengan **20 orang berjalan berbarengan**. Hasilnya "pintu selebar 3 meter" — benar untuk rombongan, tapi belum menjawab apakah **satu orang** yang membawa lemari bisa lewat.
Angka tes selalu jujur pada apa yang diperintahkan, bukan pada yang kita bayangkan. Kalau yang diperintah "20 koneksi TCP, paket 1500 byte, link sepi", ya itulah yang dijawab.
🔥 Kasus nyata: Setelah diukur dengan `connection-count=1`, satu aliran hanya dapat **118 Mbps** dari 300 Mbps. Saat ping dijalankan **bersamaan** dengan tes, latency naik dari 4 ms ke **380–450 ms**. Penyebabnya bukan kabel, tapi tidak ada queue: 20 siswa menonton video memenuhi buffer modem. Setelah dipasang queue per kelas dan limit agregat, ping saat link penuh turun ke 40–60 ms.
🧠 Konsep singkat
Hasil tes adalah interaksi **empat lapis**. Angka akhir yang muncul adalah lapis **tersempit**, bukan kapasitas kabel:
| Lapis | Yang menentukan | Contoh gejala | |---|---|---| | Sumber | CPU, jumlah koneksi, ukuran paket | satu core 100%, hasil mentok | | Jalur | kapasitas, latency, loss, MTU, queue | hasil naik-turun, loss muncul | | Penerima | CPU, firewall, NAT | hasil 0 bps atau putus | | Cara ukur | protokol, `connection-count`, limit | angka bulat, arah tidak seimbang |
Kalau satu lapis sempit, tes tetap "berhasil" dan tetap mengeluarkan angka. Karena itu praktik hari ini bukan mengejar angka tertinggi, tapi **memastikan alat ukur tidak berbohong**.
📊 Angka penting: UDP menghitung **seluruh paket IP** termasuk header, sedangkan TCP hanya menghitung **data**. Paket 1500 byte berarti 1472 byte data UDP. Counter interface menambahkan header Ethernet, jadi angkanya sedikit lebih tinggi dari hasil tes.
🧩 Istilah penting
| Istilah | Arti awam | Kenapa penting di lab | |---|---|---| | Throughput | jumlah data yang benar-benar lewat per detik | ini yang diukur alat | | Goodput | data berguna setelah retransmisi | lebih rendah dari throughput | | pps | paket per detik | penentu utama di paket kecil | | `local-tx-speed` | batas kirim dari sisi client | mengunci variabel uji | | `remote-tx-speed` | batas kirim dari sisi server | pasangannya | | `connection-count` | jumlah aliran paralel | 1 aliran mirip 1 pengguna | | `max-sessions` | batas tes bersamaan di server | 100 default, tidak bisa dilampaui | | `lost-packets` | paket hilang **detik terakhir** | bukan total seluruh tes | | Bufferbloat | antrean menumpuk, latency meledak | tidak terlihat saat link sepi |
💡 Tips: Sebelum menyimpulkan "link lambat", tulis dulu pertanyaan yang mau dijawab. "Berapa kapasitas?" beda alat dengan "kenapa satu guru Zoom-nya putus?"
🔧 Praktik: delapan uji yang membongkar angka palsu
Lab ini memakai dua router dan satu laptop pengamat. Tidak perlu internet — justru lebih baik tanpa internet supaya tidak ada variabel luar.
🔹 Persiapan lab
| Perangkat | Interface | Alamat | |---|---|---| | R1 (client uji) | ether1 ke R2 | 192.0.2.10/24 | | R1 | ether2 LAN lab | 10.10.10.1/24 | | R2 (server uji) | ether1 ke R1 | 192.0.2.20/24 | | R2 | ether2 LAN pengamat | 10.20.20.1/24 | | Laptop pengamat | ethernet | 10.20.20.10/24, gateway 10.20.20.1 |
Alamat di atas memakai rentang dokumentasi RFC 5737, jadi aman dipakai di lab mana pun.
Konfigurasi dasar di R2:
/ip address add address=192.0.2.20/24 interface=ether1
/ip address add address=10.20.20.1/24 interface=ether2
/tool bandwidth-server print
/system device-mode print
Pastikan tiga hal ini benar sebelum lanjut:
- **`enabled: yes`** dan **`authenticate: yes`** pada bandwidth server (default memang begitu).
- **`bandwidth-test: yes`** pada `device-mode`. Router baru dengan RouterOS 7.17+ sering datang dalam mode `home` yang mematikan fitur ini, dan menyalakannya butuh akses fisik.
- User uji dengan policy **`test` dan `winbox`** — server memeriksa keduanya.
/user group add name=btest policy=test,winbox
/user add name=btest group=btest password=GantiPasswordIni
⚠️ Hati-hati: Kalau `device-mode` mematikan bandwidth test, semua uji akan gagal dengan pesan `not allowed by device-mode`. Cek dulu sebelum menyalahkan kabel.
🔹 Langkah 0: baseline "kebenaran"
Di sini kita **sengaja memasang batas 50 Mbps** di kedua arah. Jadi jawaban yang benar sudah diketahui: sekitar 50 Mbps. Kalau alat ukur melaporkan 50 Mbps, alatnya sehat.
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=tcp direction=both local-tx-speed=50M remote-tx-speed=50M \
duration=10s random-data=yes connection-count=20
Yang harus terlihat: `tx-total-average` dan `rx-total-average` di kisaran **49–50 Mbps**, dengan `local-cpu-load` dan `remote-cpu-load` jauh di bawah 50%.
Catat enam angka baseline di lembar kerja: tx average, rx average, local CPU, remote CPU, `lost-packets`, dan durasi. Semua uji berikutnya dibandingkan ke angka ini.
💡 Tips: Jalankan baseline **tiga kali** dan pakai nilai tengah. Selisih antar run lebih dari 5% berarti ada variabel yang belum terkendali — biasanya link tidak sepi atau CPU sibuk.
🔹 Uji A — paket kecil: Mbps atau pps?
Sekarang lepas batas, lalu ukur dua kali dengan ukuran paket berbeda. Protokol UDP, arah transmit, tanpa limit:
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=udp direction=transmit local-udp-tx-size=1500 duration=10s
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=udp direction=transmit local-udp-tx-size=64 duration=10s
Hasil yang biasanya muncul: paket 1500 byte bisa mendekati kapasitas link, paket 64 byte **jauh lebih rendah**. Keduanya benar. Bedanya, yang pertama mengukur **bit rate**, yang kedua mengukur **packet rate**.
📊 Angka penting: Untuk 1 Gbps, paket 1500 byte hanya perlu ±81.000 paket/detik. Dengan paket 64 byte, angka yang sama menuntut ±1.488.000 paket/detik. Hampir semua router menyerah lebih dulu di jumlah paket, bukan di jumlah bit.
Ukuran paket yang bisa disetel adalah **52 sampai 64000 byte** untuk IPv4. Paket lebih besar dari MTU terkecil di jalur akan difragmentasi, dan hasilnya bukan lagi gambaran bersih.
🔹 Uji B — satu koneksi, satu core
Uji ini menjawab keluhan "kok satu download lambat, tapi tesnya cepat". Jalankan tiga kali, hanya `connection-count` yang berubah:
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=tcp direction=transmit connection-count=1 duration=10s
Ulangi dengan `connection-count=20`, lalu `connection-count=64`. Sambil tes berjalan, buka terminal kedua di R1:
/system resource cpu print
Perhatikan: bisa jadi **satu core 100%** sementara core lain menganggur. Inilah jebakan `local-cpu-load` — angka totalnya terlihat aman (misalnya 25%), padahal kapasitas satu core sudah habis.
Satu aliran TCP umumnya dilayani satu core. Beberapa koneksi menyebar ke beberapa core, jadi hasil agregat naik walau CPU total tetap sama.
⚠️ Hati-hati: Membandingkan hasil `connection-count=1` milik router A dengan `connection-count=20` milik router B adalah kesalahan paling umum saat menulis laporan. Selalu sebutkan jumlah koneksi di samping angka.
🔹 Uji C — arah: transmit, receive, both
Banyak laporan hanya menyebut "300 Mbps" tanpa arah. Padahal arah bisa sangat tidak seimbang:
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=udp direction=transmit local-udp-tx-size=1500 duration=10s
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=udp direction=receive remote-udp-tx-size=1500 duration=10s
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=udp direction=both duration=10s
Di kabel, transmit dan receive biasanya mirip, dan `both` mendekati jumlah keduanya. Di link wireless, `both` sering **lebih kecil** dari penjumlahan karena dua arah berbagi waktu udara yang sama.
Karena itu, untuk wireless, ukur tiap arah **sendiri-sendiri** dulu, baru ukur `both` untuk melihat total yang bisa dibawa link.
💡 Tips: Kalau mau mengukur "pengalaman upload rapor", pakai arah transmit dari sisi sekolah. Arah receive hanya bercerita tentang download.
🔹 Uji D — data yang bisa dikompres
Kalau hasil tes terasa **terlalu bagus** dibanding pemakaian nyata, ada dua kemungkinan: jalur mengompres data, atau parameternya kurang ketat. Bandingkan:
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=tcp direction=both local-tx-speed=50M remote-tx-speed=50M \
duration=10s random-data=no
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=tcp direction=both local-tx-speed=50M remote-tx-speed=50M \
duration=10s random-data=yes
Di link normal, dua hasil ini hampir sama. Kalau `random-data=yes` jauh lebih rendah, cek `local-cpu-load` lebih dulu: opsi ini memang memakan CPU di kedua router, jadi penurunan bisa berarti **CPU**, bukan kompresi.
⚠️ Hati-hati: Jangan simpulkan "ada kompresi" hanya karena selisih hasil. Bukti tambahan yang sah adalah CPU tetap rendah di kedua sisi sementara angka turun konsisten.
🔹 Uji E — UDP masuk tapi tidak keluar (0 bps)
Ini uji kegagalan yang paling sering ditemui di lapangan: klien di belakang NAT atau firewall. Kita tiru dengan satu rule di R1:
/ip firewall filter add chain=input action=drop protocol=udp \
src-address=192.0.2.20 comment="lab: blok UDP balik"
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
direction=receive duration=10s
Hasilnya: **rx 0 bps** atau tanpa baris data sama sekali. Tes tetap berjalan sampai selesai, karena bagian ping dan login tetap lewat.
Sekarang hapus rule dan ulangi — hasil normal kembali:
/ip firewall filter remove [find comment="lab: blok UDP balik"]
Pelajaran: uji **receive** butuh paket dari server masuk ke client. Uji **transmit** tetap jalan walau client di belakang NAT, karena client yang memulai koneksi.
🔹 Uji F — ping sehat saat link sepi
`speed-test` mengukur ping **sebelum** bagian throughput, jadi angka latency-nya adalah latency di link kosong. Untuk melihat kondisi saat sibuk, ukur sendiri:
- Di laptop pengamat, jalankan ping terus-menerus ke `192.0.2.10`.
- Di R1, jalankan tes tanpa limit selama 30 detik.
- Catat latency sebelum dan selama tes.
ping -i 0.2 192.0.2.10
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=tcp direction=both duration=30s
Kalau latency melonjak dari 2 ms ke ratusan ms, yang kamu temukan adalah **bufferbloat**: antrean menumpuk di buffer modem karena tidak ada yang mengatur urutan keluar.
🧪 Uji cepat: Bandingkan rata-rata ping saat sepi dan saat penuh. Lonjakan lebih dari 5 kali lipat sudah cukup untuk menyimpulkan antrean tidak terkendali — dan itu tidak akan pernah terlihat dari `speed-test` biasa.
🔹 Uji G — koneksi melebihi max-sessions
Server punya batas `max-sessions`, default **100**, dan satu tes tidak boleh memakai koneksi lebih banyak dari batas itu. Uji dengan sengaja melampaui:
/tool bandwidth-server print
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=tcp direction=transmit connection-count=150 duration=10s
Gejala yang muncul adalah `disconnected` di tengah tes — bukan pesan "koneksi terlalu banyak". Setelah `connection-count` diturunkan ke 80, tes berjalan normal.
📊 Angka penting: `max-sessions=100` membatasi **jumlah tes bersamaan** sekaligus **jumlah koneksi per tes**. Di `speed-test`, `connection-count` menerima 1–255 dan default-nya 20, atau jumlah core kalau core router lebih dari 20.
🔹 Uji H — alamat server vs alamat user
Banyak yang mengira membatasi `address` pada user uji akan mengunci siapa yang boleh tes. Mari buktikan:
/tool bandwidth-server set allowed-addresses4=198.51.100.0/24
/tool bandwidth-test address=192.0.2.20 user=btest password=GantiPasswordIni \
protocol=tcp direction=transmit local-tx-speed=50M duration=10s
Hasilnya `can not connect`, karena R1 (`192.0.2.10`) tidak ada di daftar. Sekarang kembalikan ke subnet yang benar:
/tool bandwidth-server set allowed-addresses4=192.0.2.0/24
Uji lanjutan: tambahkan `address=10.99.99.99` pada user `btest` di R2, lalu tes lagi dari R1. Login **tetap berhasil** — membuktikan setelan alamat milik user tidak membatasi login bandwidth test, hanya `allowed-addresses4`/`allowed-addresses6` yang berlaku.
⚠️ Hati-hati: Ini artinya membatasi user saja **tidak** melindungi server tes. Kalau server harus dijangkau dari internet, batasi lewat `allowed-addresses4`, dan jangan pernah mematikan `authenticate` pada router yang bisa dijangkau jaringan tidak tepercaya.
🔹 Bersih-bersih
Jangan tinggalkan lab dalam keadaan bisa dipakai orang lain. Di R2:
/user remove [find name=btest]
/user group remove [find name=btest]
/tool bandwidth-server set allowed-addresses4="" allowed-addresses6=""
/tool bandwidth-server print
Di R1, pastikan tidak ada sisa rule dan tidak ada sesi tes yang menggantung:
/ip firewall filter print where comment~"lab"
/tool bandwidth-server session print
🔹 Lembar hasil
Isi tabel ini selama praktik. Inilah yang membedakan laporan teknis dari tebakan.
| Uji | Perintah kunci | Hasil yang diharapkan | Yang dibuktikan | |---|---|---|---| | Baseline | limit 50M dua arah | 49–50 Mbps | alat ukur sehat | | A | `local-udp-tx-size=64` | jauh lebih rendah | Mbps bukan pps | | B | `connection-count=1` lalu 20 | naik bertahap | satu aliran ≠ agregat | | C | transmit / receive / both | wireless: both < jumlah | arah & airtime | | D | `random-data=yes` | mirip, atau turun karena CPU | kecurigaan kompresi | | E | drop UDP balik | rx 0 bps | peran arah & NAT | | F | ping saat tes jalan | latency melonjak | bufferbloat | | G | `connection-count=150` | `disconnected` | batas `max-sessions` | | H | `allowed-addresses4` salah | `can not connect` | user address bukan pembatas |
🏭 Dipakai di dunia kerja
- **Sekolah:** laporan "internet lambat" saat CBT sering berakar pada satu aliran yang kecil, bukan kapasitas gedung. Tes ber-`connection-count=1` memisahkan dua masalah itu sebelum teknisi membeli bandwidth baru.
- **Kantor:** rapat online butuh latency stabil, bukan angka unduh besar. Mengukur ping saat link penuh adalah cara termurah membuktikan perlu queue atau tidak.
- **ISP/warnet:** saat pelanggan mengeluh, angka tes yang menyebut protokol, arah, dan jumlah koneksi bisa dipertahankan di depan pelanggan. Angka tanpa metode hanya memicu debat.
- **Industri:** jendela backup malam ditentukan dari throughput nyata satu aliran ke server cadangan, bukan dari hasil tes agregat yang tidak pernah terjadi pada aplikasi backup.
- **NOC dan tim support:** baseline enam angka per lokasi menjadi pembanding saat insiden. Tanpa baseline, "normal" hanya opini.
- **Vendor dan integrator:** uji terima proyek (acceptance test) wajib menyebut alat, versi, durasi, dan jumlah koneksi — inilah bagian yang dicek saat serah terima.
✅ Verifikasi
Sebelum menutup laporan, jalankan pemeriksaan ini dan simpan tangkapan layarnya:
- `enabled: yes`, `authenticate: yes`, `max-sessions: 100` pada `/tool bandwidth-server print`.
- `bandwidth-test: yes` pada `/system/device-mode print` di kedua router.
- Tidak ada core di angka 100% pada `/system/resource cpu print` saat tes terbaik dijalankan.
- Selisih tiga kali pengukuran berturut-turut **di bawah 5%**.
- `lost-packets` nol pada tes di bawah kapasitas link.
- `/ip firewall filter print where comment~"lab"` kosong setelah bersih-bersih.
- `/tool bandwidth-server session print` tidak menyisakan sesi.
🧪 Uji cepat: Kalau hasil tes berbeda jauh dari baseline 50 Mbps padahal limit masih terpasang, masalahnya ada di alat ukur atau CPU — bukan di link. Periksa `connection-count` dan beban core lebih dulu.
⚠️ Kesalahan umum & troubleshooting
| Gejala | Penyebab | Perbaikan | |---|---|---| | `authentication failed` | user/password salah, atau policy bukan `test,winbox` | periksa `/user group print` di server | | `can not connect` | server mati, port TCP 2000 diblok, atau alamat client tidak di `allowed-addresses` | cek rule firewall dan daftar alamat | | `disconnected` | koneksi melebihi `max-sessions` | turunkan `connection-count` | | `not allowed by device-mode` | `bandwidth-test: no` | nyalakan dengan akses fisik | | Uji receive 0 bps | paket UDP server tidak sampai ke client | pakai TCP, atau izinkan UDP masuk | | Hanya hasil ping, tanpa throughput | server tes mati atau TCP 2000 diblok | cek server dan firewall | | Hasil rendah, CPU mendekati 100% | router jadi sumber/penerima trafik | tes lewat router, bukan dari router | | Hasil mentok di angka bulat | ada queue atau limit aktif | cek `/queue simple print` dan limit tes | | Hasil TCP lebih rendah dari UDP | TCP menahan diri saat ada loss/latency | itu wajar, bukan kerusakan | | `lost-packets` selalu > 0 di tes tanpa limit | pengirim UDP melampaui kapasitas | pasang limit di bawah kapasitas dulu |
Penjelasan satu baris untuk tabel di atas: **UDP menunjukkan apa yang hilang, TCP menyembunyikan loss dengan mengirim ulang.** Jadi link yang lossy bisa terlihat "lambat tapi sehat" di tes TCP.
🔐 Catatan keamanan & etika
- **Jangan** set `authenticate=no` pada router yang bisa dijangkau jaringan tidak tepercaya. Siapa pun bisa membebani router dan linkmu.
- Batasi dengan `allowed-addresses4` dan `allowed-addresses6`, bukan hanya dengan `address` pada user.
- Tes tanpa limit memakai **seluruh bandwidth** dan sebagian besar CPU router. Di link produksi, pasang limit atau tunggu jam sepi.
- Di uplink 4G/kuota, tes 10 detik pada 100 Mbps bisa menghabiskan puluhan MB kuota. Hitung dulu sebelum mengulang tes berkali-kali.
- Hapus user uji, rule firewall sementara, dan sesi yang menggantung setelah selesai.
- Mengukur link milik orang lain tanpa izin bukan praktik lab. Untuk tugas sekolah, cukup lab sendiri atau lab virtual.
📌 Kesimpulan
Angka bandwidth test tidak pernah salah — ia hanya menjawab pertanyaan yang kita berikan. Dengan memasang limit yang diketahui, menguji ukuran paket, jumlah koneksi, arah, dan latency saat link penuh, kamu bisa memisahkan masalah **kapasitas**, **CPU**, **loss**, dan **antrean**.
Langkah berikutnya: buka Mikrotik : Queue Sederhana untuk Bandwidth Management dan pasang limit per kelas, lalu ulangi Uji F untuk membuktikan latency saat link penuh benar-benar turun.
🔗 Materi terkait
- Mikrotik : Bandwidth Test dan Pengukuran Throughput — konsep dan alat ukurnya, pasangan artikel ini.
- Mikrotik : Queue Sederhana untuk Bandwidth Management — mengendalikan antrean setelah bottleneck ketemu.
- Mikrotik : Queue Tree Lanjutan (Hierarchical Queue dan Parent) — pembagian bandwidth berjenjang.
- Mikrotik : Praktikum Uji Hierarki Queue Tree (Limit-At, Priority, dan PCQ) — lab queue dengan pembanding.
- Mikrotik : Praktikum Diagnosa Jaringan Lambat dengan Torch dan Resource — mencari siapa yang memakai bandwidth.
- Mikrotik : Firewall Filter Dasar — dasar rule yang dipakai di Uji E dan Uji H.
- Mikrotik : Praktikum Cek Firewall Filter dengan Counter dan Log — membaca counter rule.
- Lihat semua materi Mikrotik
📚 Referensi
- MikroTik RouterOS Manual — Bandwidth Test
- MikroTik RouterOS Manual — Speed Test
- MikroTik RouterOS Manual — Device mode
- MikroTik RouterOS Manual — Firewall
- MikroTik RouterOS Manual — Queues
- IETF RFC 5737 — IPv4 Address Blocks Reserved for Documentation