<!-- Title: 03:26:39  Fri Jun 13 2003 -->
<!-- Crewchief: SVT people -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Page was getting too long


<!-- Date: Fri Jun 13 03:29:29 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-117&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-117' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-118&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-118' width='300'></a></center>
<!-- Author: Stefano -->
<!-- Comment: Fri Jun 13 03;31;11 comment by...Stefano -->
SVT timing distributions from SVTSPYMON, i.e. from GhostBuster board. Left: run 164306. Right: run 164393. Same SVT configuration. Timing distribution is moved to later times in the
second run by about 2 micorseconds. Why ? See next entry.


<!-- Date: Fri Jun 13 03:32:14 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-120&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-120' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-121&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-121' width='300'></a></center>
<!-- Author: Stefano -->
<!-- Comment: Fri Jun 13 03;35;39 comment by...Stefano -->
<pre>SVX readout time for the same two runs from Dave Stuart's
&lt;a href="http://nucsb03.fnal.gov/cgi-bin/readoutocc?RUN=ar027cac.0001"&gt;web page&lt;/a&gt;. Green line is SVX r-phi readout, which deterines when SVT can start processing. In the right plot the green curve moved to the right by 2 microsec, so explaining the
previous SVT timing shift.
&lt;p&gt;
Conclusion: be careful before drawing conclusions from a change
in the position of the SVT timing distribution. </pre>


<!-- Date: Fri Jun 13 10:14:09 2003 -->
Tried to look at SVT timing offline, using GB information on SVDD bank, so that can relate timing distribution to event features. 
Not as easy as I thought
<!-- Author: Stefano -->
<!-- Comment: Fri Jun 13 10;14;31 comment by...Stefano -->
See following entry for explanation


<!-- Date: Fri Jun 13 10:15:22 2003 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-122&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-122' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-123&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-123' width='300'></a></center>
<!-- Author: Stefano -->
<!-- Comment: Fri Jun 13 10;19;15 comment by...Stefano -->
<pre>Left, timing distribution in run 164304 from SVTSPYMON (online).
Right, timing distribution for the same run from SVDD (offline).
Offline I ran on following files:
ar0281d0.0001phys
br0281d0.0001phys
cr0281d0.0001phys
dr0281d0.0001phys
er0281d0.0001phys
gr0281d0.0001phys
jr0281d0.0001phys

Similar, but different.
Left is on all L1 triggers, right on L3 accept, this may
explain something.
But, mostly, what are all those event with GB time below 17microsec ?
</pre>

<!-- Comment: Sat Jun 14 13;13;46 comment by...Bill -->
The GB program that sends its answer to svtspymon checks
only buffer 0 and counts from L1A to EE.  The GB program
that sends its answer to SVDD looks at all buffers and
starts its counter when the GB reads the next L1A from 
its FIFO of L1As.  This happens at the later of (a) L1A
occurs, (b) SVT is done with the previous event.  So the
early times are cases in which SVT's pipelining was
working.  I guess it would be useful also to record the
time from L1A.




<!-- Date: Sat Jun 14 13:18:46 2003 -->
An interesting problem has again reared its ugly head.  In 
run  
<a href=" http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=164727"> 
164727</a>, 
the TrigMon SVT monitoring plots came up empty, and we saw 0  
rate for the semileptonic b triggers and the high-pT b jet 
triggers.  This happens when SVTD is empty or contains no 
end-event word.  It happened Thursday morning, too.  I'll see 
if I can find the run number in a minute. 
Runs 
<a href=" http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=164725">164725</a> and 
<a href=" http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=164729">164729</a> seem to be OK.  I'm trying to see what  
exactly the SVTD banks look like for these runs, and whether the 
problem happens exactly on a run boundary.  
<!-- Author: Bill -->
<!-- Comment: Sat Jun 14 16;26;00 comment by...Stefano -->
Those are L3 triggers, right ? So L2 was OK, but L3 does not
find SVTD bank (nor does trigmon). TrackList board send data
to alpha, but not to event builder... Trigmon should loudly
complain about differences in SVT information in TL2D and SVTD..

<!-- Comment: Sat Jun 14 16;31;11 comment by...Bill -->
Trigmon complains.  And the COs do that the instructions
indicate for SVT: simply send an e-mail to a handful of
SVT experts.  This problem (corrupted or missing SVTD bank)
has been present intermittently
since Thursday morning.


<!-- Date: Sat Jun 14 13:37:43 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-124&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-124  width='300' align='top'></td><td>timing, normal run before Belfo test run</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Sat Jun 14 13:51:29 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-125&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-125  width='300' align='top'></td><td>Belfo test run: useqKillOnBit18 enabled </a></td></tr></table>
<!-- Author: Bill -->
<!-- Comment: Sat Jun 14 13;56;02 comment by...Bill -->
But note that this is before the prescales were adjusted.



<!-- Date: Sat Jun 14 14:14:15 2003 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-126&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-126  width='300' align='top'></td><td>same run, after prescales have updated</a></td></tr></table>
<!-- Author: Bill -->
<!-- Comment: Sat Jun 14 14;16;09 comment by...bill -->
164734

<!-- Comment: Sat Jun 14 16;16;16 comment by...Stefano -->
AMS ucode 3.0 is not enough to kill events. You need to
put in the parameter useqKillOnBit18 and set it to 1.
AMS ucode 3.0 without that is identical to 2.0 other then
the location that stores the microcode version. I suggest
using 3.0 as default.

