<!-- Title: 11:14:23  Sat Feb 26 2005 -->
<!-- Crewchief: Alex -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>A new page is a good idea once in a while...</pre>


<!-- Date: Sat Feb 26 11:22:21 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-296&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-296' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-294&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-294' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-293&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-293' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-295&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-295' width='300'></a></center>
<!-- Author: Alex -->
<!-- Comment: Sat Feb 26 11;51;43 comment by...Alex & AMZ -->
<pre>These four histograms show the timing distribution for
runs 194454 (linear scale), 194455 (linear scale), 194454 (log scale), 194455 (log scale). A longer timing tail and the lack
of the "kill on bit 18" feature seem to point the finger at
us for the L2 problem seen by the pulsar folks. What could
be wrong? I replaced the merger-&gt;HF cable in W00 with the
one allowing to sneak on the lines with the scope, so that
we can keep an eye on the bit 18 line in case this thing shows
up.
</pre>

<!-- Comment: Sun Feb 27 00;05;07 comment by...Roberto -->
<pre>FYI: run 194454 was a Pulsar test at high lum (&gt;1.E32). Run
194455 was a normal run. These plots were discussed in details
yesterday (Friday) at the trigger hardware meeting. No "svt people" other than me were present at the meeting.</pre>


<!-- Date: Tue Mar 1 15:50:29 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-297&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-297  width='300' align='top'></a></td><td>Same plot as previous entry, for run 194625. Now the 
timing is measured parasitically from the output of 
annamaria's bypass. However I am not sure that my 
script is reading that GB channel or the default one 
(which would explain the similarity of the distribution 
with what seen with the standard monitoring). I'll 
add a comment later clarifying this.</td></tr></table>
<!-- Author: Alex -->
<!-- Comment: Tue Mar  1 15;51;00 comment by...Alex -->
<pre>Red and green are before and after the first HRR in the run, respectively.</pre>


<!-- Comment: Wed Mar  2 15;34;24 comment by...Alex -->
<pre>After checking with Taka, we are confident that what we were looking at was the right quantity. So, this seems to rule out
any role of the GB in this occasional timing structure.</pre>
<!-- Comment: Wed Mar  9 16;22;57 comment by...Alex -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Taka revised more carefully the memory maps for the GB. This
reflects in a "bug" in the timing readout script.
Because of this, teh above histograms correspond to the overall 
SVT timing, NOT WHAT STATED ABOVE. The previos comment is FALSE.
The conclusions from this entry are not valid.

</pre></td></tr></td></table>
<!-- Date: Tue Mar 1 16:17:54 2005 -->
<pre>Current status of cabling on b0svt06: 
usually there is a line going from XFTfanout (slot 21/b0svt07) 
to annamaria's bypass merger (slot 14/b0svt06 input A). This 
is what is used for the "fast decision". 
In order to duplicate this line we now send it through a merger 
(slot 12/b0svt06 input D). The second output of this merger 
is parasitically (i.e. hold-disabled) fed to Ghost buster's 
channel 3. This change was done between 194625 and 194631. </pre>
<!-- Author: Alex -->
<!-- Comment: Thu Mar  3 15;52;23 comment by...Alex -->
<pre>This has been superseded. The bypass merger has been removed and placed somewhere else. See later. (slot 21/b0svt07) now goes directly to(slot 21/b0svt07)</pre>
<!-- Date: Tue Mar 1 19:57:37 2005 -->
<pre>Jahred and I this evening tested a new version of svtmon in   
b0svt06.  This new version has the verbose print messages   
suppressable by an environment variable that experts can change   
on the fly during a session on b0svt06.  This change was made  
at the request of Frank Chlebana who noted that printing lots  
of info to terminal is not only useless unless someone is  
actually watching - but could cause the CPU to hang under certain   
circumstances.  The new code behaved as expected.  
 
The new code suppresses all svtmon prints by default.  To  
increase the level of debugging info, one must log into b0svt06 
and issue the command svtLev(XX), where XX=0,1,2...0 is default  
minimal prints, 1 is for more information from the position  
fitter and assorted other sources, 2 is for verbose info from the  
beam width fitter.    
 
The changes were backed out until a new official version of   
svtmon can be built including this new code.  SVT is back in the   
same configuration it was before and is ready for the next store.  </pre>
<!-- Author: neu, adelman -->



