RE: Iperf output formatting
Tabs might be a better ideas as long as they are preserved across cut and pasting from a terminal window to a file. Also if the header had no tabs in it then it would be easier to disregard (the header would all be in the left hand most cell of the table). However, that might be confusing since the spacing of the headings might not matche the data.
-----Original Message-----
From: Kevin Gibbs [mailto:kgibbs --at-- ncsa.uiuc.edu]
Sent: Sunday, February 23, 2003 10:16 PM
To: 'iperf-users --at-- dast.nlanr.net'
Subject: Re: Iperf output formatting
Well this begs the question would using tabs for alignment be a better
idea? Then excel would have a better time with the spaces. Also the
heading every 20 lines is for readability I would be interested to know if
anyone actually uses it for such or if everyone just trashes it with
scripts or what not.
Kevin
PS if anyone has more thoughts about reporting styles we have thrown the
idea around a lot to change things in that regard.
On Sun, 23 Feb 2003, Cottrell, Les wrote:
> One slightly annoying feaure of iperf output strikes me as worth
> reporting.
>
> Iperf output typically appears as:
>
> ------------------------------------------------------------
> Client connecting to 192.91.239.1, TCP port 5014
> TCP window size: 64.0 MByte (WARNING: requested 32.0 MByte)
> ------------------------------------------------------------
> [ 3] local 198.51.111.46 port 32772 connected with 192.91.239.1 port 5014
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0- 5.2 sec 128 MBytes 208 Mbits/sec
> [ 3] 5.2-10.3 sec 177 MBytes 290 Mbits/sec
> [ 3] 10.3-15.6 sec 210 MBytes 328 Mbits/sec
> [ 3] 15.6-20.2 sec 135 MBytes 246 Mbits/sec
> [ 3] 20.2-25.3 sec 188 MBytes 308 Mbits/sec
> [ 3] 25.3-30.0 sec 233 MBytes 419 Mbits/sec
> [ 3] 30.0-35.3 sec 315 MBytes 501 Mbits/sec
> [ 3] 35.3-40.2 sec 391 MBytes 672 Mbits/sec
> [ 3] 40.2-45.0 sec 499 MBytes 863 Mbits/sec
> [ 3] 45.0-50.1 sec 445 MBytes 738 Mbits/sec
> [ 3] 50.1-56.0 sec 408 MBytes 576 Mbits/sec
> [ 3] 56.0-60.2 sec 218 MBytes 433 Mbits/sec
> [ 3] 60.2-65.2 sec 318 MBytes 541 Mbits/sec
> [ 3] 65.2-70.1 sec 410 MBytes 702 Mbits/sec
> [ 3] 70.1-75.1 sec 525 MBytes 882 Mbits/sec
> [ 3] 75.1-80.0 sec 409 MBytes 690 Mbits/sec
> [ 3] 80.0-85.0 sec 439 MBytes 741 Mbits/sec
> [ 3] 85.0-90.1 sec 544 MBytes 902 Mbits/sec
> [ 3] 90.1-95.1 sec 384 MBytes 634 Mbits/sec
> [ 3] 95.1-100.0 sec 447 MBytes 771 Mbits/sec
> [ ID] Interval Transfer Bandwidth
> [ 3] 100.0-105.0 sec 542 MBytes 912 Mbits/sec
>
> When importing this into another application such as Excel there are a
> couple of problems in parsing the input:
>
> 1. the extra space between "0.0- 5.2" causes splitting by spaces to
> put the 5.2 and the data following the space before the 5.2 into the
> wrong columns.
>
> 2. The extra headings of the form
> [ ID] Interval Transfer Bandwidth
> Embedded in the table also need to be removed before the data is easy
> to manipulate.
>
> I see no reason to insert the extra space berore the 5.2 sec, if you
> really want to keep things lined up then insert the aligning space
> before or after the sec, and anyhow the column alignment changes after
> 100 sec.
>
> The extra heading does help human readability of the output. It is
> arguable this is important even though everything is well labelled on each line. If you feel this is critical then maybe another option to enable easier to machine parse output might be an alternative.
>
> Just a thought, and keep up the good work.
>