<!-- Comment: Sat Jun 14 16;20;06 comment by...Stefano -->
<pre>See e.g. SB.mapset in $SVT_CONFIG, the line to add is
w00_useqKillOnbit18 1
and so on for all wedges</pre>

<!-- Comment: Sat Jun 14 16;25;50 comment by...bill -->
I did so.




<!-- Comment: Sat Jun 14 16;26;20 comment by...bill -->
and we are still running v3.0


<!-- Comment: Sat Jun 14 16;26;51 comment by...bill -->
<pre>and the ^#$%%#%# SVTD bank is missing the end-event words
for our test run, so I guess we need to dig through TL2D
to see whether it worked</pre>

<!-- Comment: Sat Jun 14 16;27;58 comment by...stefano -->
i did not see those lines in the mapset for run 164734 from Run Summary DB. Only useq version 3.0


<!-- Comment: Sat Jun 14 16;30;40 comment by...Stefano -->
oooppsss... I must have misstyped the run number, the useqKillOnBit18 are all there... sorry.
Well... we do need SVTD back, I think.



<!-- Comment: Sat Jun 14 22;27;57 comment by...jdl -->
I'd recommend for future timing tests you take a reference run with DPS disabled and then do the test with DPS disabled.  We are most interested in the performance at the highest luminosities, so that would be the most representative.  Also, it it the best way to get a controlled, reproducible test.
<!-- Date: Sat Jun 14 17:23:54 2003 -->
About SVTD getting hosed: I checked stream A look area files for run 164725, and see only the usual SB2W1 disagreement (which 
persists after Steve Nahn's VTM swap).  It seems to be fine. 
I guess trouble starts early in the following run (164727).  
<!-- Author: Bill -->



<!-- Date: Sun Jun 15 13:35:26 2003 -->
 
<font color="#000099">Waiting for the CDF clock back&nbsp; I paste here 
some of the event dump</font> 
<br><font color="#000099">I managed to get..</font><font color="#000099"></font> 
<p><font color="#000099">Event dump for Run 164761 Event&nbsp; 5409299</font> 
<p>P<tt>rinting contents of SVTD, 1</tt> 
<br><tt>**********************************************************</tt> 
<br><tt>Dumping Bank with Bank Name&nbsp;&nbsp;&nbsp; = SVTD</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Number&nbsp; = 1</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Version = 0</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Type&nbsp;&nbsp;&nbsp; = 53I4</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Body Size&nbsp;&nbsp;&nbsp; = 54</tt> 
<br><tt>----------------------------------------------------------</tt> 
<p><tt>Bank Type: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000003</tt> 
<p><tt>Bank Data: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000004 00000006 
00000035 00000035</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4: 00000035 00000035 
00000001 00000003</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8: 0000002f 0affffff 
00000000 00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 24: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 28: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 36: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 40: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 48: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 52: 00000000</tt> 
<br>&nbsp; 
<p><font color="#3333FF">Next, print SVDD (get expected BC from EE word 
at the bottom):</font> 
<p><tt>Printing contents of SVDD, 1</tt> 
<br><tt>**********************************************************</tt> 
<br><tt>Dumping Bank with Bank Name&nbsp;&nbsp;&nbsp; = SVDD</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Number&nbsp; = 1</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Version = 0</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Type&nbsp;&nbsp;&nbsp; = 92I4</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Body Size&nbsp;&nbsp;&nbsp; = 93</tt> 
<br><tt>----------------------------------------------------------</tt> 
<p><tt>Bank Type: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000003</tt> 
<p><tt>Bank Data: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000008 0000000a 
0000000c 0000000e</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4: 00000010 00000012 
00000014 00000024</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8: 0000005c 0000005c 
00000000 00000002</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12: 00000000 00000002 00000000 
00000002</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16: 00000000 00000002 00000000 
00000002</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20: 00000002 00000004 0000000c 
00000010</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 24: 000a00ff f7b8136a f8081388 
f85813a6</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 28: f8a813d8 f8f813ec f95c1414 
42108421</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32: 000b00ff f87f13be 020a00db 
00000001</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 36: 00000003 00000005 00000005 
00000009</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 40: 00000038 000e00ff 000c0000 
01c30136</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44: 00000031 000e00ff 000c0002 
04b4047d</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 48: 0000002b 00137eaa 00017660 
0000011b</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 52: 000b1e8e 001bce3e 00002800 
00200319</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 56: 00136b27 0004fa01 00080157 
000b6e76</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 60: 001aa628 00000000 00200260 
00136da6</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 64: 00002e04 000a0185 000a2298 
001ca208</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 68: 00001800 00200c7b 00136d5a 
0000240c</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 72: 000a0276 0009ee58 0019e278 
00006000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 76: 00200278 00136d65 0004ee06 
000a186a</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 80: 0009ee58 0019e278 00000400 
00200275</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 84: 0014bce9 00010008 00162da1 
000002c8</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 88: 001a72d9 0000969b 00200908 
<font color="#FF0000">00643415</font></tt> 
<br>&nbsp; 
<p><font color="#3333FF">Next, print TL2D(in read what I believe is the 
SVT card):</font> 
<br>&nbsp; 
<p><tt>Printing contents of TL2D, 1</tt> 
<br><tt>**********************************************************</tt> 
<br><tt>Dumping Bank with Bank Name&nbsp;&nbsp;&nbsp; = TL2D</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Number&nbsp; = 1</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Version = 0</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Type&nbsp;&nbsp;&nbsp; = 279I4</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Body Size&nbsp;&nbsp;&nbsp; = 280</tt> 
<br><tt>----------------------------------------------------------</tt> 
<p><tt>Bank Type: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000003</tt> 
<p><tt>Bank Data: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000001 00000003 
00000117 0000000c</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4: 0000000e 00000012 
00000013 00000018</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8: 0000003e 0000004c 
00000065 0000006e</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12: 0000009f 000000a0 00000111 
00000112</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16: 00000113 00000003 0510e111 
000a2002</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20: 41408093 00000000 00000004 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 24: 00000000 00000000 00000000 
00000012</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 28: 000d514c 00000000 00080172 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32: 0009c1bb 00000000 0008f306 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 36: 00098328 00000000 0013c390 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 40: 000913a8 00000000 000bf3c3 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44: 000b73d9 00000000 001303ef 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 48: 000c03f2 00000000 00120486 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 52: 001214a3 00000000 001384f6 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 56: 00127801 00000000 0013282d 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 60: 000c6843 00000000 000d78cf 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 64: 00600015 <font color="#FF0000">00000006 
33037eb2 1190145d</font></tt> 
<br><tt><font color="#FF0000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 68: 
300b6b26 0600013e d0236da5 07b00c0b</font></tt> 
<br><tt><font color="#FF0000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 72: 
20636d5a 07803009 302b6d64 0750033b</font></tt> 
<br><tt><font color="#FF0000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 76: 
8044bce9 10804a40 00643415</font> 0000000c</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 80: 2000001c 80068c01 0001001f 
80070c01</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 84: 20000012 80079001 00000023 
8007a001</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 88: 200b01d6 80085401 000e004d 
80472801</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 92: 200b01d6 80485401 000e0061 
80868c05</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 96: 20070029 8087a002 002e0037 
80862406</tt> 
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100: 206c00ef 8087240c 003b020b 81885405</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 104: 00000002 00003829 00880098 
009000ab</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 108: 00000098 00004055 00450075 
00610064</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 112: 00000070 00000030 00000000 
00001000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 116: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 120: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 124: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 128: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 132: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 136: 00000000 00010000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 140: 00000000 00730c00 00100070 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 144: 00003000 00014000 00001014 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 148: 0cd10010 00014000 00000000 
00004000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 152: 00000000 00000000 00000004 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 156: 00000000 00000000 00000000 
000003ff</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 160: 00000003 00000000 00000000 
00000068</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 164: 00f00000 00000030 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 168: 00f00000 80080632 0200067a 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 172: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 176: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 180: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 184: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 188: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 196: 00000000 00000000 00000000 
00000000</tt> 
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200: 00000000 00000000 00000000 00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 204: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 208: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 212: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 216: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 220: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 224: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 228: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 232: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 236: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 240: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 244: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 248: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 252: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 256: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 260: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 264: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 268: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 272: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 276: 00000000 00000000 00000001</tt> 
<br>&nbsp; 
<p><font color="#3333FF">Summary: TL2D OK, number of tracks in SVTD OK 
but data==0, data in SVDD OK</font> 
<p><font color="#3333FF">Now look at a supposedly good run, there is something 
I&nbsp;do not understand, all the events</font> 
<br><font color="#3333FF">have the same feature, is it like it should be?</font> 
<p><font color="#3333FF">Event dump for Run 164725 Event&nbsp; 1611854</font> 
<br>&nbsp;<tt></tt> 
<p><tt>Printing contents of SVTD, 1</tt> 
<br><tt>**********************************************************</tt> 
<br><tt>Dumping Bank with Bank Name&nbsp;&nbsp;&nbsp; = SVTD</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Number&nbsp; = 1</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Version = 0</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Type&nbsp;&nbsp;&nbsp; = 32I4</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Body Size&nbsp;&nbsp;&nbsp; = 33</tt> 
<br><tt>----------------------------------------------------------</tt><tt></tt> 
<p><tt>Bank Type: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000003</tt><tt></tt> 
<p><tt>Bank Data: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000004 00000006 
00000020 00000020</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4: 00000020 00000020 
00000001 00000003</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8: 0000001a 13828d0f 
ff900322 ff816002&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font color="#FF0000">&lt;&lt; 
What are those (22-31) bits set?</font></tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12: ff82046a ff8906ea ff884e28 
ff802c00&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font color="#FF0000">&lt;&lt; What 
are those (22-31) bits set?</font></tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16: ffa00221 ff910990 ff852a02 
ff885041&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font color="#FF0000">&lt;&lt; What 
are those (22-31) bits set?</font></tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20: ff8a62e8 ff89b800 ff80068e 
ffa00652&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font color="#FF0000">&lt;&lt; What 
are those (22-31) bits set?</font></tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 24: ff936fd1 ff815800 ff8c0874 
ff8ba238&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font color="#FF0000">&lt;&lt; What 
are those (22-31) bits set?</font></tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 28: ff8ae218 ff800000 ffa00293 
ffe4350f&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font color="#FF0000">&lt;&lt; What 
are those (22-31) bits set?</font></tt> 
<br><tt></tt>&nbsp; 
<br><tt></tt>&nbsp;<tt></tt> 
<p><tt>Printing contents of SVDD, 1</tt> 
<br><tt>**********************************************************</tt> 
<br><tt>Dumping Bank with Bank Name&nbsp;&nbsp;&nbsp; = SVDD</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Number&nbsp; = 1</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Version = 0</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Type&nbsp;&nbsp;&nbsp; = 71I4</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Body Size&nbsp;&nbsp;&nbsp; = 72</tt> 
<br><tt>----------------------------------------------------------</tt><tt></tt> 
<p><tt>Bank Type: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000003</tt><tt></tt> 
<p><tt>Bank Data: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000008 0000000a 
0000000c 0000000e</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4: 00000010 00000012 
00000014 00000024</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8: 00000047 00000047 
00000000 00000002</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12: 00000000 00000002 00000000 
00000002</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16: 00000000 00000002 00000000 
00000002</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20: 00000002 00000004 0000000c 
00000010</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 24: 000a00ff f7ae136a f7fe1392 
f84413a6</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 28: f89413d8 f8ee13ec f948140a 
42108421</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32: 000b00ff f87113bf 020300d0 
00000001</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 36: 00000003 00000005 00000005 
00000009</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 40: 00000023 000e00ff 000c0000 
01c90135</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44: 0000005b 000e00ff 000c0002 
04d404b8</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 48: 00000016 00100323 00016002 
0002046a</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 52: 000906ea 00184e28 00002c00 
00200221</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 56: 0011098c 00052a01 00085041 
000a62e8</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 60: 0019b800 0000068e 00200652 
00136fd1</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 64: 00015800 000c0874 000ba238 
001ae218</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 68: 00000000 00200293 0<font color="#FF0000">064340f&nbsp; 
&lt;&lt; EoE&nbsp;word</font></tt> 
<br><tt></tt>&nbsp;<tt></tt> 
<p><tt>Printing contents of TL2D, 1</tt> 
<br><tt>**********************************************************</tt> 
<br><tt>Dumping Bank with Bank Name&nbsp;&nbsp;&nbsp; = TL2D</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Number&nbsp; = 1</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Version = 0</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Bank Type&nbsp;&nbsp;&nbsp; = 181I4</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Body Size&nbsp;&nbsp;&nbsp; = 182</tt> 
<br><tt>----------------------------------------------------------</tt><tt></tt> 
<p><tt>Bank Type: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000003</tt><tt></tt> 
<p><tt>Bank Data: as unsigned int (4-byte words)</tt> 
<br><tt>&nbsp;&nbsp;&nbsp; Index&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3</tt> 
<br><tt>---------&nbsp; -------- -------- -------- --------</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0: 00000001 00000003 
000000b5 0000000c</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4: 0000000e 00000012 
00000013 00000018</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8: 0000002e 00000036 
0000003b 0000003c</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12: 0000003d 0000003e 000000af 
000000b0</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16: 000000b1 00000003 00002000 
00000800</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20: 00101011 00000000 00000004 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 24: 00000000 00000000 00000000 
0000000a</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 28: 0012000c 00000000 000d610c 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 32: 0008b291 00000000 001393d7 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 36: 000d6498 00000000 000846b9 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 40: 001326c4 00000000 0013774f 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 44: 00138750 00000000 0013f866 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 48: 0060010f <font color="#FF0000">00000003 
20100322 02101658</font></tt> 
<br><tt><font color="#FF0000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 52: 
70110990 0520034a 20036fd1 09300056</font></tt> 
<br><tt><font color="#FF0000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 56: 
0064350f</font> 00000002 20000011 80058801</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 60: 00000011 8003c401 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 64: 00000000 00000068 00000200 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 68: 00000000 00000000 00000200 
00000600</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 72: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 76: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 80: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 84: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 88: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 92: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 96: 00000000 00000000 00000000 
00000000</tt><tt></tt> 
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100: 00000000 00000000 00000000 00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 104: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 108: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 112: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 116: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 120: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 124: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 128: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 132: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 136: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 140: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 144: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 148: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 152: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 156: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 160: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 164: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 168: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 172: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 176: 00000000 00000000 00000000 
00000000</tt> 
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 180: 00000000</tt> 
<br><tt></tt>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp; 
<br>&nbsp;
<!-- Author: Marco -->
<!-- Comment: Sun Jun 15 14;31;06 comment by...Jane Nachtman -->
<pre>

To answer the question about why bits 22-31 are F in the good SVTD bank -- the readout is 32 bits, so the upper bits in each word are 1's, and the data as sent to the SVTlist board is in bits 21:0.  

I am not sure how it is possible for the SVTlist board to put 0's on bits 22-31 as you see in the empty SVTD banks, and I think that the board should put out all F's if the EoE word is not seen, but I will check on this.</pre>


<!-- Date: Sun Jun 15 17:51:34 2003 -->
<pre>OK after CDF clock+Level2 get fixed we have a run with SVTD correctly readout (Run 164775). Asked for a new coldstart before Store drop, to see if we are lucky again. This is RUN 164777 and is OK too.</pre>
<!-- Author: Marco  -->


<!-- Date: Sun Jun 15 21:17:01 2003 -->
<p> 
Here we are at the start of a new store, and we still see 
the infamous "missing" SVTD data. 
<p> 
I just tried interchanging the SVTD and L2 merger spigots, 
and the problem did not go away.  So whatever the readout 
board doesn't like, L2 doesn't mind! 
<p>  
<!-- Author: Bill -->
<!-- Comment: Sun Jun 15 21;25;56 comment by...Bill -->
I tried disabling the feature that sets bit 18 in the SVT
end-event word, depending on the L1 trigger bits, to see if
that caused any trouble (it's right next to the buffer number
bits).  No dice.



<!-- Date: Mon Jun 16 01:12:00 2003 -->
Nathan Eddy and I tried a number of things to see if we could 
track down the missing-SVTD-data problem.  (A couple are 
listed above.)   
<p> 
We tried moving the 
GB from slot 14 to slot 6, on the grounds that problems began 
around the time the first GB swap occurred last week, so maybe 
something bad happened to backplane pins.  As it turns out, 
only the P0 and P3 pins are bendable.  The pins on the board 
side looked fine.   
<p> 
When we moved the GB, we did it in the middle of a run, with 
a reboot/shepherd afterward.  The SVTD data briefly reappeared 
after this, but then they vanished again. 
<p> 
We were thinking of bad things like flaky/shorted VME lines, 
but could this just be a software memory overwrite problem? 
That would explain its being fixed by a reboot. 
<p>
<!-- Author: Bill -->


<!-- Date: Mon Jun 16 01:14:14 2003 -->
Nathan Eddy and I tried a number of things to see if we could 
track down the missing-SVTD-data problem.  (A couple are 
listed above.)   
<p> 
We tried moving the 
GB from slot 14 to slot 6, on the grounds that problems began 
around the time the first GB swap occurred last week, so maybe 
something bad happened to backplane pins.  As it turns out, 
only the P0 and P3 pins are bendable.  The pins on the board 
side looked fine.   
<p> 
When we moved the GB, we did it in the middle of a run, with 
a reboot/shepherd afterward.  The SVTD data briefly reappeared 
after this, but then they vanished again. 
<p> 
We were thinking of bad things like flaky/shorted VME lines, 
but could this just be a software memory overwrite problem? 
That would explain its being fixed by a reboot.  It's pretty 
fishy that SVTD has the right length but contains only 0's. 
<p>  
<!-- Author: Bill -->
<!-- Comment: Mon Jun 16 04;15;31 comment by...Stefano -->
Bad VME lines would cause problems aoso in spy bugger readout and cold start. We are also running a new FER version since about the same time the problem occurred.
CAn we reproduce the problem in between stores ? And then
start putting print statements in L2callBack ?
<br> I know I am not much of an help...


<!-- Date: Mon Jun 16 21:23:42 2003 -->
I fixed the SVTD problem.  I'll give details at the SVT meeting. 
Meanwhile, I'm pursuing the grand cleanup of all kinds of  
commissioning kludges whose continued existence limits the 
number of people who can understand SVT's configuration.  
<!-- Author: Bill -->


<!-- Date: Mon Jun 16 21:27:03 2003 -->
Wow!  We can book, configure, and read out the SVT test 
stand crate, tstsvt1 or TEST_SVT_01, using Run_Control 
now!  This provides a great way to develop the readout, 
etc., without waiting for time between stores.  I think 
this is also a decent testbed for getting on-crate 
svtsim integrated with the DAQ.  
<!-- Author: Bill -->
<!-- Comment: Mon Jun 16 21;28;16 comment by...Bill -->
I edited ~vxworks/boot/front-end/startup.svt-teststand to make
tstsvt1 load svtvme from ~ashmansk/svtvme.  Take note, in case
I forget to change it back.



<!-- Comment: Mon Jun 16 23;28;27 comment by...Bill -->
OK, I put it back.
<!-- Comment: Tue Jun 17 03;43;32 comment by...Stefano -->
<pre>I tried to book it from RC about a month ago and got
a bunch or errors. Then my shift was over before I could purusue it more. I'd be interested in knowing what was
needed to make it work.</pre>
<!-- Date: Mon Jun 16 22:32:15 2003 -->
<p> 
Hey!  So I almost have the test stand behaving in a reasonable 
way for a stand-alone DAQ test.  Channel 2 of the GB (which I 
liberated from b0svt06 slot 4, as it is no longer needed there: 
it was the "Bill" GB that got superseded by the "Taka" GB) is 
behaving like the XTRP emulator, writing an EE word each L1A. 
This is making the entire test stand blink in concert with the 
L1A pulse.  The output of the TF is going into channel 1 of the 
GB, from which I intend to read it into the debug bank.  This 
last part isn't working yet.  Actually, the TF output will 
ultimately go through channel 0 of the GB, to be "busted," and 
then into channel 1 for diagnostic readout.  This will be the 
long-awaited unification of Taka's "processor" firmware and my "utility" 
firmware.<p> 
Once this stuff works, I can add some of the other bells and 
whistles to the "utility" program: a timing measurement, a 
2048-word spy buffer, .... 
<p>  
<!-- Author: Bill -->
<!-- Comment: Mon Jun 16 23;30;28 comment by...Bill -->
<p>
Hey, it works!
<p>
I just had to jiggle a few Merger registers, and (for the 
moment) write by hand 'vme tstsvt1 write 20 800004 4' to
get GB channel 2 to ignore its SVT input cable, and then
I had the loop working that I described above!  
<p>


<!-- Date: Wed Jun 18 01:41:37 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=0011, FIFOMT=1111, InpEna=1100, Ena&!MT=0000
Merger b0svt07/11: EEreg=0111, FIFOMT=1001, InpEna=1000, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->



<!-- Date: Fri Jun 20 04:55:21 2003 -->
First attempt at estimating performance of an 
ideal ghostbuster placed before the Trak Fitter: 
Bottom line: from 21 to 8 roads per wedge in average 
(excluding empty wedges). Plots and details in 
Stefano's <a href="http://www.ts.infn.it/~belforte/svt/ana/log.html#June19">log</a>
<!-- Author: Stefano -->
<!-- Comment: Sun Jun 22 09;47;20 comment by...Bill -->
What about the most trivial ghostbusting, where only the first one or two roads entering the TF are memorized, and any subsequent road all of whose superstrips overlap with one of
those roads is rejected?  This may be feasible inside the current TF.  How much difference would one vs two vs N roads
memorized make?

<!-- Comment: Sun Jun 22 17;05;24 comment by...Alberto -->
<pre>With the same algorithm of Stefano I have 18.3 roads without GB and 7.5 with GB.
If I apply the most trivial ghostbusting comparing incoming roads with one road in memory I get 14 roads.
If I compare with 2 roads in memory then I get 12 roads.

All this numbers are relative to the wedge with the maximum number of roads.

I'm surprised that even after the "full GB" the number of tracks after the TF is two times the number of TF's tracks I get with 4/4.</pre>

<!-- Comment: Mon Jun 23 03;22;53 comment by...Stefano -->
<pre>Maybe because with 4/5 roads are twice as large ?</pre>

<!-- Comment: Mon Jun 23 03;27;13 comment by...Stefano -->
About Bill's most trivial algorithn. On average there are
4 roads with 5 hits, if would probably take to store and compare
all of them in order to get a significant suppression of 4-hit ghosts. I would not dismiss the possibility of building 4 ghostbuster boards and inserting them after the HB's.

<!-- Comment: Tue Jun 24 14;21;45 comment by...Bill -->
Mircea says this could be done for roughly $11K in 8-12 weeks.



<!-- Comment: Tue Jun 24 15;30;19 comment by...Stefano -->
If the algorithm can fit, is damn cheap. Question is who is going to try to write it all in verilog/vhdl and fit it. GB has just one
APEX and no external ram's, right ?
<!-- Comment: Wed Jun 25 09;20;05 comment by...Bill -->
One APEX per channel and one FRAM per channel.
<!-- Date: Tue Jun 24 14:56:21 2003 -->
<pre> 
Date: Tue, 17 Jun 2003 11:21:11 -0500 (CDT) 
From: Bill Ashmanskas &lt;ashmansk@cdf.uchicago.edu&gt; 
To: Bill Badgett &lt;badgett@fnal.gov&gt; 
Subject: resetchannel for test_svt_01 
 
Hi, Bill. 
 
I found last night that in order to keep the software event builder happy  
while reading out test_svt_01, I needed either to disable TMPD readout or  
to supply test_svt_01 with a resetchannel number.  For the moment, I chose  
'158' from the list of unused channels.  Perhaps there's a more rigorous  
way to make this assignment? 
 
Cheers, 
Bill 
 
</pre>
<!-- Author: bill -->
<!-- Comment: Tue Jun 24 14;57;02 comment by...bill -->
Bill replied that this was as good a choice as any.



<!-- Comment: Sat Jun 28 22;32;00 comment by...jdl -->
Typically the reset channel is the same as the txpt and rxpt channels.  But there is no reset for the test-stand crates, so it does not matter.
<!-- Date: Tue Jun 24 22:19:05 2003 -->
<p> 
Before run 165207, I rebooted b0svt06,7 to incorporate patch 
to svtvme_fer.c: some stuff that was hard-coded for specific 
crates is now controlled via hwset information.  For example, 
readout from the GB is no longer hard-coded to happen in b0svt07. 
Before run 165208, I moved the readout from b0svt06/12 to 
b0svt07/13 (required hwset update).  I also turned on the 
"paranoid" mode of the SVTD readout, which complains if there 
is no EE word or if the number of words mod 7 isn't 1.  The 
complaint takes the form of an FER message -- can also include 
a done timeout if desired.  (The DTO is currently turned on  
for 'nosvx' but off for normal running, so that if the problem 
happens, it is reported loudly between stores and simply logged 
as a message during stores.) 
<p> 
 
  
<!-- Author: Bill -->


<!-- Date: Tue Jun 24 22:20:15 2003 -->
<pre>Messenger  FER_messenge  7b85628 200 SUSPEND      282aa0  7b85358  3d0004     0 
 
b0svt07-&gt; tt Messenger 
2889e8 vxTaskEntry    +60 : FER_messenger () 
7ae1348 FER_messenger  +2cc: 7abf884 () 
7abf884 FER_smartInitMS+1e04: 7adf904 () 
7adf904 FER_errorSender+2380: MLencodedMessageDestroy () 
7acc7f8 MLencodedMessageDestroy+58 : free () 
25a37c free           +1c : memPartFree () 
259fbc memPartFree    +144: taskSuspend () 
value = 0 = 0x0 
b0svt07-&gt;  
</pre>
<!-- Author: bill -->
<!-- Comment: Tue Jun 24 22;21;36 comment by...Bill -->
Here's what I saw at one point when we were spewing a whole
bunch of FER messages in a test.  Bill Badgett suggested that
I "tt Messenger" and get a stack trace.



<!-- Comment: Wed Jun 25 15;06;16 comment by...bill -->
<pre>Here's another one: this one during cold start.

288a18 vxTaskEntry    +60 : FER_messenger ()
7ae1348 FER_messenger  +2cc: 7abf884 ()
7abf884 FER_smartInitMS+1e04: 7adf904 ()
7adf904 FER_errorSender+2380: MLencodedMessageDestroy ()
7acc7f8 MLencodedMessageDestroy+58 : free ()
25a3ac free           +1c : memPartFree ()
259fec memPartFree    +144: taskSuspend ()
value = 0 = 0x0
b0svt06-&gt; 


</pre>


<!-- Date: Wed Jun 25 15:15:14 2003 -->
I removed the Merger formerly known as "mrg_xtrpcheckbc", 
whose only purpose was to complain when XTRP sent bad BCs. 
This hasn't happened in eons.  Removing this required 
updating the settings on "mrg_xtrpemu" under various 
conditions.  Now XTRP goes straight into input A of 
mrg_xtrpemu, the xtrpemu goes into input B, and the HF 
that feeds fake tracks for L2 testing goes into input C. 
<p> 
Then I moved mrg_xtrpemu from b0svt07.11 to b0svt06.4.  This 
required also moving the card in the hardware database.  Putting 
this card here allows the b0svt06 crate CPU to be aware of all 
data entering or leaving SVT (except the L1 bits). 
<p> 
Soon the "xtrp emulator" Hit Finder will be removed, blue wires 
and all, and replaced with the output half of one GB channel. 
<p>  
<!-- Author: bill -->
<!-- Comment: Wed Jun 25 16;39;30 comment by...bill -->
Some tweaking may be needed the next time you want to use any
hwset other than the one in the database, or "nosvx" or "stephen4".

<!-- Comment: Thu Jun 26 04;32;49 comment by...Stefano -->
Bill, Thanks for that comment about hwset !!

<!-- Comment: Thu Jun 26 04;35;40 comment by...Stefano -->
That HF in b0svt07 that feeds fake tracks is also usefull for XTF-A/B testing  :-)

