Experimental Physics and Industrial Control System

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  <2012>  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

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  <2012>  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024