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