<!-- Date: Thu Jun 26 10:21:32 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=1111, FIFOMT=0000, InpEna=1111, Ena&!MT=1111
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: f00000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->



<!-- Date: Thu Jun 26 21:07:10 2003 -->
<pre>Hey, now this is pretty cool.  This afternoon, L2 complained 
that SVT had sent no data, and SVT agreed! 
 
 
[ashmansk@b0dap30 ~]$ grep -i svt /cdf/code-common/cdfonline/errmon/log/errorfile165297.log 
(MLE) b0svt06:Messenger:2:02:46 PM-&gt;FER_E_SVT, GB 13.0 nw=0 (mod7=0) ee=ffffff event=507214 
(MLE) b0l2de00:Messenger:2:03:03 PM-&gt;SvtMonitor: No data sent from client, event 507215 
[ashmansk@b0dap30 ~]$  
 
The trick here is that L2 accepts the first couple of bogus 
events it sees (sending them to the error stream), and only 
times out on the third (fourth?) one.  So SVT's Level2-accept 
code can notice the problem and respond!  In this case, it 
sees that the relevant L2 buffer contains no EE word.  We 
should also be able to look at FIFO status registers, etc. 
 
 
</pre>
<!-- Author: Bill -->
<!-- Comment: Thu Jun 26 21;08;05 comment by...bill -->
This morning, SVT was suspected of having sent no data
(Marco and Alex were called to investigate), but SVT
did not report anything fishy.



