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: Andrew Johnson <anj@aps.anl.gov>
To: tech-talk@aps.anl.gov
Date: Tue, 19 Jun 2012 12:39:00 -0500
Hi Dirk,

On 2012-06-19 Dirk Zimoch wrote:
> 
> When I change from DOUBLE to FLOAT arrays, nothing changes.

Ok, so the issue is related to the TCP socket communications side, not the 
conversion or storage into the waveform.

> Making the CPU really busy does not change anything. It neither changes
> the location of the breaks nor the time/element for anything > 16.
> 
> When I make the string longer, the break moves up.
> "3,..."
> size    1024     duration:     1169     time/element:    1.1
> size    2048     duration:     2116     time/element:    1.0
> size    4096     duration:    43596     time/element:   10.6
> size    8192     duration:    47498     time/element:    5.8
> size   16384     duration:    53602     time/element:    3.3
> size   32768     duration:    30096     time/element:    0.9
...
> "3.14159265359,..."
> size     256     duration:      677     time/element:    2.6
> size     512     duration:    40791     time/element:   79.7
> size    1024     duration:    41654     time/element:   40.7
> size    2048     duration:    42928     time/element:   21.0
> size    4096     duration:     7013     time/element:    1.7
> 
> Server and IOC run on the same PC. When I change from localhost to the
> IP address, nothing changes. To use other mechanisms than TCP will take
> some time to implement....

That implies that it's to do with sending the data over the TCP socket.  I'd 
say that at some point during the transmission the OS decides that the server 
process has filled its transmit queue enough and it switches to the IOC 
process to read some data out of the socket.  Once that happens before the 
server has queued up all of its data the OS has introduced 2 extra context 
switches into the operation, the scheduler might be making one or both 
processes wait a whole time-slice before they get to run again, so 20ms each 
might be reasonable for that.

The interesting thing is that going all the way up to 1 million elements 
doesn't trigger a second bump.  Maybe you could try adding spaces as well to 
see if there is another bump without increasing the number of elements

Also you could try making the server run as a real-time process.  I'm not sure 
how to actually do that, but I think it might help.

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte

Replies:
Re: Strange performance results -- any ideas? John William Sinclair
References:
Strange performance results -- any ideas? Dirk Zimoch
Re: Strange performance results -- any ideas? Till Straumann
Re: Strange performance results -- any ideas? Dirk Zimoch

Navigate by Date:
Prev: Re: Strange performance results -- any ideas? Dirk Zimoch
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 
Navigate by Thread:
Prev: Re: Strange performance results -- any ideas? Dirk Zimoch
Next: Re: Strange performance results -- any ideas? John William Sinclair
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 ·