<!-- Date: Wed Mar 2 19:54:09 2005 -->
<pre>We updated the SVT online code and downloaded it to the SVT crate. The new code has been tested with fake hits and L2 torture.</pre>
<!-- Author: Alberto & Alex -->



<!-- Date: Thu Mar 3 15:57:11 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-298&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-298  width='300' align='top'></a></td><td>Annamaria was here at the last round of L2 tests 
at the beginning of the store. She managed to collect 
few timing points with the GB timing measurement inserted 
between the XTF output and her bypass merger. This 
is the timing distribution for the events where L2 
sees long latencies from SVT.</td></tr></table>
<!-- Author: Alex & Annamaria -->
<!-- Comment: Wed Mar  9 16;21;02 comment by...Alex -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Due to a bug in the timing readout script this histogram corresponds to the overall SVT timing, NOT WHAT STATED ABOVE</pre></td></tr></td></table>
<!-- Date: Thu Mar 3 16:00:54 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-299&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-299  width='300' align='top'></a></td><td>The Large SVT Processing Time Mistery: run 194625 (pulsar test), difference between bunch counter seen by XFLD and 
by SVT, versus event number. The HRR was done at about event 
22000 (see run summary).</td></tr></table>
<!-- Author: Roberto -->


<!-- Date: Thu Mar 3 16:01:39 2005 -->
<pre>Now that we have this point we feel like we should blame either 
XTF or XTRP. We therefore moved the merger used for the timing 
measurements at the INPUT of XTF, receiving directly the line 
that comes from XTRP (it's a gray cable coming from downstairs). 
XTRP output goes now to (slot 12/b0svt06 input D). Output 1 
has the hold sense enabled and goes where the XTRP output 
was (slot 4/b0svt06 input A), while Output 2 (which has 
the hold sense disabled) goes to the GB board channel 3 
(Slot 6/b0svt06 5th connector from the top). 
At the next chance of observing the timing pathology 
we should read the timing distribution again from 
the GB and see if XTRP sends out something unreasonable 
to XTF.</pre>
<!-- Author: Alex Annamaria Stefano and Roberto -->


<!-- Date: Thu Mar 3 16:03:08 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-301&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-301  width='300' align='top'></a></td><td>Same run (194624), difference between phi measured by SVT 
and measured by XFT (via linker in SVTD), versus event number.</td></tr></table>
<!-- Author: Roberto -->
<!-- Comment: Thu Mar  3 16;03;42 comment by...Alex -->
<pre>Sono arrivato prima io!</pre>

<!-- Comment: Thu Mar  3 17;22;52 comment by...Jahred -->
<pre>Hablo español e inglés, pero no hablo italiano!

Translation: I speak Spanish and English, but I don't speak Italian! =)</pre>


<!-- Date: Fri Mar 4 13:51:22 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-302&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-302  width='300' align='top'></a></td><td>One more for run 194625: phi measured by XFT vs event number. 
It seems to be undefined before the HRR.</td></tr></table>
<!-- Author: Roberto -->


<!-- Date: Fri Mar 4 17:19:03 2005 -->
I have just removed 2 unused Hit Finders from SVT07 and replaced one of them with a Merger in preparation for future SVT tests. 
I'm going to put the two HF into the 3rd floor rack. 
They have serial number 11 and 17.<br> 
 
I marked the two HF's offline in the hardware database. 
The new merger is not yet in the hardware database. 
Everything has been tested with fakehits.
<!-- Author: Alberto -->
<!-- Comment: Fri Mar  4 18;20;30 comment by...Alberto -->
<pre>The new Merger in svt07:slot4 has been configured to fanout SVT hit data for wedge0.
The second output is ready for SVT upgrade vertical slice tests.

The second output of wedge0 MRG (svt00/slot7) has been sent to inputD of MRG in svt07/slot4.
The second output of MRG in svt07/slot4 has been sent back to HB hit input (svt00/slot11).

If it necessary to go back, just directly connect output2 of MRG (svt00/slot7) to HB hit input (svt00/slot11).</pre>
<!-- Date: Fri Mar 4 18:04:25 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-303&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-303  width='300' align='top'></a></td><td>More on run 194625: xft_phi vs event number for svtsim tracks (!!!) </td></tr></table>
<!-- Author: Roberto -->



<!-- Date: Tue Mar 8 09:35:41 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-304&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-304' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-305&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-305' width='300'></a></center>
<!-- Author: Stefano  -->
<!-- Comment: Tue Mar  8 09;38;10 comment by...Stefanoi -->
Today Pulsar guys have done tests. I took timing informations from the GB as set by Alex. Long latency was observed in the run (~300us). From these plots seem that the problem comes from XTRP.


<!-- Date: Tue Mar 8 15:43:21 2005 -->
<pre>Today the "locgically impossible" error from GB appeared again: 
 
(MLE) b0svt06:Messenger:Mar 8, 2005 12:40:10 PM-&gt;FER_E_SVT, GB 6.1 nw=15 (mod7=1) ee=686441 event=563 
 
(MLE) b0svt06:Messenger:Mar 8, 2005 12:40:15 PM-&gt;FER_E_SVT, GB 6.1 nw=15 (mod7=1) ee=60640c 
event=1823  
 
(MLE) b0svt06:Messenger:Mar 8, 2005 12:40:23 PM-&gt;FER_E_SVT, GB 6.1 nw=15 (mod7=1) ee=60677f 
event=3889  
 
(MLE) b0svt06:Messenger:Mar 8, 2005 12:40:23 PM-&gt;FER_E_SVT, GB 6.1 nw=15 (mod7=1) ee=686779 
event=3959  
 
(MLE) b0svt06:Messenger:Mar 8, 2005 12:40:23 PM-&gt;FER_E_SVT, GB 6.1 nw=15 (mod7=1) ee=68673e 
event=3982  
 
(MLE) b0svt06:Messenger:Mar 8, 2005 12:40:30 PM-&gt;FER_E_SVT, GB 6.1 nw=15 (mod7=1) ee=68677f 
event=5773  
 
we try to re-compile the code and we keep to get errors. So W.Badgett compiled svtvme on b0dau36 (SunOS) machine and we copied the library from: 
 
/cdf/code-IRIX-6.5/products/vxworks_generic/v5_3c/target/config/svtvme/svtvme_th.o 
 
to  
 
${SVTVME_DIR}/lib/${SVTVME_DEST_ENV}/${SVTVME_DEST_ARCH}/svtvme_th.o 
 
</pre>
<!-- Author: Stefano T. -->


<!-- Date: Tue Mar 8 20:10:08 2005 -->
We have tested some AM Plugs that either gave problems in the past that were not well understood or caused fuse blown. 
We took away all the plugs from AM01 and put on that 16 "bad" plugs. 10 of them seem to work correctly but tomorrow we will do more intesive tests. We also found a problem in the plug 13:734 that is mounted on the AM05 that is still to be better investigated. So now the spare boards available are the ones in the Pulsar crate (without beam this night it shouldn't be a problem). 
<!-- Author: Barbara & Stefano -->




<!-- Date: Wed Mar 9 16:25:15 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030>The timing readout script has been updated following 
Taka's careful review of the GB register mapping 
into the VME address space. The official script documented 
in <A href=http://www-cdf.fnal.gov/internal/upgrades/daq_trig/trigger/svt/timingScripts.html>this link</A> is now fixed and should work fine. Any timing measurement 
performend with that script in the previous e-log entries 
is in reality a measurement of the overall SVT timing.</td></tr></td></table>
<!-- Author: Alex -->


<!-- Date: Wed Mar 9 17:36:15 2005 -->
<pre>To do list for Stefano: 
 
The cable that normally goes to b0svt06 slot 14 input A is 
disconnected and bypassed through a merger in b0svt07 slot 5. 
Therefore: 
 
- that cable goes to input D b0svt07 slot 5 
- in order to reinstate normal dataflow, a cable is installed 
  between b0svt07 slot 5 output 1 and b0svt06 input A slot 14 
-the timing measurement is performed attaching a cable 
 between b0svt07 slot 5 output 2 and b0svt06 slot 13 
 input of channel 1 (i.e. the third connector from the top) 
 
With the configuration after this change: 
 
b0svt06/6 channel 1 measures the OVERALL SVT TIMING 
b0svt06/6 channel 2 measures the ARRIVAL TIME OF THE XFT INFORMATION TO SVT 
b0svt06/13 channel 2 measures the OUTPUT TIME OF THE SVT BYPASS 
b0svt06/13 channel 1 measures the ARRIVAL TIME OF THE XTF DATA TO THE SVT BYPASS 
 
</pre>
<!-- Author: Alex, Stefano -->
<!-- Comment: Wed Mar  9 17;38;21 comment by...Alex -->
<pre>This assumes that we have a merger in b0svt07 slot 5 which is
not part of RC and which is being configured like the one
in b0svt06 slot 12.</pre>


<!-- Date: Wed Mar 9 19:36:05 2005 -->
<pre>After intensive test, made yesterday and today, of some AM Plugs we can summary that we recover 9 AM Plugs. The following are the numbers of the AM Plug recovered: 
741 
564 
243 
337 
249 
458 
392 
203 
225 
   
The AM01 board is still in use with "BAD" AM Plugs 
</pre>
<!-- Author: Barbara & Stefano -->


<!-- Date: Wed Mar 9 20:59:09 2005 -->
<pre>I've added a new merger in b0svt07 and used it to split the output of XTFA. I've followed the Alex's prescriptions. I had to swap some cable. 
Fake hits look OK and also the L2_TORTURE was fine. 
I'll provide ASAP a better description of the present crate layout.</pre>
<!-- Author: Stefano T. -->


<!-- Date: Thu Mar 10 19:04:35 2005 -->
Today Bill B. made official a new version of the fer code (<a href='/cgi/elog/elog.pl?nb=2005&action=view&page=207&frame=2&anchor=16:51:53.737'> 
see here </a>). <br> 
That version includes support for upgrade SVT++ cards, i.e. calls their coldstart subroutines if they are present in the run configuration and in the crate.
<!-- Author: Alberto -->


<!-- Date: Thu Mar 10 19:47:53 2005 -->
<pre>After intensive test made on AMB01 and AM05 of some AMPlugs we have 15 "good" AMPlugs in the box and the two board are now full of "good" plugs.</pre>
<!-- Author: Barbara & Stefano -->


<!-- Date: Fri Mar 11 00:55:41 2005 -->
<pre>This evening we had pulsar tests w/out silicon. Run with Alpha driving and Pulsar driving have been taken. Before doing the test with the Pulsar alone we lost the beam.  
In none of the runs Long SVT Timing was observed. Below I report the plots from the two runs. </pre>
<!-- Author: Stefano T. -->


<!-- Date: Fri Mar 11 00:59:20 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-306&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-306' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-307&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-307' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-308&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-308' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-309&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-309' width='300'></a></center>
<!-- Author: Stefano T. -->
<!-- Comment: Fri Mar 11 01;00;46 comment by...Stefano T. -->
<pre>Clockwise order: time after XTRP, after XTFA, after ByPass and after SVT</pre>


<!-- Date: Fri Mar 11 01:02:31 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-310&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-310' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-311&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-311' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-312&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-312' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-313&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-313' width='300'></a></center>
<!-- Author: Stefano T. -->
<!-- Comment: Fri Mar 11 01;03;51 comment by...Stefano T. -->
<pre>Clockwise order (or from left to right depending on the resolution :-) ): time after XTRP, after XTFA, after ByPass and after SVT</pre>


<!-- Date: Fri Mar 11 13:39:45 2005 -->
<table><tr><td><a href=/elog/notebooks/svt/Fri_Mar_11_2005_133926.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-315  align='top'></a></td><td>...</td></tr></table>
<!-- Author: Stefano T. -->
<!-- Comment: Fri Mar 11 13;41;21 comment by...Stefano T. -->
<pre>phi XFT used by SVT. Last run before the ByPass: 192073</pre>


<!-- Date: Fri Mar 11 13:43:03 2005 -->
<center><a href='/elog/notebooks/svt/Fri_Mar_11_2005_134210.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-317' ></a><a href='/elog/notebooks/svt/Fri_Mar_11_2005_134229.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-319' ></a><a href='/elog/notebooks/svt/Fri_Mar_11_2005_134244.ps'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-321' ></a></center>
<!-- Author: Stefano T. -->
<!-- Comment: Fri Mar 11 13;46;35 comment by...Stefano T. -->
<pre>Same as previous entry for run (From left to right):  run 192100, run 192100 zoomed, run 192197. With ByPass.</pre>


<!-- Date: Fri Mar 11 18:00:01 2005 -->
The new svt09 crate now receives a copy of hit data from wedge 0. A new cable from MRG in svt07/slot4/output1(<a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=19&frame=2&anchor=17:19:03'>see here</a>) is going to b0svt09. 
It is currently going to MRG in svt09/slot5/inputA. 
However, the destination will be moved from time to time as needed for the test.  
<!-- Author: Alberto -->

<!-- Date: Mon Mar 14 18:21:34 2005 -->
<pre>
 
Merger b0svt07/10: EEreg=0000, FIFOMT=1111, InpEna=0000, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=0001, 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: Mon Mar 14 18:26:46 2005 -->
<pre>
 
Merger b0svt07/10: EEreg=0000, FIFOMT=1111, InpEna=0000, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=0001, 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=1000, InpEna=1111, Ena&!MT=0111
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=1100, FIFOMT=0010, InpEna=1111, Ena&!MT=1101
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=1001, FIFOMT=0100, InpEna=1110, Ena&!MT=1010
 
Ena&!MT summary: 00000000e000000b05
 
</pre>
<!-- Author: svt whodunnit script -->
<!-- Comment: Mon Mar 14 18;50;38 comment by...Stefano, Roberto, Alberto, Taka  -->
<pre> Many L2 Decision Timeouts are happened, and event rates 
are immediately goes to 0. We tried "whodunnit script" 
to check the End of Events in every MRGs.
 It seems that b0svt03 slot7 MRG complains something
according to the result of the script, but not sure
what is going on yet.
 We doubt MRG stop mode due to lostsync, but we released all of
them two years ago already. Swapping MRG board was needed?
</pre>

<!-- Date: Tue Mar 15 08:30:33 2005 -->
<pre>
 
Merger b0svt07/10: EEreg=0000, FIFOMT=1111, InpEna=0000, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=0001, 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: Tue Mar 15 08:31:35 2005 -->
<pre>
 
Merger b0svt07/10: EEreg=0000, FIFOMT=1111, InpEna=0000, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=0001, 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: Tue Mar 15 08:33:07 2005 -->
<pre>
 
Merger b0svt07/10: EEreg=0000, FIFOMT=1111, InpEna=0000, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=0001, 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: Tue Mar 15 08:43:51 2005 -->
<pre>
 
Merger b0svt07/10: EEreg=0000, FIFOMT=1111, InpEna=0000, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=0001, 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: Tue Mar 15 08:56:46 2005 -->
<pre>
 
Merger b0svt07/10: EEreg=0000, FIFOMT=1111, InpEna=0000, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=0001, 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=1000, InpEna=1111, Ena&!MT=0111
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=1100, FIFOMT=0010, InpEna=1111, Ena&!MT=1101
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=1001, FIFOMT=0100, InpEna=1110, Ena&!MT=1010
 
Ena&!MT summary: 00000000e000000b05
 
</pre>
<!-- Author: svt whodunnit script -->



<!-- Date: Fri Mar 18 09:29:29 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-322&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-322' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-323&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-323' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-324&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-324' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-325&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-325' width='300'></a></center>
<!-- Author: Stefano -->
<!-- Comment: Fri Mar 18 09;42;37 comment by...Stefano  -->
<br>
Today we tried to measure the timing. <br> 
These plot come from the run 195413 <br>
The pulsar system now x-check the bunch counter and pull HRR in case of mismatch in 3 subsequent events so even if at the real beginning of the run we observe long latency in these data we shouldn't observe problems. <br>
We have tried to make the measurement also with the alpha disabling the Auto-HRR but the system goes in Time Out. Pulsar people said that they can try to provide a new code in which the bunch counting is not checked.<br>


<!-- Date: Fri Mar 18 09:51:57 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-327&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-327' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-326&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-326' width='300'></a></center>
<!-- Author: Stefano -->
<!-- Comment: Fri Mar 18 09;58;40 comment by...Stefano & Roberto -->
<br>At least we get some useful infos...<br>
This is the last run (195415) with the alpha driving and the Auto-HRR disabled, it lasted 3 minutes and we had to end the run because of the end of the store.<br>
The first plot is the overall SVT timing while the second one is the timing from XTRP before XTFA (we had no time to measure the other timings)<br>
Two conlcusions:<br>
1) We can do this test by just disabling Auto-HRR in a normal run <br>
2) The long latency time should be after the XTFA <br>