<!-- Comment: Mon Jun 30 16;16;26 comment by...bill -->
<pre>amazing ...

errorfile165436.log:(MLE) b0svt06:Messenger:7:00:17 AM-&gt;FER_E_SVT, GB 13.0 nw=0 (mod7=0) ee=ffffff event=485654
errorfile165436.log:(MLE) b0l2de00:Messenger:7:00:22 AM-&gt;SvtMonitor: No data sent from client, event 485655
errorfile165436.log:(MLE) b0svt06:Messenger:12:39:14 PM-&gt;FER_E_SVT, GB 13.0 nw=0 (mod7=0) ee=ffffff event=4464572
errorfile165436.log:(MLE) b0l2de00:Messenger:12:39:29 PM-&gt;SvtMonitor: No data sent from client, event 4464573
</pre>
<!-- Date: Thu Jun 26 21:19:10 2003 -->
<pre>There is now a program that fixes up the CRC in a hwset file 
in a more straightforward way: 
 
b0dap30.fnal.gov: ~/svtconf &gt; python $SVTVME_DIR/python/crcfix.py nosvx.hwset 
nosvx.hwset: hwsetCrc 69171091 
rewrote nosvx.hwset (1067 lines) 
1c1 
&lt; hwsetCrc 687562477 
--- 
&gt; hwsetCrc 69171091 
b0dap30.fnal.gov: ~/svtconf &gt;  
</pre>
<!-- Author: bill -->


