Iperf CSV output format

The fields are

timestamp,source_address,source_port,destination_address,destination_port,interval,transferred_bytes,bits_per_second

I deduced this by looking at

$ iperf -c localhost -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to localhost, TCP port 5001
TCP window size:  648 KByte (default)
------------------------------------------------------------
[  5] local 127.0.0.1 port 54401 connected with 127.0.0.1 port 5001
[  4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 54401
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec  50.3 GBytes  43.2 Gbits/sec
[  4]  0.0-10.0 sec  50.3 GBytes  43.2 Gbits/sec

$ iperf -c localhost -r -y C
20140114124826,127.0.0.1,54402,127.0.0.1,5001,5,0.0-10.0,52551090176,42041052917
20140114124826,127.0.0.1,5001,127.0.0.1,54402,4,0.0-10.0,52551090200,41999020136

EDIT: You can find the relevant source code here:

// TCP Reporting
printf( reportCSV_bw_format,
timestamp,
(stats->reserved_delay == NULL ? ",,," : stats->reserved_delay),
stats->transferID,
stats->startTime,
stats->endTime,
stats->TotalLen,
speed);
} else {
// UDP Reporting
printf( reportCSV_bw_jitter_loss_format,
timestamp,
(stats->reserved_delay == NULL ? ",,," : stats->reserved_delay),
stats->transferID,
stats->startTime,
stats->endTime,
stats->TotalLen,
speed,
stats->jitter*1000.0,
stats->cntError,
stats->cntDatagrams,
(100.0 * stats->cntError) / stats->cntDatagrams, stats->cntOutofOrder );
} 

The accepted answer skips one odd field: the one that comes after the source and destination IP+port pairs:

timestamp,
source_address,
source_port,
destination_address,
destination_port,
XXX,                  <---- this one
interval,
transferred_bytes,
bits_per_second

The code in the accepted answer says this comes from the transferID variable. Some of the other answers here seem to argue that it represents a connection identifier or connection direction. However, a quick dive through the code indicates that transferID comes from a global variable named groupID. It is initialized to zero:

// Global ID that we increment to be used 
// as identifier for SUM reports
int groupID = 0;

However, a quick grep through the code seems to indicate that it is incremented and decremented a lot, very confusingly. There don't seem to be any defined constants that say what it means. Manual testing (iperf version 2.0.9 (9 Sept 2016) pthreads) shows the number being reused between connections. So I guess the moral of the story is... ignore that number? Or use iperf3.

Look at the 6th field assuming "," (comma) being a field separator. Then look at these lines here:

Server listening on TCP port 5001
------------------------------------------------------------
Client connecting to localhost, TCP port 5001

[ 5] local 127.0.0.1 port 54401 connected with 127.0.0.1 port 5001 [ 4] local 127.0.0.1 port 5001 connected with 127.0.0.1 port 54401 [ ID] Interval Transfer Bandwidth [ 5] 0.0-10.0 sec 50.3 GBytes 43.2 Gbits/sec [ 4] 0.0-10.0 sec 50.3 GBytes 43.2 Gbits/sec

"5" indicates client -> server connection, then "4" indicates "server -> client" connection (look at the source/destination ports to tell, in this particular example given by "sciurus".

date and time, source IP, source port, destination IP, destination port, iperf process number, time interval, amount of data transferred (bytes), bandwidth (bits per second), jitter (milliseconds), number of lost datagrams, total number of datagrams sent, percentage loss, number of datagrams received out of order

I got the above information from:

http://www.jb.man.ac.uk/~jcullen/code/python/iperf_tests.py