Dirk Zimoch wrote:
Hi all,
I am testing the performance of array parsing with StreamDevice on a
Linux system. I am reading strings like "3.1415,3.1415,...\n" into a
waveform record with FTVL=DOUBLE. The input is via TCP from localhost.
I found a very strange duration/size relationship:
size 1 duration: 423 time/element: 423.0
size 2 duration: 234 time/element: 117.0
size 4 duration: 229 time/element: 57.2
size 8 duration: 239 time/element: 29.9
size 16 duration: 238 time/element: 14.9
size 32 duration: 259 time/element: 8.1
size 64 duration: 281 time/element: 4.4
size 128 duration: 312 time/element: 2.4
size 256 duration: 397 time/element: 1.6
size 512 duration: 552 time/element: 1.1
size 1024 duration: 40023 time/element: 39.1
size 2048 duration: 41450 time/element: 20.2
size 4096 duration: 41678 time/element: 10.2
size 8192 duration: 5579 time/element: 0.7
size 16384 duration: 10947 time/element: 0.7
size 32768 duration: 21826 time/element: 0.7
size 65536 duration: 43508 time/element: 0.7
size 131072 duration: 77358 time/element: 0.6
size 262144 duration: 138533 time/element: 0.5
size 524288 duration: 275591 time/element: 0.5
size 1048576 duration: 518404 time/element: 0.5
I have now replaced the EPICS IOC by a different receiver that does not
process the data in any way but simply dumps it:
cat < /dev/tcp/localhost/40123 >/dev/null
The server is still almost the same, it just does not expect any replies
any more. Here are the results:
size 1 duration: 26 time/element: 26.0
size 2 duration: 25 time/element: 12.5
size 4 duration: 22 time/element: 5.5
size 8 duration: 20 time/element: 2.5
size 16 duration: 25 time/element: 1.6
size 32 duration: 24 time/element: 0.8
size 64 duration: 31 time/element: 0.5
size 128 duration: 43 time/element: 0.3
size 256 duration: 68 time/element: 0.3
size 512 duration: 118 time/element: 0.2
size 1024 duration: 219 time/element: 0.2
size 2048 duration: 417 time/element: 0.2
size 4096 duration: 791 time/element: 0.2
size 8192 duration: 1550 time/element: 0.2
size 16384 duration: 3381 time/element: 0.2
size 32768 duration: 6747 time/element: 0.2
size 65536 duration: 13327 time/element: 0.2
size 131072 duration: 24354 time/element: 0.2
size 262144 duration: 38822 time/element: 0.1
size 524288 duration: 77327 time/element: 0.1
size 1048576 duration: 154387 time/element: 0.1
So it seems that neither the data server (a Tcl program) nor the TCP
layer is the source of the strange delay.
All times are in 1e-6 seconds. Time is measured on the server. The clock
starts before sending the string and stops after the waveform sends back
an acknowledge.
Protocol: {in "%f"; out "%(NORD)d";}
I understand that for small arrays, the time is dominated by overhead
and stays more or less constant.
But does anyone have an idea why is there this strange performance drop
for sizes between 1024 and 4096 elements?
Dirk
- References:
- Strange performance results -- any ideas? Dirk Zimoch
- Navigate by Date:
- Prev:
CSS with a dynamic IOC (=labview?) Touchard Dominique
- Next:
RE: dbd expand errors for measurementComputing module Mark Rivers
- 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? Korhonen Timo
- Next:
Job opening at the SNS Hartman, Steven M.
- 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
|