<!-- Date: Thu Jun 26 22:27:57 2003 -->
Added a spy buffer (including a "timing spy") to GB.  But it's 
still being checked out in the test stand, for now.  
<!-- Author: Bill -->
<!-- Comment: Tue Jul  1 19;51;47 comment by...Bill -->
The GB containing spy buffers is now installed in svt06.slot13.
2048 words of spy data (GB_SPY_B) and 512 words of timing
(GB_TSPY_B).  The same buffers exist for the 3rd channel (C)
as well as B.  The first channel (A) is reserved for Taka's
data-processor, which will be unified with this board soon.




<!-- Date: Tue Jul 1 20:14:16 2003 -->
Cable to L2 now comes from GB.  Once we check that spy buffer 
monitoring works OK from GB, we can remove the Merger from  
b0svt06 slot 12, as it is no longer needed as a splitter.  
<!-- Author: Bill -->


<!-- Date: Fri Jul 18 19:43:17 2003 -->
<p> 
Some time early this morning, SVT started spewing some error messages to FER that imply some sort of contradiction: 
 
<p> 
errorfile166328.log:(MLE) b0svt06:Messenger:6:08:32 PM->FER_E_SVT, GB 13.0 nw=15 (mod7=1) ee=643406 event=1611909 
 
<p> 
It is difficult to understand (a) how these messages could be 
generated at all in the absence of a compiler bug, the loading 
of svtvme code different from that at the head of CVS, or some 
other very subtle problem and (b) why this just started now. 
 
