Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Strange performance results -- any ideas?
From: Dirk Zimoch <dirk.zimoch@psi.ch>
To: Dirk Zimoch <dirk.zimoch@psi.ch>
Cc: EPICS <tech-talk@aps.anl.gov>
Date: Wed, 20 Jun 2012 17:59:14 +0200
Dirk Zimoch wrote:
Hi all,

I am testing the performance of array parsing with StreamDevice on a Linux system. I am reading strings like "3.1415,3.1415,...\n" into a waveform record with FTVL=DOUBLE. The input is via TCP from localhost.

I found a very strange duration/size relationship:
size       1     duration:      423     time/element:  423.0
size       2     duration:      234     time/element:  117.0
size       4     duration:      229     time/element:   57.2
size       8     duration:      239     time/element:   29.9
size      16     duration:      238     time/element:   14.9
size      32     duration:      259     time/element:    8.1
size      64     duration:      281     time/element:    4.4
size     128     duration:      312     time/element:    2.4
size     256     duration:      397     time/element:    1.6
size     512     duration:      552     time/element:    1.1
size    1024     duration:    40023     time/element:   39.1
size    2048     duration:    41450     time/element:   20.2
size    4096     duration:    41678     time/element:   10.2
size    8192     duration:     5579     time/element:    0.7
size   16384     duration:    10947     time/element:    0.7
size   32768     duration:    21826     time/element:    0.7
size   65536     duration:    43508     time/element:    0.7
size  131072     duration:    77358     time/element:    0.6
size  262144     duration:   138533     time/element:    0.5
size  524288     duration:   275591     time/element:    0.5
size 1048576     duration:   518404     time/element:    0.5

I have now replaced the EPICS IOC by a different receiver that does not process the data in any way but simply dumps it:
cat < /dev/tcp/localhost/40123 >/dev/null

The server is still almost the same, it just does not expect any replies any more. Here are the results:

size       1     duration:       26     time/element:   26.0
size       2     duration:       25     time/element:   12.5
size       4     duration:       22     time/element:    5.5
size       8     duration:       20     time/element:    2.5
size      16     duration:       25     time/element:    1.6
size      32     duration:       24     time/element:    0.8
size      64     duration:       31     time/element:    0.5
size     128     duration:       43     time/element:    0.3
size     256     duration:       68     time/element:    0.3
size     512     duration:      118     time/element:    0.2
size    1024     duration:      219     time/element:    0.2
size    2048     duration:      417     time/element:    0.2
size    4096     duration:      791     time/element:    0.2
size    8192     duration:     1550     time/element:    0.2
size   16384     duration:     3381     time/element:    0.2
size   32768     duration:     6747     time/element:    0.2
size   65536     duration:    13327     time/element:    0.2
size  131072     duration:    24354     time/element:    0.2
size  262144     duration:    38822     time/element:    0.1
size  524288     duration:    77327     time/element:    0.1
size 1048576     duration:   154387     time/element:    0.1

So it seems that neither the data server (a Tcl program) nor the TCP layer is the source of the strange delay.






All times are in 1e-6 seconds. Time is measured on the server. The clock starts before sending the string and stops after the waveform sends back an acknowledge.

Protocol: {in "%f"; out "%(NORD)d";}

I understand that for small arrays, the time is dominated by overhead and stays more or less constant.

But does anyone have an idea why is there this strange performance drop for sizes between 1024 and 4096 elements?

Dirk




References:
Strange performance results -- any ideas? Dirk Zimoch

Navigate by Date:
Prev: CSS with a dynamic IOC (=labview?) Touchard Dominique
Next: RE: dbd expand errors for measurementComputing module Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: Strange performance results -- any ideas? Korhonen Timo
Next: Job opening at the SNS Hartman, Steven M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·