Benchmark: Mengukur packet per second - Revision history

Onnowpurbo: /* Method #1: The old-school “ping“ */

2018-12-10T03:00:22Z

Method #1: The old-school “ping“

← Older revision		Revision as of 03:00, 10 December 2018
Line 13:		Line 13:
	Jalankan sebagai root:		Jalankan sebagai root:

			sudo su
	ping -q -s 1 -f 192.168.100.101		ping -q -s 1 -f 192.168.100.101

Onnowpurbo: /* Pranala Menarik */

2018-12-10T02:51:17Z

Pranala Menarik

← Older revision		Revision as of 02:51, 10 December 2018
Line 80:		Line 80:

	* [[Benchmark]]		* [[Benchmark]]
	* [[Internet Offline: ~~Benchmark~~]]		* [[ Internet Offline: packets-per-second benchmark]]

Onnowpurbo: /* Referensi */

2018-12-10T02:49:01Z

Referensi

← Older revision		Revision as of 02:49, 10 December 2018
Line 76:		Line 76:

	* https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/		* https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/

			==Pranala Menarik==

			* [[Benchmark]]
			* [[Internet Offline: Benchmark]]

Onnowpurbo: /* Method #2: The much faster and extended “hping3“ */

2018-12-10T02:19:52Z

Method #2: The much faster and extended “hping3“

← Older revision		Revision as of 02:19, 10 December 2018
Line 31:		Line 31:

	==Method #2: The much faster and extended “hping3“==		==Method #2: The much faster and extended “hping3“==

			Install

			sudo su
			apt update
			apt install hping3

	Jalankan perintah berikut		Jalankan perintah berikut
Line 46:		Line 52:
	sys 0m1.160s		sys 0m1.160s

	~~If the~~ packet loss is 0%, ~~decrease~~ “-i u20” ~~to something smaller like~~ “-i u15” ~~or less~~. ~~Make sure to not decrease it too much, or you may temporarily lose connectivity to the~~ device ~~(because of switch problems?)~~.		Jika packet loss 0%, kurang “-i u20” menjadi lebih kecil, misalnya, “-i u15” atau lebih kecil lagi. Pastikan jangan terlalu kecil karena kita akan kehilangan sambungan ke device tersebut.

	~~The calculations for the packets~~-per-second ~~value are the same as for “ping” above~~. ~~You need to divide the received packets to the time:~~		Perhitungan packet-per-second sama dengan ping di atas. Kita perlu membagi jumlah paket yang di terima dengan waktu yang di butuhkan

	10818 packets / 2.635 secs ~= 4105 packets-per-second		10818 packets / 2.635 secs ~= 4105 packets-per-second

	~~Because the calculated packets~~-per-second ~~represent the rate of successful replies~~, ~~we need to multiply it by two~~, ~~in order to get the actual packets~~-per-second, ~~as the count of the replies is the same as the count of the successfully received requests~~. ~~The final result is~~:		Karena perhitungan packet-per-second di atas merepresentasikan reply ping yang berhasil, kita perlu mengalikan dengan dua, untuk memperoleh packet-per-second yang sebenarnya, dengan memperhitungkan packet request. Hasil akhirnya:

	4105 x 2 = 8210 packets-per-second		4105 x 2 = 8210 packets-per-second

	~~The calculated value by~~ “hping3” ~~is the same as the one by “ping”~~. ~~We are either correct, or both methods failed…🙂~~		Hasl perhitungan dari “hping3” harusnya tidak beda jauh dari "ping”.

	~~Some notes which apply for both methods:~~		==Catatan==

	* ~~You should run multiple instances of the~~ ping ~~commands~~, ~~either from the same or from different machines~~, ~~in order to be able to properly saturate the connection of the machine which is being tested~~.		* Sebaiknya kita menjalankan beberapa ping, bisa dari mesin yang sama atau mesin yang berbeda, untuk membuat saturasi sambungan ke mesin yang sedang di uji.
	* ~~The machines from which you test have a hardware~~ rate limit ~~too~~. ~~If the host being tested has a similar rate limit~~, ~~you surely need to run the~~ ping ~~commands from more than a single machine~~.		* Mesin yang di uji mempunyai rate limit. Jika semua mesin sama, maka sebaiknya agar saturasi maka ping di kirim dari beberapa mesin yang berbeda.
	* ~~You should run more and more simultaneous ping commands until you start to receive similar results for the calculated packets-per-second rate. This indicates a saturation of the network~~ bandwidth, ~~usually at the remote host which is being tested, but may also indicate a saturation somewhere in the route between your tester machines and the tested host…~~		* Ethernet switch biasanya mempunyai hardware, bandwidth, packet-per-second limit. Ini akan mempengaruhi hasil.
	* The ethernet switches also have a hardware limit of the bandwidth and the packets-per-second. ~~This may influence the overall results~~.		* Jika ada firewall di device, sebaiknya dibuang dulu. Karena firewall akan memperlambat pemrosesan packet.
	* ~~If the tested~~ device ~~has any~~ firewall ~~rules, you should temporarily remove them, because they may slow down the packets processing~~.		* Jika device yang di test adalah linux, kita dapat membuang sementara ICMP rate limit dengan menjalankan perintah “sysctl net.ipv4.icmp_ratelimit=0” dan “sysctl net.ipv4.icmp_ratemask=0”.
	* ~~If the tested~~ device ~~is a Linux box~~, ~~you should temporarily remove the~~ ICMP rate ~~limits by executing~~ “sysctl net.ipv4.icmp_ratelimit=0” ~~and~~ “sysctl net.ipv4.icmp_ratemask=0”.		* Jika device yang di test adalah sebuah router, cara yang lebih baik untuk mentest packet-per-second maximum rate adalah dengan membanjiri satu interface dan menghitungnya di interface yang lain.
	* ~~If the tested~~ device ~~is a~~ router, ~~a better way to test its packets~~-per-second maximum rate ~~is to flood one of its interfaces and count the output rate at the other one, assuming that you are actually flooding a host which is behind the router according to its routing tables~~.

	==Referensi==		==Referensi==

	* https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/		* https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/