<p> 
The only clue that I see is that b0svt06 was rebooted just before  
midnight on July 17.  When was the previous reboot?  Do we have 
a record? 
 
<p>
<!-- Author: Bill -->


<!-- Date: Fri Jul 18 19:47:59 2003 -->
<p> 
A few days ago, it was discovered by the shift crew that SVT's 
beamline was not being perfectly subtracted.  This was found 
during a very long run.  Marco traced this to spymon's writing 
the beam fit to the GB that is doing the SVTD bank readout, 
rather than the GB that is doing the ghost busting and beam 
subtraction.  This happened because of a miscommunication between 
me and Marco when I was consolidating Ghost Buster boards on 
or around July 1.  Marco told me in what order he wanted me to 
put the boards having the two different functionalities (which 
will soon, I hope, be merged into just a single board), and I  
guess I got the sign wrong.  I checked after the swap that the 
beam fitter ran without complaints, but I did not think of checking that it was writing into the correct board. 
<p> 
I guess this helps to make the point that there is almost always some collateral damage. 
<p>
<!-- Author: Bill -->
<!-- Comment: Sat Jul 19 04;28;42 comment by...Marco -->
<pre>Now that I know that this really started on July 1st, we will go back and mark bad runs where either SVTX or SVTY position as measured by the beam fitter is more than 50 micron away from the value it had at the beginning of the run, since this is the only one that was written to the correct board.</pre>


