epics/pvDatabase
0
0
Fork 0
Code Issues Pull Requests Projects Wiki Activity

more work on monitor queues

Browse Source
This commit is contained in:
Marty Kraimer
2013-11-12 11:09:25 -05:00
parent 006859120e
commit 3039e1cdb0
8 changed files with 2045 additions and 171 deletions
Download Patch File Download Diff File Expand all files Collapse all files

84
documentation/pvDatabaseCPP.html
View File

@@ -38,7 +38,7 @@
<h1>pvDatabaseCPP</h1>
<!-- Maturity: Working Draft or Request for Comments, or Recommendation, and date. -->
<h2 class="nocount">EPICS v4 Working Group, Working Draft, 04-Sep-2013</h2>
<h2 class="nocount">EPICS v4 Working Group, Working Draft, 12-Nov-2013</h2>
<dl>
<dt>Latest version:</dt>
<dd><a
@@ -46,11 +46,11 @@
</dd>
<dt>This version:</dt>
<dd><a
href= "pvDatabaseCPP_20130904.html">pvDatabaseCPP20130904.html</a>
href= "pvDatabaseCPP_20131112.html">pvDatabaseCPP20131112.html</a>
</dd>
<dt>Previous version:</dt>
<dd><a
href= "pvDatabaseCPP_20130828.html">pvDatabaseCPP20130828.html</a>
href= "pvDatabaseCPP_20130904.html">pvDatabaseCPP20130904.html</a>
</dd>
<dt>Editors:</dt>
<dd>Marty Kraimer, BNL</dd>
@@ -79,12 +79,27 @@ V4 control system programming environment:<br />
<h2 class="nocount">Status of this Document</h2>
<p>This is the 04-Sep-2013 version of of pvDatabaseCPP.</p>
<p><b>NOTE:</b>
This is built against pvDataCPP-md NOT against pvDataCPP.
To build you must also
checkout pvAccessCPP and build it against pvDataCPP-md.
<p>This is the 12-Nov-2013 version of of pvDatabaseCPP.</p>
</p>
<p><b>Problem</b> When arrayPerformance is run with a small array and queueSize 1 it fails.
For example:
<pre>
mrk&gt; bin/linux-x86_64/arrayPerformanceMain arrayPerformance 50 0.00 local 1 1 0.001
arrayPerformance arrayPerformance 50 0 local 1 1 0
...
first 2245711 last 2245711 sum 112285550 elements/sec 0.0452426million changed {1, 2} overrun {}
first 2246087 last 2246087 sum 112304350 elements/sec 0.0451597million changed {1, 2} overrun {}
arrayPerformance value 2246117 time 1 iterations/sec 336447 elements/sec 16.8223million
first 2246448 last 2246448 sum 112322400 elements/sec 0.0450084million changed {1, 2} overrun {}
first 2246827 last 2246827 sum 112341350 elements/sec 0.0446581million changed {1, 2} overrun {}
...
first 2282180 last 2282180 sum 114109000 elements/sec 0.0447461million changed {1, 2} overrun {}
first 2282540 last 2282540 sum 114127000 elements/sec 0.044695million changed {1, 2} overrun {}
Segmentation fault (core dumped)
</pre>
I do not know why and am stuck about what to do.
Looking at SingleElementQueue I do not see any problem.</p>
<p>All channel methods except channelRPC, which is implemented
by pvAccess, have been implemented.
This project is ready for alpha users.
@@ -1597,31 +1612,31 @@ Each has support for <b>-help</b>.</p>
mrk&gt; pwd
/home/hg/pvDatabaseCPP-md
mrk&gt; bin/linux-x86_64/arrayPerformanceMain -help
arrayPerformanceMain recordName size delay providerName nMonitor useQueue
arrayPerformanceMain recordName size delay providerName nMonitor queueSize waitTime
default
arrayPerformance arrayPerformance 50000000 0.001 local 1 false
arrayPerformance arrayPerformance 50000000 0.01 local 1 2 0.0
mrk&gt; bin/linux-x86_64/longArrayMonitorMain -help
longArrayMonitorMain channelName useQueue
longArrayMonitorMain channelName queueSize waitTime
default
longArrayMonitorMain arrayPerformance false
longArrayMonitorMain arrayPerformance 2 0.0
mrk&gt;
</pre>
<h3>Example output</h3>
<pre>
mrk&gt; bin/linux-x86_64/arrayPerformanceMain
arrayPerformance arrayPerformance 50000000 0.01 local 1 false
arrayPerformance arrayPerformance 50000000 0.01 local 1 2 0.0
...
first 0 last 0 sum 0 elements/sec 529.007million changed {1, 2} overrun {}
first 1 last 1 sum 50000000 elements/sec 510.686million changed {1, 2} overrun {}
first 2 last 2 sum 100000000 elements/sec 520.114million changed {1, 2} overrun {}
first 3 last 3 sum 150000000 elements/sec 514.842million changed {1, 2} overrun {}
first 4 last 4 sum 200000000 elements/sec 507.642million changed {1, 2} overrun {}
first 5 last 5 sum 250000000 elements/sec 505.598million changed {1, 2} overrun {}
first 6 last 6 sum 300000000 elements/sec 517.081million changed {1, 2} overrun {}
first 7 last 7 sum 350000000 elements/sec 516.508million changed {1, 2} overrun {}
first 8 last 8 sum 400000000 elements/sec 513.711million changed {1, 2} overrun {}
first 9 last 9 sum 450000000 elements/sec 505.309million changed {1, 2} overrun {}
arrayPerformance value 11 time 1.08257 iterations/sec 10.161 elements/sec 508.049million
first 5 last 5 sum 250000000 elements/sec 51.5164million changed {0} overrun {}
arrayPerformance value 7 time 1.08532 iterations/sec 6.44973 elements/sec 322.487million
first 6 last 6 sum 300000000 elements/sec 493.414million changed {1, 2} overrun {}
first 7 last 7 sum 350000000 elements/sec 172.566million changed {1, 2} overrun {}
first 8 last 8 sum 400000000 elements/sec 515.064million changed {1, 2} overrun {}
first 9 last 9 sum 450000000 elements/sec 515.359million changed {1, 2} overrun {}
arrayPerformance value 11 time 1.10601 iterations/sec 3.6166 elements/sec 180.83million
first 10 last 10 sum 500000000 elements/sec 80.5679million changed {1, 2} overrun {}
first 11 last 11 sum 550000000 elements/sec 499.455million changed {1, 2} overrun {}
first 12 last 12 sum 600000000 elements/sec 504.324million changed {1, 2} overrun {}
first 13 last 13 sum 650000000 elements/sec 101.517million changed {1, 2} overrun {}
...
</pre>
<h3>arrayPerformance</h3>
@@ -1677,10 +1692,12 @@ until the record is destroyed executing the following algorithm:</p>
</dd>
<dt>nMonitor</dt>
<dd>The number of longArrayMonitors to create.</dd>
<dt>useQueue</dt>
<dd>Should the longArrayMonitors use a queue?
This must be <b>true</b> or <b>false</b>.
<dt>queueSize</dt>
<dd>The queueSize for the element queue.
A value less than 1 will become 1.
</dd>
<dt>waitTime</dt>
<dd>The time that longArrayMonitor will sleep after poll returns a monitorElement.</dd>
</dl>
<h3>longArrayMonitor</h3>
<p>This is a pvAccess client that monitors an arrayPerformance record.
@@ -1690,7 +1707,8 @@ is a report.</p>
<p>The arguments for longArrayMonitorMain are:</p>
<dl>
<dt>channelName</dt>
<dt>useQueue</dt>
<dt>queueSize</dt>
<dt>waitTime</dt>
</dl>
<h3>Some results</h3>
<p>The results were from my laptop.
@@ -1713,8 +1731,12 @@ The delay will be a millisecond.
There will be a single monitor and it will connect directly
to the local channelProvider, i. e. it will not use any network
connection.</p>
<p>The report shows that arrayPerformance can perform about 10 iterations per second
and is putting about 500million elements per second.
<p>The report shows that arrayPerformance can perform about 4 iterations per second
and is putting about 200million elements per second.
Since each element is an int64 this means about 1.6gigaBytes per second.
</p>
<p>If queueSize is set to 1 thereport shows that arrayPerformance can perform about 10 iterations
per second and is putting about 500million elements per second.
Since each element is an int64 this means about 4gigaBytes per second.
</p>
<p>When no monitors are requested and a remote longArrayMonitorMain is run:<p>
@@ -1727,7 +1749,7 @@ mrk&gt; bin/linux-x86_64/longArrayMonitorMain
In addition the time between reports varies from just over 1 second to 1.3 seconds.
The reason is contention for transfering data between main memory and local caches.
The next section has an example that demonstrates what happens.
Note that if the array size is small enouggh to fix in the local cache then running longArrayMonitor
Note that if the array size is small enough to fix in the local cache then running longArrayMonitor
has almost no effect of arrayPerforance.
</p>
<h2>Vector Performance</h2>