<!-- Title: 07:10:34  Tue Sep 11 2007 -->
<!-- Crewchief: Stefano -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Shutdown</pre>


<!-- Date: Thu Oct 11 11:48:02 2007 -->
<pre>We made a new SVTVME release v5_0 for SL4. It will be loaded by default by SVT crates. We still have to reboot the crates.</pre>
<!-- Author: ALberto, Massimo, and Laura -->
<!-- Comment: Thu Oct 11 20;07;14 comment by...Massimo -->
<pre>Crates have been rebooted. </pre>
<!-- Date: Thu Oct 11 11:57:31 2007 -->
<pre>On October 5 I was paged for the usual TF++ memory error occurring to b0svt08 at config. The board responsible for that was TF++ #3187. I power-cycled the crate. 
 
(MLE) b0svt08:Messenger:Oct 5, 2007 06:14:51 PM-&gt;FER_E_SVT, (info) hc=2478488567 mc=144980087  
(MLE) b0svt08:Messenger:Oct 5, 2007 06:14:51 PM-&gt;FER_E_SVT, writeMap(tf_w02/TF++ssx0_1): 
checkMemoryFragment   
(MLE) b0svt08:Messenger:Oct 5, 2007 06:14:51 PM-&gt;FER_E_SVT, mismatch (nerr=57812)  
(MLE) b0svt08:Messenger:Oct 5, 2007 06:14:51 PM-&gt;FER_E_SVT, writeMap(tf_w02/TF++ssx0_1): 
checkMemoryFragment   
(MLE) b0svt08:Messenger:Oct 5, 2007 06:14:51 PM-&gt;FER_E_SVT, mismatch (nerr=57084)  
(MLE) b0svt08:Messenger:Oct 5, 2007 06:14:51 PM-&gt;FER_E_SVT, TFPP (slot 9) SSmap_1 write failed twice 
(MLE) b0svt08:Messenger:Oct 5, 2007 06:14:51 PM-&gt;Setup failed with error code 1  
(MLE) b0svt08:Messenger:Oct 5, 2007 06:14:51 PM-&gt;Statechange failed  
(MLE) b0svt06:Messenger:Oct 5, 2007 06:15:06 PM-&gt;FER_E_SVT, (info) hc=2478488567 mc=144980087 </pre>
<!-- Author: Massimo -->



<!-- Date: Mon Oct 29 21:10:51 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-391&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-391  width='300' align='top'></a></td><td>beam position before shutdown</td></tr></table>
<!-- Author: diruzza -->


<!-- Date: Mon Oct 29 21:28:38 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-392&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-392  width='300' align='top'></a></td><td>plot beam monitor run 252901 (post shutdown)</td></tr></table>
<!-- Author: Benedetto & nicolo -->


<!-- Date: Mon Oct 29 21:53:26 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-393&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-393  width='300' align='top'></a></td><td>again with the fit prameters too</td></tr></table>
<!-- Author: nicolo & benedetto -->


<!-- Date: Fri Nov 2 01:49:06 2007 -->
<pre>We load the new patterns and constants for SVT for the present position of the beam (x=-0.176, y=0.024, dx/dz=0.000400, dy/dz=-0.000300); Svt fit the beam, coverage and track parameters look good..</pre>
<!-- Author: Stefano and Laura -->


<!-- Date: Mon Nov 5 19:51:51 2007 -->
<pre>How to switch back to the previous release of SPyMon: 
- log as cdfprod on online machine (ksu cdfprod) 
- cd /cdf/onln/code/cdfprod/svtmon 
- two links:  devel -&gt; default for consumer (-d option) 
                   current -&gt; for crate 
- rm devel 
- ln -s /cdf/onln/code/cdfprod/svtmon/svtmon/v5_1 devel 
- rm current 
-  ln -s /cdf/onln/code/cdfprod/svtmon/svtmon/v5_1 current 
 