<!-- Comment: Sat Jul 19 12;16;41 comment by...Bill -->
<p>
There's something I don't understand.  Why doesn't Vladimir's
program report that there is no "up-to-date" beam fit when the
GB is never written except at the start of a run?  The value
loaded at the start of run should be marked "old."  So we 
should have noticed from the daily autoSvtMon job that the GB
was not being updated.  Is there some additional readout of the
beam fit that Vladimir reads, that does not go through the GB?

<!-- Date: Sat Jul 19 04:34:09 2003 -->
I got paged tonight because of a) high trigger rate at the beginning of the store and b) the strange FER error appearing again. <p> 
For a) it was readily found that we got another 150 micron movement in the beam position <p> 
For b) I have manually disabled the paranoid option on b0svt06 crate and created the new default 20030719042208.hwset that will disable this feature permanently until we understand better.
<!-- Author: Marco -->

<!-- Date: Sat Jul 19 09:28:25 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=1111, FIFOMT=0000, InpEna=1111, Ena&!MT=1111
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: f00000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->




<!-- Date: Tue Jul 22 20:35:00 2003 -->
Are youse guys ever going to fix the <a href='http://www-cdfonline.fnal.gov/cgi/ops/cdf_svt/spylist.cgi?0'>browsable histo</a> page?
<!-- Author: Friends of the SVT -->