Onnowpurbo: /* Method #2: The much faster and extended “hping3“ */

2018-12-09T23:55:32Z

Method #2: The much faster and extended “hping3“

← Older revision		Revision as of 23:55, 9 December 2018
Line 36:		Line 36:
	time hping3 192.168.100.101 -q -i u20 --icmp\|tail -n10		time hping3 192.168.100.101 -q -i u20 --icmp\|tail -n10

	~~This will bombard the host~~ “192.168.100.101” ~~with~~ ICMP echo ~~requests~~. ~~After a few seconds~~, ~~you can interrupt the~~ ping ~~by pressing~~ CTRL+C. ~~Here is the output~~:		Ini akan mem-bombardir mesin “192.168.100.101” dengan ICMP echo request. Setelah beberapa detik, kita dapat meng-interupsi proses ping dengan menekan tombol CTRL+C. Outputnya kira-kira:

	--- 192.168.100.101 hping statistic ---		--- 192.168.100.101 hping statistic ---

Onnowpurbo: /* Method #1: The old-school “ping“ */

2018-12-09T23:54:15Z

Method #1: The old-school “ping“

← Older revision		Revision as of 23:54, 9 December 2018
Line 20:		Line 20:
	20551 packets transmitted, 20551 received, 0% packet loss, time 6732ms		20551 packets transmitted, 20551 received, 0% packet loss, time 6732ms

	~~You can calculate the~~ packets-per-second rate ~~by dividing the count of the packets to the elapsed time~~:		Maka packets-per-second rate di peroleh dengan membagi jumlah paket dengan waktu yang dibutuhkan:

	20551 packets / 6.732 secs ~= 3052 packets-per-second		20551 packets / 6.732 secs ~= 3052 packets-per-second

	~~Note that this is the count of the replies at~~ 0% packet loss. ~~Which means that the same~~ count ~~requests were sent too. So the final result is~~:		Perlu di catat bahwa ini hanya menghitung "reply" saat 0% packet loss. Artinya jika kita masukan count request ke dalamnya maka hasil akhirnya adalah:

	3052 x 2 = 6104 packets-per-second		3052 x 2 = 6104 packets-per-second

	~~Note that if you run~~ multiple ~~“ping” commands simultaneously~~, ~~you will get more accurate results~~. ~~You need to sum the average values from every “ping” command~~, ~~in order to calculate the overall packets~~-per-second rate. ~~For example~~, ~~when I performed the measurement against the very same host but using two or three simultaneous “ping” commands~~, ~~the average packets~~-per-second ~~value was settled to~~ 8000.		Catatan: jika kita dapat menjalankan multiple ping sekaligus, maka kita akan dapat memperoleh hasil yang lebih akurat. Kita perlu menjumlahkan rata-rata yang di peroleh dari masing-masing ping, untuk memperoleh packet-per-second rate yang sesungguhnya. Contoh dalam kasus ini, jika kita menjalankan 2 atau 3 ping sekaligus, maka akan memperoleh nilai paket-per-second rata-rata sekitar 8000.

	==Method #2: The much faster and extended “hping3“==		==Method #2: The much faster and extended “hping3“==

