In my last post, I talked about using iperf to look at network performance. This post looks at using a close relation of iperf called jperf. Jperf is actually a GUI front end to the iperf application. (Jperf is downloadable from the sourceforge site.)Installing jperf is very simple; simply download and unzip it to the directory you want to run it from. It has a jperf.bat file and a jperf.sh file; as I run jperf on a Linux host, I use the jperf.sh file. Running the jperf.sh file produces the GUI as shown in Figure A (click to enlarge images).
Jperf can be run as a server or as a client. One of the handy aspects of using jperf is that to run it, you click a button called "run iperf". Jperf will then display the iperf command it is running in the background.There are sections for application layer options and transport layer options. This post looks at the transport layer options. As Figure A shows, there are a number of TCP parameters that can be modified. A few explanatory notes are in order to explain these parameters.
The Mean Segment Size (MSS) gives the option to change the amount of data in each frame. In terms of transmission, it is less than the MTU of the card. The Window size denotes how many packets can be sent before an acknowledgement is required. The Buffer length is the amount of traffic that can be queued for transmission. These three parameters can all be adjusted, depending on what you want to test.Figure B is the result of a run using the default TCP parameters.
There is a setting I have used for this run called "Num Connections". This allows you to define how many connections are allowed to the server; here it is set to five. For this run, four actual connections were made. As can be seen, jperf draws and updates the graph as each transmission is received. The output window below the graph provides the numbers used to draw the graph. This output can be saved if you want to use some other graphing program such as Libre Office Calc.
Again, the number of connections allowed is five. Here the output for bandwidth and jitter are shown. As can be seen in both the graphs, four connections were made to the server. The average throughput is somewhat higher for UDP than for TCP. This is because UDP does not acknowledge whether a frame is received or not. Hence, UDP will send out the frames as fast as it receives them. The second graph shows the jitter, again for all four users. In this case the highest value for the jitter is around 2.5 ms, which is acceptable for most UDP applications. As for TCP, you can save the output as a text file.
Jperf provides a handy GUI option for iperf. A nice feature is being able to re-use the iperf command line strings if you want to so some scripting for the purpose of monitoring, data gathering or testing.
Scott Reeves has worked for Hewlett Packard on HP-UX servers and SANs, and has worked in similar areas in the past at IBM. Currently he works as an independent IT consultant, specializing in Wi-Fi networks and SANs.