Re: Iperf output formatting


  IMHO CSV output would make the most sense because it is easily parsable by
  Excel and Perl and it is self describing.  I think we should leave the
  current output method in place but add a flag --csv-output or somesuch that
  causes the output to be in CSV format.

On Sun, Feb 23, 2003 at 10:47:28PM -0800, Cottrell, Les wrote:
> 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.
> > 

-- 
Jon Dugan             |  Senior Network Engineer, NCSA Network Research
jdugan --at-- ncsa.uiuc.edu  |  269 CAB, 605 E Springfield, Champaign, IL 61820
217-244-7715          |  http://www.ncsa.uiuc.edu/~jdugan/



Other Mailing lists | Author Index | Date Index | Subject Index | Thread Index