<!-- Date: Wed Jul 23 17:43:29 2003 -->
<pre>Temporary change in autoSVTMon: 
 
the large errors on Vladimir efficiency were due to the missing 
XFLD bank in stream A: the denominator for the efficiency 
calculation was given by the number of L3 tracks matched with 
XFT L1 tracks; the L1 info was taken from XFLD. 
 
To fix this problem I need few days. In the mean time I have 
temporarily removed the match with L1 tracks. 
So, we expect lower numbers for the SVT efficiency (it is 
affected by XFT inefficiency). 
 
Roberto</pre>
<!-- Author: Roberto -->

<!-- Date: Tue Jul 29 09:15:09 2003 -->
<pre>
 
Merger b0svt07/10: EEreg=1111, FIFOMT=0000, InpEna=1111, Ena&!MT=1111
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: f00000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->



<!-- Date: Tue Jul 29 10:05:41 2003 -->
Please see shift e-log <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=629&frame=2&anchor=09:33:45.702'>entry</a>  
regarding this morning's BC mismatches in wedge 4, costing 
CDF ~30 minutes of high-luminosity beam time.  
<!-- Author: Bill -->


<!-- Date: Tue Jul 29 16:34:40 2003 -->
Today's SVT problem that cost ~0.5/pb of data probably 
deserves a 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=629&frame=2&anchor=14:28:45.596'>link</a> 
<!-- Author: Bill -->


<!-- Date: Wed Jul 30 14:25:24 2003 -->
<pre>autoSVTMon restored: 
 
the efficiency definition is back to the old one, i.e. the 
denominator is given by the match of COT L3 tracks and XFT  
tracks, as it was before july 23. 
 
Notice that the effciency went from 62% to 78%. The difference 
should be due to the XFT inefficiency.</pre>
<!-- Author: Roberto -->


<!-- Date: Fri Aug 1 09:40:46 2003 -->
<center><a href='/elog/notebooks/svt/Fri_Aug__1_2003_093957.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-128' ></a><a href='/elog/notebooks/svt/Fri_Aug__1_2003_094015.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-130' ></a></center>
<!-- Author: Alberto -->
<!-- Comment: Fri Aug  1 09;47;23 comment by...Alberto -->
<pre>The first plot compares 4/4 timing measured from run 164303 with simulated SVT time.
The second one compares 4/5 timing measured from run 164308 with simulated SVT time.

All simulations use data from run 152133, L1_TWO_TRK2_L2_AUTO.
The time is 19+0.3*(max # of combination over wedges)+gaus(0,1) (usec).

The 1us gaussian smearing is added to account for fluctuation from the arrival of last SVX hit or from other sources.
It improves the agreement in the 4/4 plot.
</pre>