<!-- Comment: Fri Mar 18 13;50;43 comment by...Alex -->
<pre>In principle you could perform the timing measurements in parallel,
you don't need to do them sequentially: just launch the timing
readout script in parallel on separate terminals and cross
your fingers!</pre>

<!-- Comment: Fri Mar 18 15;31;59 comment by...Roberto -->
<pre>the reason we did not perform all the timing measurements was that we did not have enough time, the run ended after only three minutes and they dropped the store.
Meybe next time...</pre>


<!-- Date: Thu Mar 24 12:51:14 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-328&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-328' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-329&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-329' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-330&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-330' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-331&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-331' width='300'></a></center>
<!-- Author: Stefano -->
<!-- Comment: Thu Mar 24 12;59;03 comment by...Stefano -->
<pre>Today we have the chance to measure the timing while observing the LL. The run were 195689 (first plot is the SVT timing for that run) and 195690. The second plot is the timing for XTFA (no evidence of long latency). The 3th and 4th are the timings after the BYPASS and  the output of SVT (I made this just to check that we were looking at the right infos).

So it seems that the problem appear for the first time after the BYPASS while XTFA (and so XTRP) looks fine.</pre>


<!-- Date: Fri Mar 25 14:20:52 2005 -->
<pre>Now SVT is set in the std. configuration w/out cables and mergers for the timing measurement. In Fake Hits run everything looks fine.</pre>
<!-- Author: Stefano -->


