Subject: |
Re: Strange performance results -- any ideas? |
From: |
Burkhard Kolb <[email protected]> |
To: |
tech-talk Mailing List <[email protected]> |
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
<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
|