Onnowpurbo: /* Method #1: The old-school “ping“ */

2018-12-09T23:49:32Z

Method #1: The old-school “ping“

Onnowpurbo at 22:34, 9 December 2018

2018-12-09T22:34:23Z

← Older revision		Revision as of 22:34, 9 December 2018
Line 1:		Line 1:
	Sumber: https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/		Sumber: https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/

			Artikel ini menjelaskan tentang teknik mengukur throughput dan kinerja jaringan dari sebuah komputer Linux, dengan cara perkiraan.

	~~This article is about measuring network~~ throughput ~~and performance using a Linux box, in a very approximate way~~.		Ada banyak tolok ukur kinerja jaringan dan stress-test yang mengukur tingkat transfer bandwidth maksimum perangkat - yaitu berapa banyak byte per detik atau bit per detik yang dapat ditangani perangkat. Contoh bagus untuk benchmark test semacam ini adalah NetPerf, Iperf, atau bahkan beberapa unduhan wget yang berjalan secara bersamaan dan menyimpan file yang diunduh ke /dev/null, sehingga kita menghilangkan throughput hard disk dari komputer lokal.

	~~There are many network performance benchmarks and stress~~-~~tests which measure the maximum bandwidth transfer~~ rate ~~of a device – that is how many bytes-~~per-second or bits-per-second a device can handle. Good examples for such benchmark tests are NetPerf, Iperf, or even multiple Wget downloads which run simultaneously and save the downloaded files to /dev/null, so that we eliminate the hard disk throughput of the local machine.		Ada metrik lain yang sangat penting untuk throughput perangkat jaringan - rate maksimum paket per detik (pps).

	~~There is however another very important metric for the throughput of a network device – its packets-~~per~~-second~~ (~~pps~~) ~~maximum rate~~.		Karena sulitnya menemukan tool yang sesuai untuk mengukur paket per detik dari perangkat jaringan. Pada kesempatan ini akan di perlihatkan dua (2) metoda untuk mengukur menggunakan echo ICMP yang biasa dikenal sebagai "ping", untuk memperkirakan paket per detik dari perangkat jaringan yang langsung terhubung ke jaringan.

	~~Today I struggled a lot to find out a tool which measures the packets~~-per-second throughput of a network device and couldn’t find a suitable one. Therefore, I tried two different methods both using the ICMP echo protocol, in order to approximately measure the packets-per-second metric of a remote network device which is directly attached to my network.		==Method #1: The old-school “ping“==

	~~Method #1: The old-school “ping“. Execute the following as~~ root:		Jalankan sebagai root:

	ping -q -s 1 -f 192.168.100.101		ping -q -s 1 -f 192.168.100.101

	~~This floods the destination~~ “192.168.100.101” ~~with the smallest possible~~ PING ~~packets~~. ~~Here is a sample output:~~		Perintah di atas akan membanjiri tujuan “192.168.100.101” dengan paket PING yang paling kecil. Hasilnya kira-kira,

	--- 192.168.100.101 ping statistics ---		--- 192.168.100.101 ping statistics ---
	20551 packets transmitted, 20551 received, 0% packet loss, time 6732ms		20551 packets transmitted, 20551 received, 0% packet loss, time 6732ms

	You can calculate the packets-per-second rate by dividing the count of the packets to the elapsed time:		You can calculate the packets-per-second rate by dividing the count of the packets to the elapsed time:

Onnowpurbo: Created page with "Sumber: https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/ This article is about measuring network throughput and performan..."

2016-11-13T10:45:23Z

Created page with "Sumber: https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/ This article is about measuring network throughput and performan..."

New page

Sumber: https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/

This article is about measuring network throughput and performance using a Linux box, in a very approximate way.

There are many network performance benchmarks and stress-tests which measure the maximum bandwidth transfer rate of a device – that is how many bytes-per-second or bits-per-second a device can handle. Good examples for such benchmark tests are NetPerf, Iperf, or even multiple Wget downloads which run simultaneously and save the downloaded files to /dev/null, so that we eliminate the hard disk throughput of the local machine.

