Introduction
Bad Network performance and frequently interruptions are often because of a insufficiently network infrastructure. Under-sized or old network hardware, a wrong configuration or maybe hardware faults can be a bad influence for the performance in a network and make the work on the PC more difficult. Long waiting periods and even data loss are the consequences. With the application JPerf is it possible to measure the information flow-rate (the bandwidth) in a network and to determine the specific weak point.
System requirements
To execute a performance test you need a environment with a minimum of 2 PC´s, which are connected trough a network. On both PC´s JPerf must be started then. The application are executing in a Java-runtime environment, which needs the following minimal configuration.
Network-performance tests with IPerf/JPerf:
- Intel- or a 100% compatible processor
- 64 MB random access memory (RAM)
- 98 MB space on the harddisk
The following operating systems are supported:
- Sun Solaris x86/x64
- Linux
- Apple OS X
Installation
Installation IPerf on IPFire
You can comfortably install IPerf over Pakfire or via Console:
pakfire install iperf
Installation IPerf / JPerf on Windows systems
To install IPerf on Windows you must download iPerf3 (or IPerf 2). Note that iPerf3 is not backwards compatible with iPerf2.
To install JPerf on Windows you must download JPerf
After you download it successfully you need to copy the contents of both archives in a own directory (no subdirectory for IPerf and JPerf). Subsequently you have to execute the jperf.bat and the window of JPerf will be started on the Windows system PC´s
Installation IPerf / JPerf on Linux systems
(Not tested yet)
To install IPerf on Linux you must download iPerf3 (or IPerf 2). Note that iPerf3 is not backwards compatible with iPerf2.
To install JPerf on Linux you must download JPerf
After you download it successfully you need to copy the contents of both archives in a own directory (no subdirectory for IPerf and JPerf). Subsequently you have to execute the jperf.sh over the Console and the window of JPerf will be started on the Linux PC´s
Installation IPerf on MacOS
To install IPerf on MacOS you must download iPerf3 (or IPerf 2). Note that iPerf3 is not backwards compatible with iPerf2.
Test the Network with IPerf and JPerf
Test with IPFire and one Client
To make a performance test, start first IPerf on IPFire
The command in the Console is
iperf -s
The next step is to start JPerf on the PC. Choose in the upper display area the client -mode and enter under the "Serveraddress" the network address or IPFire´s hostname.
In client -mode is it also possible to choose how long the JPerf-performancetest should be execute, you can find the preferences over the tab "application layer options" in the left screen area. You can add a value in the field "Transmit", below is it possible to add bytes and seconds over the "radiobuttons", JPerf gives there the possibility to choose a specific time or an amount of data which should run during the test. For an easy performancetest you can choose for example the execution on time and a value from 30 to 60 seconds.
Note:
Since the transmission speed in the network is subject to fluctuations, can the test results be falsified, if the time for the test run is selected too briefly. Generally is valid: the longer the testing time, the more meaningfully the test results!
Test with IPFire and several Clients
Often it comes only then to network delays if several Clients access at the same time over the network to a server. In order to simulate this behavior is it possible to execute a performance test with several Client PCs. Start in addition first JPerf in server -mode on the server which should be examined.
Subsequently, you start the program on any number of PC in the network in the Client -mode. The process on the Client PCs must be started by hand, the selected testing time should be increased accordingly.
Thus it is guaranteed that all Clients transmit a time long actually at the same time data to the server.
Note:
If several PCs access a server at the same time, they divide its max. bandwidth under itself. With a test run for a Client and a server with in each case an Gigabit-interface, if an average value is measured by 400.000 Kbit/s, the bandwidth should with a test with two Clients for instance with 200.000 Kbit/s per Client, and so on …
If the bandwidth goes from a certain number of Clients extraordinarily down, (for example with four
Clients 100.000 Kbit/s per Client, with five Clients 20.000 Kbit/s per Client in a Gigabit network)
points this to an insufficient sizing, a false configuration or a hardware error in the network infrastructure.
Read off the results
After you input all values you can begin to start the test run, with one click on the run lperf! -button on the client machine. The Client begins now to transmit data to the server. The transmission speed is measured and displayed in the result area of the window.
Note:
If the result area should not show the complete time interval of the test, you can adapt the display over the context menu with the instruction out zoom - > to horizontal axle.
An average value from 80.000 to 90.000 Kbit/s in a 100 Mbit network or, 350.000 to 450.000 Kbit/s in a Gigabit network should be achieved with a sufficient infrastructure.
In case the test result is clearly different (for example 50.000 kbit/s in a 100 Mbit network) is this a hint for insufficient sizing, a false configuration or a hardware error.
Note:
The expected bandwidth always depends on the weaker one of the PCs involved. The bandwidth which can be expected in a Gigabit network can be achieved only if both PCs involved are equipped with an Gigabit interface. Has one the PCs an Gigabit interface, the other one however only over a 100 Mbit binding can be expected the max. bandwidth indicated by 100 Mbit.!
Repeated test runs
In order to identify the sources of errors in a network more exactly, respectively to limit the amount of possible causes, it can be meaningful to execute a test several times to different times. If the achieved bandwidth is strongly reduced in a network to the normal period of operation, normalizes itself however during work-free times (in lunch time, after end of a workday) is an under-sizing or an overloading of the used network components usualy the case. If the measured bandwidth remains also in work-free times far behind the value which can be expected, is this to be due rather to a false configuration or a hardware error.