Iperf CSV output format

Solution 1:

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 );
} 

Solution 2:

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.