There is however another very important metric for the throughput of a network device – its packets-per-second (pps) maximum rate.

Today I struggled a lot to find out a tool which measures the packets-per-second throughput of a network device and couldn’t find a suitable one. Therefore, I tried two different methods both using the ICMP echo protocol, in order to approximately measure the packets-per-second metric of a remote network device which is directly attached to my network.

Method #1: The old-school “ping“. Execute the following as root:

ping -q -s 1 -f 192.168.100.101

This floods the destination “192.168.100.101” with the smallest possible PING packets. Here is a sample output:

--- 192.168.100.101 ping statistics ---
20551 packets transmitted, 20551 received, 0% packet loss, time 6732ms

You can calculate the packets-per-second rate by dividing the count of the packets to the elapsed time:

20551 packets / 6.732 secs ~= 3052 packets-per-second

Note that this is the count of the replies at 0% packet loss. Which means that the same count requests were sent too. So the final result is:

3052 x 2 = 6104 packets-per-second

Note that if you run multiple “ping” commands simultaneously, you will get more accurate results. You need to sum the average values from every “ping” command, in order to calculate the overall packets-per-second rate. For example, when I performed the measurement against the very same host but using two or three simultaneous “ping” commands, the average packets-per-second value was settled to 8000.

Method #2: The much faster and extended “hping3“. Execute the following:

taurus:~# time hping3 192.168.100.101 -q -i u20 --icmp|tail -n10

This will bombard the host “192.168.100.101” with ICMP echo requests. After a few seconds, you can interrupt the ping by pressing CTRL+C. Here is the output:

--- 192.168.100.101 hping statistic ---
67932 packets transmitted, 10818 packets received, 85% packet loss
round-trip min/avg/max = 0.5/7.8/15.6 ms

real 0m2.635s
user 0m0.368s
sys 0m1.160s

If the packet loss is 0%, decrease “-i u20” to something smaller like “-i u15” or less. Make sure to not decrease it too much, or you may temporarily lose connectivity to the device (because of switch problems?).

The calculations for the packets-per-second value are the same as for “ping” above. You need to divide the received packets to the time:

10818 packets / 2.635 secs ~= 4105 packets-per-second

Because the calculated packets-per-second represent the rate of successful replies, we need to multiply it by two, in order to get the actual packets-per-second, as the count of the replies is the same as the count of the successfully received requests. The final result is:

4105 x 2 = 8210 packets-per-second

The calculated value by “hping3” is the same as the one by “ping”. We are either correct, or both methods failed…🙂

Some notes which apply for both methods:

* You should run multiple instances of the ping commands, either from the same or from different machines, in order to be able to properly saturate the connection of the machine which is being tested.
* The machines from which you test have a hardware rate limit too. If the host being tested has a similar rate limit, you surely need to run the ping commands from more than a single machine.
* You should run more and more simultaneous ping commands until you start to receive similar results for the calculated packets-per-second rate. This indicates a saturation of the network bandwidth, usually at the remote host which is being tested, but may also indicate a saturation somewhere in the route between your tester machines and the tested host…
* The ethernet switches also have a hardware limit of the bandwidth and the packets-per-second. This may influence the overall results.
* If the tested device has any firewall rules, you should temporarily remove them, because they may slow down the packets processing.
* If the tested device is a Linux box, you should temporarily remove the ICMP rate limits by executing “sysctl net.ipv4.icmp_ratelimit=0” and “sysctl net.ipv4.icmp_ratemask=0”.
* If the tested device is a router, a better way to test its packets-per-second maximum rate is to flood one of its interfaces and count the output rate at the other one, assuming that you are actually flooding a host which is behind the router according to its routing tables.

Thanks to zImage for his usual willingness to help people out by giving good tips and ideas.

==Referensi==

* https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/

