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: Burkhard Kolb <b.kolb@gsi.de>
To: tech-talk Mailing List <tech-talk@aps.anl.gov>
Date: Wed, 20 Jun 2012 08:48:21 +0200
Hi Dirk, 
did you try to run the loop backwards, to see if that has to do with the
memory allocation in the TCP stack?

Burkhard
--
Dr. Burkhard Kolb
Tel +49 6159 712667
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1 | D-64291 Darmstadt | www.gsi.de

Gesellschaft mit beschränkter Haftung
Sitz der Gesellschaft: Darmstadt
Handelsregister: Amtsgericht Darmstadt, HRB 1528

Geschäftsführung: Professor Dr. Dr. h.c. Horst Stöcker, Peter Hassenbach, Dr. Hartmut Eickhoff
Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph
Stellvertreter: Ministerialdirigent Dr. Rolf Bernhard




Am 19.06.2012 um 20:34 schrieb John William Sinclair:

> 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
> 



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
Re: Strange performance results -- any ideas? John William Sinclair

Navigate by Date:
Prev: Re: Strange performance results -- any ideas? John William Sinclair
Next: RE: BOY XY graph tick marks [SEC=UNCLASSIFIED] Chen, Xihui
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? John William Sinclair
Next: Re: Strange performance results -- any ideas? Matthieu Bec
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 ·