<!-- Date: Sat Mar 26 15:52:31 2005 -->
<pre>Run 195746 is taken without fast abort, to check the standard 
configuration for crate 6. Data look ok. No HRR at the beginning 
of the run.</pre>
<!-- Author: Roberto -->


<!-- Date: Mon Mar 28 10:18:05 2005 -->
<pre>last Friday I moved one HB spare from the 3rd floor and the only TF spare from the teststand to b0svt09 crate. 
Please be aware that if you need the TF spare you have to look there!</pre>
<!-- Author: Alberto -->
<!-- Comment: Wed Mar 30 14;58;54 comment by...Jahred -->
<pre>I upgraded the cntrl firmware of the spare TF (IDPROM #7) with the latest firmware - should do negative phi correction and LC cut correctly now.</pre>
<!-- Date: Wed Mar 30 10:14:33 2005 -->
<pre>Bill checked the svt09 tracer configuration (that was bad). 
He found that there was a clk problem that was solved by getting the TS input from a different channel in crate 2RR29C bottom. This is a temporary patch, until the correct channel will be fixed. 
 
Paolo is now checking with fake hits that everything is ok, including the hardware bypass of the fast abort by RC and ST. 
 
 </pre>
<!-- Author: Alberto, Paolo, Roberto & Stefano -->


<!-- Date: Wed Mar 30 10:24:47 2005 -->
<pre>Roberto and I labeled the GB connectors, for both GB boards in svt06, as: 
input 0, out 0 
input 1, out 1 
input 2, out 2</pre>
<!-- Author: Alberto & Roberto -->



<!-- Date: Wed Mar 30 17:16:41 2005 -->
<pre>This is a summary of what we know about the Bunch Counter mismatch problems: 
 
                           Problem (1)       Problem (2) 
                           -----------       ----------- 
 
Can be fixed 
by HRR                      yes               no 
 
 
SVT find good 
tracks (chi2, d-phi 
correlation, beam 
pos.)                       yes               yes 
 
 
SVT tracks match 
L3 tracks                   no                yes 
 
 
SVT efficiency              0%                80% 
 
Amount of the BC 
mismatch (TFRD-SVT)         any value         +-2 
 
svtsim reproduces 
data                        no                yes 
 
svtsim BC (SVTD) in 
agreement with XFLD         yes               yes 
 
 
 
Example runs               194625            195267 
                           (first 22k 
                           events) 
 
 
We have decided to run without fast abort for a week starting 
from today in order to check if we still have bc mismatches. 
The fast abort is bypassed in the hwset. This is what we changed: 
 
mrg_bypass_MRG_ERR_EN from 105 to 104 
 
mrg_bypass_MRG_INPAENA from 1 to 0 
 
mrg_splitxtfb_MRG_HOLDENA1 form 1 to 0 
 
The fast abort is also bypassed physically: the cable in crate 6 that usually goes to mrg, slot 14, output 1, now goes to mrg  
slot 20, output 2 (the old cable from slot 14 to slot 20 out 2  
is now  floating). 
 
During this week we hope to have more tools available (e.g.  
spydumps for mrg sl. 14).</pre>
<!-- Author: Roberto -->
<!-- Comment: Wed Mar 30 20;26;42 comment by...Roberto -->
<pre>Problem (1) is the one with long SVT processing time.</pre>


<!-- Date: Thu Mar 31 21:58:24 2005 -->
<pre>I made a new release of svtvme called v2_9. 
This version contains the head of the repository which includes only the very first changes for the upgrade. 
Eventually this version will be loaded in the crates instead of the developmnet. 
In this moment those two version are identical. 
</pre>
<!-- Author: Alberto -->


<!-- Date: Fri Apr 1 16:27:46 2005 -->
<pre>Here is the e-log (main shift) ROberto and I made regarding L2DTOs for today's run (in case you are interested): 
 
============================================= 
 
Start of Shift Notes:   
 
Running, store #4072 Lumi 28E30. Plan is to take data all shift. 
 
Fri Apr 1 08:34:08 
 
L2 TO 
 
 - Cristobal :: (run 196045) 
-- Fri Apr 1 08:37:24 comment by...Cristobal --  again 
-- Fri Apr 1 09:04:28 comment by...Cristobal --  again 
-- Fri Apr 1 09:39:09 comment by...Cristobal --  again 
-- Fri Apr 1 10:25:21 comment by...Cristobal --  again 
-- Fri Apr 1 11:19:10 comment by...Cristobal --  again 
-- Fri Apr 1 11:44:56 comment by...Cristobal --  again 
-- Fri Apr 1 12:09:51 comment by...Cristobal --  again 
-- Fri Apr 1 13:04:08 comment by...Cristobal --  again 
-- Fri Apr 1 13:32:59 comment by...Cristobal --  again 
-- Fri Apr 1 13:35:08 comment by...Cristobal --  again 
-- Fri Apr 1 13:47:15 comment by...Cristobal --  again 
-- Fri Apr 1 14:34:18 comment by...Ted --   
 
we are taking data with Pulsar driving and alpha in auto-reject mode. L2DTOs can be pulled by either system. From Run Summary error log files, there are a few types of errors reported from Alpha side (attached below, a few examples). On Pulsar error log 
file, we haven't seen any similar errors reported.  
 
 
(MLE) b0l2de00:SpyAlpha:Apr 1, 2005 6:05:35 AM-&gt; 
L2receive: SVT buffno 0 != event buffno 2 
SVT BC: 0, XTRP BC: 15 
 
 
(MLE) b0l2de00:SpyAlpha:Apr 1, 2005 6:36:09 AM-&gt; 
L2receive: bad L1 Magic Bus word 0x039700004030081c1000000000000000 
 
 
(MLE) b0l2de00:SpyAlpha:Apr 1, 2005 6:47:09 AM-&gt; 
SvtMonitor: saw 3 sequential errors (12 total) 
 
 
 
(MLE) b0l2de00:SpyAlpha:Apr 1, 2005 6:53:55 AM-&gt; 
L2receive: CList pass 0, cluster 0: 3 != 2 
 
(MLE) b0l2de00:SpyAlpha:Apr 1, 2005 6:53:56 AM-&gt; 
Bad data: resetting FIFOs 
 
(MLE) b0l2de00:SpyAlpha:Apr 1, 2005 6:53:56 AM-&gt; 
ClistMonitor: saw 3 sequential errors (9 total) 
 
 
 
 
(MLE) b0l2de00:SpyAlpha:Apr 1, 2005 7:42:13 AM-&gt; 
L2receive: SVT buffno 2 != event buffno 3 
SVT BC: 24, XTRP BC: 6 
 
(MLE) b0l2de00:SpyAlpha:Apr 1, 2005 7:42:13 AM-&gt; 
SvtMonitor: saw 3 sequential errors (21 total) 
 
(MLE) b0dap73.fnal.gov:Thread-1111:Apr 1, 2005 7:40:57 AM-&gt;  Level 2 Decision Timeout 
 
 
 
-- Fri Apr 1 14:43:43 comment by...Ted and Roberto --   
 
Roberto just checked the TrigMon SVT BC and Buffer mismatch 
plots, and he sees none. Since Pulsar is driving, the TrigMon 
uses Pulsar TL2D, so this is another confirmation that the actual 
SVT data looks fine (i.e. this is consistent with the fact that 
we do not see any errors reported on Pulsar error log file). 
The SVT/XTRP buffer mismatch and other errors reported by alpha must be caused by something inside alpha crate, rather than SVT system or other subsystem upstream (otherwise, Pulsar would complain).</pre>
<!-- Author: Ted -->