← Older revision		Revision as of 23:49, 9 December 2018
Line 22:		Line 22:
	You can calculate the packets-per-second rate by dividing the count of the packets to the elapsed time:		You can calculate the packets-per-second rate by dividing the count of the packets to the elapsed time:

	20551 packets / 6.732 secs ~= 3052 packets-per-second		20551 packets / 6.732 secs ~= 3052 packets-per-second

	Note that this is the count of the replies at 0% packet loss. Which means that the same count requests were sent too. So the final result is:		Note that this is the count of the replies at 0% packet loss. Which means that the same count requests were sent too. So the final result is:

	3052 x 2 = 6104 packets-per-second		3052 x 2 = 6104 packets-per-second

	Note that if you run multiple “ping” commands simultaneously, you will get more accurate results. You need to sum the average values from every “ping” command, in order to calculate the overall packets-per-second rate. For example, when I performed the measurement against the very same host but using two or three simultaneous “ping” commands, the average packets-per-second value was settled to 8000.		Note that if you run multiple “ping” commands simultaneously, you will get more accurate results. You need to sum the average values from every “ping” command, in order to calculate the overall packets-per-second rate. For example, when I performed the measurement against the very same host but using two or three simultaneous “ping” commands, the average packets-per-second value was settled to 8000.

	Method #2: The much faster and extended “hping3“~~. Execute the following:~~		==Method #2: The much faster and extended “hping3“==

	~~taurus:~#~~ time hping3 192.168.100.101 -q -i u20 --icmp\|tail -n10		Jalankan perintah berikut

			time hping3 192.168.100.101 -q -i u20 --icmp\|tail -n10

	This will bombard the host “192.168.100.101” with ICMP echo requests. After a few seconds, you can interrupt the ping by pressing CTRL+C. Here is the output:		This will bombard the host “192.168.100.101” with ICMP echo requests. After a few seconds, you can interrupt the ping by pressing CTRL+C. Here is the output:

	--- 192.168.100.101 hping statistic ---		--- 192.168.100.101 hping statistic ---
	67932 packets transmitted, 10818 packets received, 85% packet loss		67932 packets transmitted, 10818 packets received, 85% packet loss
	round-trip min/avg/max = 0.5/7.8/15.6 ms		round-trip min/avg/max = 0.5/7.8/15.6 ms

	real 0m2.635s		real 0m2.635s
	user 0m0.368s		user 0m0.368s
	sys 0m1.160s		sys 0m1.160s

	If the packet loss is 0%, decrease “-i u20” to something smaller like “-i u15” or less. Make sure to not decrease it too much, or you may temporarily lose connectivity to the device (because of switch problems?).		If the packet loss is 0%, decrease “-i u20” to something smaller like “-i u15” or less. Make sure to not decrease it too much, or you may temporarily lose connectivity to the device (because of switch problems?).
Line 48:		Line 50:
	The calculations for the packets-per-second value are the same as for “ping” above. You need to divide the received packets to the time:		The calculations for the packets-per-second value are the same as for “ping” above. You need to divide the received packets to the time:

	10818 packets / 2.635 secs ~= 4105 packets-per-second		10818 packets / 2.635 secs ~= 4105 packets-per-second

	Because the calculated packets-per-second represent the rate of successful replies, we need to multiply it by two, in order to get the actual packets-per-second, as the count of the replies is the same as the count of the successfully received requests. The final result is:		Because the calculated packets-per-second represent the rate of successful replies, we need to multiply it by two, in order to get the actual packets-per-second, as the count of the replies is the same as the count of the successfully received requests. The final result is:

	4105 x 2 = 8210 packets-per-second		4105 x 2 = 8210 packets-per-second

	The calculated value by “hping3” is the same as the one by “ping”. We are either correct, or both methods failed…🙂		The calculated value by “hping3” is the same as the one by “ping”. We are either correct, or both methods failed…🙂
Line 65:		Line 67:
	* If the tested device is a Linux box, you should temporarily remove the ICMP rate limits by executing “sysctl net.ipv4.icmp_ratelimit=0” and “sysctl net.ipv4.icmp_ratemask=0”.		* If the tested device is a Linux box, you should temporarily remove the ICMP rate limits by executing “sysctl net.ipv4.icmp_ratelimit=0” and “sysctl net.ipv4.icmp_ratemask=0”.
	* If the tested device is a router, a better way to test its packets-per-second maximum rate is to flood one of its interfaces and count the output rate at the other one, assuming that you are actually flooding a host which is behind the router according to its routing tables.		* If the tested device is a router, a better way to test its packets-per-second maximum rate is to flood one of its interfaces and count the output rate at the other one, assuming that you are actually flooding a host which is behind the router according to its routing tables.

	~~Thanks to zImage for his usual willingness to help people out by giving good tips and ideas.~~




	==Referensi==		==Referensi==

	* https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/		* https://blog.famzah.net/2009/11/24/benchmark-the-packets-per-second-performance-of-a-network-device/