- Go to https://www-cdfonline.fnal.gov/internal/ops/svt/spymon instructions_expert.html and follow the instructions,  
-&gt; kill the process 
- move /cdf/onln/data/cdf_svt/svtest/spymon/*root 
-&gt; restart the process using "svtspymon tree" 
-&gt; reboot all the crates</pre>
<!-- Author: Benedetto 4 Laura -->


<!-- Date: Tue Nov 6 13:22:46 2007 -->
<pre>&lt;ul&gt; 
&lt;li&gt; we tested the HB spare and it didn't work - we need to prepare a new spare 
&lt;li&gt; we made "current" the development version of svtvme and tested everything with fake hits 
&lt;/ul&gt;</pre>
<!-- Author: Laura and Stefano -->


<!-- Date: Mon Nov 12 15:30:21 2007 -->
<pre>We reloaded the patterns, which were generated on 20070704 for a beam position closer to the current one.</pre>
<!-- Author: Massimo, La -->


<!-- Date: Mon Dec 3 08:16:27 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-394&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-394' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-395&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-395' width='300'></a></center>
<!-- Author: Benedetto -->
<!-- Comment: Mon Dec  3 08;17;52 comment by...benedetto -->
<pre>Beam position 11/27 - 12/03</pre>


<!-- Date: Mon Dec 3 08:20:16 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-396&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-396' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-397&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-397' width='300'></a></center>
<!-- Author: Benedetto -->
<!-- Comment: Mon Dec  3 08;21;11 comment by...benedetto -->
<pre>slope 11/27 - 12/03</pre>


<!-- Date: Tue Dec 4 14:57:42 2007 -->
</br>We had seen relatively higher error rate(~0.4% : limit is 0.2%) from wedge03 since a few days ago and since TrigMon table becomes red due to this problem, shift crew were complaining. And so here is a summary on what we have done. </br></br> 
 
 
First we have ran vslice for TF of w03 (svt09 slot11). </br> 
Then we didn't see any problem on TF++.</br> 
</br> 
Then we move to vslice on the crate svt01 and got the following  
error even after powercylcing the crate. (of course before as well.) </br> 
===============================================</br> 
HB: lastEE=60162c </br> 
Roads: lastEE=60162c </br> 
Hits: lastEE=60172c </br> 
Dumped 265 events in CUTroads and HBout </br> 
Starting Simulation </br> 
ERROR: RW layer map does not match observed layer map! RW layer map: 000037, addr=074e8f, observed layer map:   0  </br> 
python: </br> /cdf/onln/code/cdfprod/svtvme/development/src/svtsim_hb.c:390: svtsim_hb_procEvent1: Assertion `0' failed. </br> 
Abort</br> 
================================================= </br> 
</br> 
We have checked the other crates and no error was found. </br> 
Then it turned out that we have one HB spare that Laura pointed out and 
she said it "should" work :) Then after swapping the board, error went away ! </br> 
Bad one is "91" and the one we put in is "83" sitting in svt01. 
Laura takes care of the bad HB++ board and should follow what's happening. 
</br> 
So the conclusion now is that we were having a problem on HB which we don't 
know the cause exactly (need expert's investigation), but now everything should run normally. </br> 
- But in fact we need to prepare for spares since we don't have it any more..... </br>  
<!-- Author: Kohei/Jahred/Massimo/Laura -->
<!-- Comment: Tue Dec  4 15;24;44 comment by...Kohei/Laura -->
<pre>Ivan pointed out if we just have a problem on the mezzanine on the
board. So we tried to put the bad one (91) back in and tested it by vslice. And this time we didn't see any erorrs. So we leave it to svt01 and now we have one spare board (91) which is good.</pre>


<!-- Date: Mon Dec 10 12:22:08 2007 -->
<pre>Just as reference: during a slow HRR operation we gat this message in /cdf/onln/data/cdfdaq/rcLog/rtserver/:rtserver_check_2007-10-27-19:30.log 
 
"&lt; tcp        0   1984 b0server04.fnal.gov:5101    b0svt09.fnal.gov:1084       ESTABLISHED  
--- 
&gt; tcp        0    992 b0server04.fnal.gov:5101    b0svt09.fnal.gov:1084       ESTABLISHED  
Last RTworks Error Code: 1 
Last C Error Code: 16 
Last OS Error Code: 16 
Last Socket Error Code: 16 
Sun Dec  9 03:57:38 2007: Accept connection on fd 177 from b0svt08.fnal.gov 
Sun Dec  9 03:57:38 2007: Closing connection on fd 177 from b0svt08.fnal.gov 
TAL-SS-05250-W Internal validation &lt;T_TRUE == status&gt; failed, file: utthread.c, line 2277 
TAL-SS-05251-W Please report this to Talarian Corporation Technical Support. 
Last RTworks Error Code: 1 
Last C Error Code: 16 
Last OS Error Code: 16 
Last Socket Error Code: 16" 
 
Which is the same error we received today with cratew svt01. For this crate the solution was starting a new run. 
Maybe is the usual message when a crate is very slow... 
 
 
 
</pre>
<!-- Author: Kohei/Laura -->
<!-- Comment: Tue Dec 18 12;20;25 comment by...Laura -->
<pre>I forgot to write what happened later:
1. It has been discovered that the previous message (Accept connection, closing connection) was also reported for crates very slow during HRR transition (svt09, svt08, but sometimes also other random svt crates...).
2. During a DAQ meeting the RTserver experts explained us this is the usual behaviour when RTServer is receiving too much data (more than the data buffer size). 
3. Marco and Benedetto reduced by factor of 2 the frequency of SVTMon data sent to the RTserver.
4. Nobody is anymore complaining about slow HRR transitions, but, on the other hand, nobody told us if we fixed the problem...
(To be continued..)</pre>
<!-- Comment: Tue Dec 18 16;33;26 comment by...Laura -->
<pre>DAQ experts told me the problem of slow svt crates has been fixed.</pre>
<!-- Date: Tue Dec 11 16:13:32 2007 -->
<pre>Today b0svt04 got stucked (while we were running smoothly). Reshepherd didn't work, we tried to shutdown the crate (using the shutdown software command), but the crate was completely frozen, so we decided to power cycle it. 
Once we did, the SPYMON task was not running (we could't check that before, because we could't connect to the crate). So, we try svtStart command, but the crate started to complain about the missing connection to RTserver. We tried several times, then we decided to page DAQ. DAQ restarted the RTserver, rebooted the crate and finally we were able to run smoothly. 
 
 </pre>
<!-- Author: Massimo -->


<!-- Date: Tue Dec 18 11:53:17 2007 -->
<h3>SVTsim saga</h3> 
On Friday 14 the shift crew noticed that the TrigMon crash rate, which had always been marking regularly the data taking with the precison of CDF clock, was increased to a crash every O(100) events. Koji and Pasha debugged TrigMon and found that the crash was occurring at line 210 of svtsim_hb.cc (<a href="http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=soft-releases&action=view&page=23&frame=2&anchor=19:11:07">ref</a>). A deeper investigation by Laura and Heather tracked the problem down in the TL2D format, which had recently been changed: bits 21 and 22 of the track words, historically EP and EE, were reassigned to account for CMP matching. </br> 
SVTsim was temporarily disabled. Yesterday the correct TL2D format was restored and SVTsim switched on again. Runs 255141-255194 were flagged bad for SVT.
<!-- Author: Massimo -->


<!-- Date: Tue Dec 18 12:06:28 2007 -->
<pre>SVT Done TO. 
 
From the beginning of November we had a significant number of Done Timeouts for svt crates. According with the shift e-log (so I guess the number it's understimated) I report below, the number of Done TOs for each crate: 
- svt09: 24 
- svt00: 16 
- svt04: 13 
- svt02, svt08, svt03, svt07: 4 
- svt01, svt06: 1 
</pre>
<!-- Author: Laura -->




<!-- Date: Mon Dec 31 10:36:03 2007 -->
<pre>SpyMon. 
Today they paged me because PsyMon missing task on svt09. I simply connect to the crate and restart SpyMon. I think it could be useful keep running even if SPyMon task is missing... 
</pre>
<!-- Author: Laura -->


<!-- Date: Tue Jan 1 19:05:49 2008 -->
<pre>Got paged the last day of the year because SVT occupancy had a new empty wedge. As suggested by the "SVT faq list" I've simply suggested to contact SVT folks. At the beggining they thought it was just a metter of statistics too low. Looking at the silicon e-log the studies they did at the beginning of the beam looked OK and also the main pager from home could't see this missing wedge. It turns out the ladder was masked off in the hardware database.  
In any case was bread for silicon folks.</pre>
<!-- Author: Laura -->


<!-- Date: Sun Jan 6 20:27:54 2008 -->
I was paged because SVT SPY Monitor was red in ProcMon. It turned out that spy_manager was not running on b0server02. I restarted it, but it was crashing again after a couple of minutes with the error message: 
<pre> 
ACNET interface - XML-RPC Fault: HTTP error #-1 occurred 
Fatal Error: connect operation failed (Connection timed out) (-504) 
</pre> 
I performed a search on the e-log and discovered that this problem has been occurring in the past with a frequency of once per year, but I didn't find any clue for the solution. <br> 
At the end, the problem disappeared by itself: I simply kept trying to launch spy_manager and finally it was able to open a connection with ACNET and started properly.
<!-- Author: Massimo -->
<!-- Comment: Tue Jan  8 11;53;33 comment by...Massimo -->
For sake of completeness and future reference: Marco confirmed that in general such communication problems are due to the ACNET server at Beam Division.


<!-- Date: Wed Jan 9 10:46:42 2008 -->
<h4>New beam position</h4> 
Before store 5835 the beamline was moved to reduce the y-z tilt. The new beam position is: 
<pre> 
x     = -0.1303 cm  ( -0.0143 w.r.t. SVX ) 
y     =  0.0907 cm  ( -0.0529 w.r.t. SVX ) 
dz/dx =  0.510 mrad (   0.093 w.r.t. SVX ) 
dz/dy = -0.086 mrad (   0.104 w.r.t. SVX ) 
</pre>
<!-- Author: Massimo -->


<!-- Date: Fri Jan 11 15:06:09 2008 -->
<pre>Before run 256106 installed new patterns and constants for the beam position X=-0.1303 Y=0.0907 XS=0.000510 YS=-0.000086. 
</pre>
<!-- Author: Massimo -->


<!-- Date: Thu Mar 6 15:54:58 2008 -->
I paged myself because SPYMON was not running on b0svt08. 
Logged onto the crate and restarted the process.
<!-- Author: Massimo -->


<!-- Date: Mon Mar 24 16:16:48 2008 -->
<pre>Before store 6004 (run 259929) I loaded new patterns and constants, 
generated for the beam position: 
 
x     = -0.1452 cm   
y     =  0.0265 cm   
dz/dx =  0.578 mrad  
dz/dy = -0.098 mrad  
 
 
</pre>
<!-- Author: Massimo -->


<!-- Date: Tue Mar 25 11:16:48 2008 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-398&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-398' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-399&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-399' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-400&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-400' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-401&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-401' width='300'></a></center>
<!-- Author: Massimo -->
<!-- Comment: Tue Mar 25 11;18;12 comment by...Massimo -->
Beam position history since January 11.


<!-- Date: Wed Apr 30 15:37:21 2008 -->
<pre>Since the vertical direction of the beam position was out the beam position used to generate the current patterns for more than 300 um, I load a previous set of patterns and constants, the one used on date 2008-01-11. 
The beam position for this set of patterns is: 
x=-1303 
y=907 
dx=510 
dy=-86</pre>
<!-- Author: Laura -->


<!-- Date: Mon May 26 13:05:56 2008 -->
<pre>I had a page at 11:50 May 26. Because of RXPT error related with b0svt00, ACE tried to shepherd this crate. But, RC said shepherding failed ACE tried it again. It may make SVT00 confuse and stuck. After a couple of reset and shepheding, we decied to have power-cycle. Then, it start working. </pre>
<!-- Author: Hyunsu -->


<!-- Date: Fri May 30 13:12:52 2008 -->
<pre>I think I have made it so that the Tracklist Board only sends  
tracks with pt&gt;2 GeV (8 &lt;= pt_bin &lt;= 87) to the SVT.  This change  
should be transparent to the SVT.  I checked the  
2.3.4: L2_Table_Beam table and there are no errors.  Run 262823 is the first run with this configuration.</pre>
<!-- Author: Heather Gerberich -->


<!-- Date: Thu Jun 5 01:29:30 2008 -->
<pre>Was just paged for SVT, but problem was resolved during phone conversation....not entirely clear on what the issue was, waiting to see further information regarding error.  Suspect that the error was actually in L2 and not in SVT since ace(?) mentioned that the log-files say 'waiting for SVT' yet SpyMon appears normal in ProcMon</pre>
<!-- Author: Michael A Schmidt -->


<!-- Date: Tue Jun 24 12:20:32 2008 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-402&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-402' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-403&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-403' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-404&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-404' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-405&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-405' width='300'></a></center>
<!-- Author: Massimo -->
<!-- Comment: Tue Jun 24 12;21;23 comment by...Massimo -->
Beam position from 03/24 to 06/24.


<!-- Date: Wed Jul 2 15:12:06 2008 -->
<pre>Installed new pattern and constant after store 6258 for the beam position.  
 
x     = -0.1221 cm    
y     =  0.0844 cm    
dz/dx =  0.609 mrad   
dz/dy = -0.103 mrad</pre>
<!-- Author: Hyunsu & Laura -->
<!-- Comment: Sat Jul  5 14;02;45 comment by...Massimo -->
<pre>I've uploaded the constants generated with the correct beam 
position. In the procedure I had forgotten a '#' in the mapset
file, so I had to upload another one.
For the record:
 512kpatt_20080705135555 --&gt; currently active mapset
 512kpatt_20080705132344 --&gt; mapset with missing '#' at line 120
</pre>

<!-- Comment: Sat Jul  5 14;04;05 comment by...Massimo -->
<pre>All this happened after store 6266.</pre>


<!-- Date: Wed Jul 30 02:13:49 2008 -->
<pre>I was paged because the SVT failure rate was above 0.002. I 
checked the SVTSPYMON plots, which looked fine. The only unusual 
thing I noticed was that the error LED of the b0svt08 tracer was 
on, but the monitoring plots relative to that crate were fine. I   
tried to run vslice on SVT crates. It was kinda working for all crates but b0svt01, in which case I got: 
 
Using Hit Buffer 
Crate is b0svt01, wedge is 3 
SC=11, MRG=12, AMSRW=17, AMPP_0=18, AMPP_1=19 HB=21, TF=-1 OMRG=-1 
Setup SVTSIM: wd=3 map=512kpatt_20080705135555 hw=20070626212159 
loading hwset 20070626212159.hwset, CRC 2322608428, hwsetCrc 2322608428 
loading mapset 512kpatt_20080705135555.mapset, CRC 2512880768, mapsetCrc 2512880768 
svtsim_dict_hash: h=-772 hs=997 
python: /cdf/onln/code/cdfprod/svtvme/development/src/svtsim_dict.c:81: svtsim_dict_hash: Assertion `h&gt;=0 && h&lt;self-&gt;hashSize' failed. 
Aborted 
 
While I was playing with vslice, b0svt01 and b0svt08 went into an  
error condition, which was hanging the data taking. The shepherding did not work, so I decided to power-cycle b0svt08  
and b0svt01. I had to restart SPYMON by hand on b0svt08, but then 
we could resume the data taking. The failure rate seems still high.</pre>
<!-- Author: Massimo -->
<!-- Comment: Wed Jul 30 21;58;03 comment by...Massimo and Alberto -->
<pre>The problem reappeared this afternoon. Alberto localized it on AM++ 1 board on wedge 3 (b0svt01, slot 19). We swapped the board:
AM++ #23 replaced with #17. </pre>


<!-- Date: Fri Aug 1 17:16:06 2008 -->
<pre>We installed a new SVTVME library. 
The new library will print out debug information needed to trace the source of some RXPT errors from SVT.  
The new library is an update of the development version. 
We should make a frozen version when the library will be more stable. 
I.e. when RXPT error debugging ends.</pre>
<!-- Author: Hyun Su and Alberto -->


<!-- Date: Fri Aug 1 17:27:47 2008 -->
<table><tr><td><a href=/elog/notebooks/svt/Fri_Aug__1_2008_172728.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-407  align='top'></a></td><td>SVT efficiency as a function of Int. Lum. </td></tr></table>
<!-- Author: Hyunsu -->


<!-- Date: Wed Aug 20 01:59:04 2008 -->
<pre>We installed new hwset file to disable HRR just from BC mismatching of Wedge0. It will calm down freqent RXPT error coming from SVT00. </pre>
<!-- Author: Hyunsu&Laura -->


<!-- Date: Fri Aug 22 16:52:19 2008 -->
<pre>Tonight b0svt03 had a lot of auto HRR, few ot them were very close to Bunch counter mismatch in COT crates. 
Here on the left there are SVT error timestamps in the RunControl logfile (/cdf/onln/data/cdfdaq/rcLog/errmon/log/266000/errorfile266405.log)  
after the arrow some errors in  errorfile266405_bunchcounters.log(same directory) 
 
Aug 22, 2008 05:04:00   no 
Aug 22, 2008 05:23:07 -&gt;(MLE) b0cot15:Messenger:Aug 22, 2008 05:23:06 AM-&gt;Runtime Error 27, Event 2749482: Bunch counter mismatch, mismatch count = 15 (errCount 539 
Aug 22, 2008 05:25:38  
Aug 22, 2008 05:42:27 -&gt;(MLE) b0cot19:Messenger:Aug 22, 2008 05:42:27 AM-&gt;Runtime Error 29, Event 3340947: Bunch counter mismatch, mismatch count = 1 (errCount 558) 
 
Aug 22, 2008 05:45:23 -&gt;(MLE) b0cot16:Messenger:Aug 22, 2008 05:45:23 AM-&gt;Runtime Error 40, Event 3414374: Bunch counter mismatch, mismatch count = 15 (errCount 837) 
 
Aug 22, 2008 05:54:36   no 
Aug 22, 2008 06:02:11   no 
Aug 22, 2008 06:05:40   no 
Aug 22, 2008 06:10:53 -&gt;(MLE) b0cot08:Messenger:Aug 22, 2008 06:10:54 AM-&gt;Runtime Error 51, Event 4167917: Bunch counter mismatch, mismatch count = 15 (errCount 969) 
 
Aug 22, 2008 06:11:57   no 
Aug 22, 2008 06:13:23   no 
Aug 22, 2008 06:18:22   no 
Aug 22, 2008 06:23:00   no 
Aug 22, 2008 06:25:03   no 
Aug 22, 2008 06:52:23   no 
Aug 22, 2008 07:14:31   no 
Aug 22, 2008 07:16:26   no 
Aug 22, 2008 07:18:20   no 
Aug 22, 2008 07:23:43   no 
Aug 22, 2008 07:25:55   no 
Aug 22, 2008 07:30:21   no 
Aug 22, 2008 07:35:07   ??b0xft02:Messenger:Aug 22, 2008 07:35:01 AM-&gt;Runtime Error 5, Event 6474918: Bunch counter mismatch, mismatch count = 1 (errCount 1446) 
(MLE) 
Aug 22, 2008 07:36:54  no  
Aug 22, 2008 08:00:00  no 
Aug 22, 2008 08:26:50  no 
Aug 22, 2008 10:13:29  no 
Aug 22, 2008 10:47:53  no 
Aug 22, 2008 10:52:19  no</pre>
<!-- Author: Benedetto -->


<!-- Date: Fri Aug 22 17:49:45 2008 -->
<pre>We disabled HRR generated by BC mismatching for all wedge because the problem was expanded for other crate(svt01 and svt03). Seems like it was same with svt00 problem. Most likely we pretty sure it was not dagerous but we should investigate more. </pre>
<!-- Author: Hyunsu and Laura -->


<!-- Date: Thu Aug 28 10:19:10 2008 -->
<pre>I updated hwset to enable HRR for All merger and disable HRR for each wedge(0~11). So, the final merger can do HRR if we have BC mismatching. </pre>
<!-- Author: Hyunsu -->


<!-- Date: Sat Aug 30 17:55:53 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-408&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-408  width='300' align='top'></a></td><td>Beam position in the latest two days: 
there is a small jump in DY at the beginning of the latest store. 
</td></tr></table>
<!-- Author: Benedetto -->
<!-- Comment: Sat Aug 30 17;57;42 comment by...Benedetto -->
<br><a href=
'/cgi/elog/elog.pl?nb=2008&action=view&page=728&frame=2&anchor=11:39:12.393'>See Here</a>


<!-- Date: Sat Aug 30 18:05:03 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-409&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-409  width='300' align='top'></a></td><td>Beam position 1-30 AUG.</td></tr></table>
<!-- Author: Benedetto -->


<!-- Date: Thu Sep 4 19:55:48 2008 -->
<pre>Run 266852 has be taken with the modified tracklist firmware: SLAM-confirmed tracks. To be used to test svtsim.</pre>
<!-- Author: Laura -->
<!-- Comment: Mon Sep  8 16;38;26 comment by...Laura -->
<pre>Files copied in fcdflnx8 /cdf/scratch/sartori/SLAM.</pre>
<!-- Date: Mon Sep 8 11:28:42 2008 -->
<pre>HERE we are collecting statistics about the out of sync problem 
 
20080908 run 266929 lum 70E30 failures in W7B4 W7B5</pre>
<!-- Author: Laura & Alberto -->


<!-- Date: Mon Sep 8 14:48:40 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-410&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-410  width='300' align='top'></a></td><td>Collecting statistic...</td></tr></table>
<!-- Author: Laura -->



<!-- Date: Tue Sep 9 07:17:51 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-411&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-411  width='300' align='top'></a></td><td>again...</td></tr></table>
<!-- Author: Laura -->


<!-- Date: Tue Sep 9 10:03:50 2008 -->
<pre>SPYDUMPS LOCATION 
 
SPYDUMPS OF THE LAST TWO HOURS: 
online svt data area 
/cdf/onln/data/cdf_svt/svttest/spymon/spydumps/ 
 
OLDER TARED FILES: 
(since september 2008 stored directly in the svt projectarea) 
1)log on fcdfprj1.fnal.gov 
2)cd /cdf/proj/111.svt/spydumps/</pre>
<!-- Author: Benedetto -->


<!-- Date: Thu Sep 11 09:19:24 2008 -->
<pre>We just swapped the HF for w7b4b5 (b0svt03 slot 15) with a spare. The HF that we took out is HF#048. It has been labeled as "gives seldom out-of-sync problems".</pre>
<!-- Author: Alberto & Laura -->


<!-- Date: Tue Sep 16 18:29:25 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-412&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-413  width='300' align='top'></a></td><td>Problem still there. It wasn't the HF.</td></tr></table>
<!-- Author: Laura  -->


<!-- Date: Tue Sep 16 18:31:28 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-414&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-415  width='300' align='top'></a></td><td>Still there</td></tr></table>
<!-- Author: Laura  -->
<!-- Comment: Tue Sep 16 18;37;43 comment by...Laura  -->
<pre>Lum very low, about 60 ×1030 cm-2sec-1.
It's not a high lumi problem. </pre>


<!-- Date: Tue Sep 23 12:23:36 2008 -->
<pre>Changed firmware in Tracklist Control A board from 0xb5709110 to 0xb5808190. The new firmware changes the shorter list of tracks that are sent to SVT. The shorter list is pt&gt;2, slam confirmed tracks (previously the shorter list consisted of all tracks with pt&gt;2). The path to L2 is not changed.  
I have updated the register setting SVTFILTERSETTING to 0 so that tracklist will send the full list of tracks to SVT, not the filtered list.</pre>
<!-- Author: Laura for Heather -->
<!-- Comment: Tue Sep 23 14;04;05 comment by...by Heather -->
<pre>This webpage has the tracklist control A firmware that we have been using 
for the last year:

http://www.hep.uiuc.edu/engin/cdf/XFT2/Tracklist%5FFirmware/Tracklist%5FControl%5FA/

In case there is a problem and it needs to be switched back, and I'm not 
available,  you can find it there.  

cheers,
Heather

</pre>


<!-- Date: Sun Sep 28 18:28:11 2008 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-416&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-416  width='300' align='top'></a></td><td>Lum, around 87</td></tr></table>
<!-- Author: Laura  -->


<!-- Date: Tue Sep 30 08:56:23 2008 -->
<table><tr><td><a href=/elog/notebooks/svt/Tue_Sep_30_2008_085616.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-418  align='top'></a></td><td>SVT efficiency vs lum. based on simulation of SVX peaple</td></tr></table>
<!-- Author: Hyunsu -->