g+
g+ Communities
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  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: Re: Strange performance results -- any ideas?
From: John William Sinclair <sinclairjw@ornl.gov>
To: tech-talk@aps.anl.gov
Date: Tue, 19 Jun 2012 14:34:22 -0400
Shown below is a bit of code that will run a bash shell using
real-time scheduling. A program executed from this shell
will thus run with the same real-time scheduling. You will have
to be root else the scheme will fail.

Its not a bad idea to run a second shell from which to kill the 1st if necessary.

#include <stdio.h>
#include <pthread.h>

main() {

int stat;
struct sched_param sched;

  sched.sched_priority = sched_get_priority_max( SCHED_FIFO );

  printf( "\nSwitching to real-time scheduling, priority = %-d\n\n",
   sched.sched_priority );

  stat = sched_setscheduler( 0, SCHED_FIFO, &sched );
  if ( stat ) printf( "Real-time switch failed\n\n" );

  stat = system( "bash" );

  printf( "\nSwitching back to normal scheduling\n\n" );

}



Best,
John Sinclair

On 06/19/2012 01:39 PM, Andrew Johnson wrote:
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


Replies:
Re: Strange performance results -- any ideas? Burkhard Kolb
References:
Strange performance results -- any ideas? Dirk Zimoch
Re: Strange performance results -- any ideas? Till Straumann
Re: Strange performance results -- any ideas? Dirk Zimoch
Re: Strange performance results -- any ideas? Andrew Johnson

Navigate by Date:
Prev: Job opening at the SNS Hartman, Steven M.
Next: Re: Strange performance results -- any ideas? Burkhard Kolb
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: Re: Strange performance results -- any ideas? Andrew Johnson
Next: Re: Strange performance results -- any ideas? Burkhard Kolb
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·