<!-- Title: Eve shift. Wed Nov 26, 2003 -->
<!-- SciCo: Pekka Sinervo -->
<!-- DAQAce: Taka Maruyama -->
<!-- MonAce: Dale Stentz -->
<!-- CO: Andrey Korytov -->
<!-- OpManager: Masa Tanaka -->
<!-- Notes: -->
We get a store at 14.05x10**30.  Plan for the shift is to: 
<ul> 
<li> Continue stable running with PHYSICS_1_05 during store 
<li> At 7 PM, we will change COT thresholds (page COT expert at 6:30).  At that time, we will swap out a GB and restart the run. 
</ul> 
Goal is to achieve 87% efficiency, and look very carefully at data, looking for any anomalies.


<!-- Date: Wed Nov 26 16:23:38.915 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre> 
To conserve SmartSockets licenses, I have stopped the DBbroker  
proxy and processes on b0dap84; have stopped merlin and  
the merlin mysqld on b0dap83. 
 
Have also updated ProcMon to disable the merlin  
and dbBroker checks.   PLEASE DO NOT RESTART DBBROKER  
OR MERLIN! 
 
 
</pre></td></tr></td></table>
<!-- Author: W.Badgett :: (run <a href='/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175066' target=_top>175066</a>) -->


<!-- Date: Wed Nov 26 16:24:54.549 2003 -->
L2 decision timeout. (auto HRR).
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 16;25;35 comment by...Taka -->
Not due to SVT but due to CLIST (L2)


<!-- Date: Wed Nov 26 16:26:49.666 2003 -->
<pre>The West Inner BLM counter is actively reading a non-zero rate of radiation of ~.0026 R/s.  The current intergrated raditation is 43.025 R - the rest of the BLMs read 0 Rads.</pre>
<!-- Author: Dale -->


<!-- Date: Wed Nov 26 16:27:07.025 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>The problems with the LUMIs not updating on  
the RunSummary page and the absence of some  
continuing runs in the ShiftSummary in the  
eLog has been fixed in fer RunControl version v3_11 
 
If you have a convenient time, please restart  
runControl.  Don't forget to start a new xterm shell  
window before "setup fer" 
 
Please do not page DAQ again about this problem. 
</pre></td></tr></td></table>
<!-- Author: W.Badgett :: (run <a href='/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175066' target=_top>175066</a>) -->


<!-- Date: Wed Nov 26 16:27:19.641 2003 -->
Typical L1 accept rate ~8KHz, and L2 accept rate ~146Hz. right now.
<!-- Author: Taka -->


<!-- Date: Wed Nov 26 16:32:50.543 2003 -->
L3 rate is 0 since trigger inhibit works well. (CMX HV error)
<!-- Author: Taka -->


<!-- Date: Wed Nov 26 16:34:33.255 2003 -->
CMX HV trip on SW wedge 16-17.  Recovered.
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 17;11;32 comment by...Dale -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>CDF Downtime Log says that the following systems are 'obsolete' in the HV section (thus we cannot use them to make entries):

PEM, PHA, CPR, CMX, and CMP.

Is there a way to re-allow these guys to be used?</pre></td></tr></td></table>
<!-- Comment: Thu Nov 27 08;34;52 comment by...Phil Schlabach -->
Dale, I can tell you why CMX and CMP aren't there I think. This is a relic of the old trigger inhibit system. There was only 1 bit for CMU, CMX, CMP. The downtime logger only knew when that bit went off and made an entry under CMU HV. How this will play out in the new system I can't say.
<!-- Comment: Thu Nov 27 08;43;32 comment by...ps -->
suspiciously close to the spike in proton losses and on the right side...
<!-- Date: Wed Nov 26 16:35:35.714 2003 -->
<pre>TEVMON warring - spike in proton losses.  Calling MCR.</pre>
<!-- Author: Dale -->


<!-- Date: Wed Nov 26 16:38:22.079 2003 -->
b0dap52 shows no CPU report.
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 16;38;46 comment by...Taka -->
(from BigBrother)
<!-- Date: Wed Nov 26 16:38:31.432 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12512&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12512  width='300' align='top'></td><td>Spike in losses.</a></td></tr></table>
<!-- Author: Dale -->


<!-- Date: Wed Nov 26 16:38:43.920 2003 -->
Could I have a plot from BeamMon about the beam position, or using ACNET variable c:svtgy from lumberjack plotter (D44) ? thx.
<!-- Author: rainer -->



<!-- Date: Wed Nov 26 16:46:03.562 2003 -->
Steve Nann requested HRR. 
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 16;47;34 comment by...Taka -->
After HRR, L2 decision timeout happen, (not due to SVT but XTRP) 


<!-- Date: Wed Nov 26 16:56:37.355 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12513&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12513  width='300' align='top'></td><td>Beam position change so far today.</a></td></tr></table>
<!-- Author: Dale -->


<!-- Date: Wed Nov 26 17:00:51.221 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12514&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12514' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12515&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12515' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12516&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12516' width='300'></a></center>
<!-- Author: Andrey Korytov -->
<!-- Comment: Wed Nov 26 17;06;57 comment by...Andrey Koyrtov -->
<pre>XMon: 
L2 EM_ISO Trigger rates are 50% too high, all L1's are OK.
Will e-mail Matt Worcester.</pre>
<!-- Date: Wed Nov 26 17:01:15.909 2003 -->
I've taken a look at Xmon.  L1 looks golden.  L2 triggers based on SVT are all down by about 20%.  I don't have any explanation of this.  It appears that the SVT barrel beamlines that are used by L2 are being updated, but the 3D beamlines for L3 are being reported as (0,0).  Also, triggers with isolated photons in L2 are running hot.  This smells of a warm phototube.  L2_TWO_TRK2_D160_&_TWO_CJET10 has gone berserk.  This is probably also related.  However, I would expect MET triggers also do be high, and they are not.  It is also possible that we are seeing seasonal effects.   
<p> 
Xmon is not reporting the status of L3 triggers.  The only thing I can tell is that the silicon-based triggers are useless until the SVT 3D beamline is fixed.   
<p> 
I expect all track-based triggers to go up in rate by ~10% when the COT thresholds are lowered from 225mV to 205mV in the axial layers later in this shift.
<!-- Author: jdl -->
<!-- Comment: Wed Nov 26 20;40;03 comment by...jdl -->
SVT rates are probably low as a result of the beamline shift of 800um.  That reduces the efficiency of the roads.  The info in the DB for prediction the L2_TWO_TRK2_D160_&_TWO_CJET10 trigger is corrupt.  
<!-- Date: Wed Nov 26 17:06:39.926 2003 -->
HRR requested by Steve Nann.
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 17;08;52 comment by...Taka -->
Nothing happened.

<!-- Comment: Wed Nov 26 17;09;49 comment by...adf -->
It did what it was supposed to--set the SRC fishnet

<!-- Comment: Wed Nov 26 17;10;14 comment by...rainer -->
what d'ya mean 'nuffin' ?

<!-- Comment: Wed Nov 26 17;11;03 comment by...rainer -->
ah. andy fishing. something is happening!



<!-- Date: Wed Nov 26 17:12:12.749 2003 -->
<b>If you find SRC Fatal Errors</b> in the DAQ window, please call 
the SRC pager 722-7599 (Andy F.) until further notice.  
Please record in the elog any error messages from SRC, along with any other errors that occurred at the same time.
<!-- Author: adf -->


<!-- Date: Wed Nov 26 17:13:59.042 2003 -->
L3 error: if this is not necesarry, I apologize:<p> 
 
(MLE) b0l3pcom2.fnal.gov:main:4:48:26 PM->Error on L3 node b0l3c16 (partition 5) Wed Nov 26 16:48:25 2003 l3_node  
  in chain_loop (l3_chain.c:624) 
  @L3_INPUT_FAILURE:  chain 0 code Success (54172 good, 2771 bad)  
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 17;37;27 comment by...Guillelmo -->
It means one event was rejected at the converter level (bad input data?). A very few events (I would say less than 0.00001%) are rejected at this level is not a big deal.
<!-- Date: Wed Nov 26 17:20:30.861 2003 -->
<pre>Quick TEVMON alarm conserning a short beam loss spike.  </pre>
<!-- Author: Dale -->


<!-- Date: Wed Nov 26 17:34:07.365 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12517&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12517  width='300' align='top'></td><td>TrigMon: L2 seed tower eta error rate runs at 60%. No off-dioganal elements on the plot, though. L2 expert is being paged.</a></td></tr></table>
<!-- Author: Andrey Korytov -->
<!-- Comment: Wed Nov 26 17;39;41 comment by...Andrey Korytov -->
The numbers are hard to read: 
--> Left-bottom plot, the comment at top right reads 
   "418/669 = 62%"
<!-- Comment: Wed Nov 26 18;24;37 comment by...Steve Kuhlmann -->
<pre>I noticed this entry,  congrats to shift crew for spotting
those little numbers without an off-diagonal element.  
Tell the "L2 expert" when they call in that I'll take care of it.

It does not affect data quality,  but it IS the cause 
of the high L2_EM_Iso trigger rates mentioned above.

Depending on when this store ends tomorrow,  I'll come
in and work on it.  </pre>
<!-- Comment: Wed Nov 26 19;36;02 comment by...masa (&quot;L2 expert&quot;) -->
<pre>Thank you steve.</pre>
<!-- Date: Wed Nov 26 17:38:27.231 2003 -->
<pre>4 Pink cells in SVX: 
 
        Barrel    Wedge    Layer   Current    Back? 
BIAS       1        10       4      604        Yes 
AVDD       1        10       3      725        Yes 
AVDD       0        10       1      478        Yes 
AVDD       0         6       2      630        No 
 
Went to green after unmarking.  3 of them came back after about ~1 min.  Paging expert. 
 
</pre>
<!-- Author: Dale :: (run <a href='/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175066' target=_top>175066</a>) -->
<!-- Comment: Wed Nov 26 17;46;55 comment by...Dale -->
<pre>Rainer is in the coltrol room and has been notified [silicon expert not paged].  Note that all 4 cells came back to being pink (see plots below).</pre>
<!-- Comment: Wed Nov 26 17;46;59 comment by...rainer -->
these cells are known. they need tweaking based on the experience of the recent store to adjust their limits. I will make an entry what will be acceptable and what not. if in doubt, page expert.
<!-- Comment: Wed Nov 26 19;24;53 comment by...rainer -->
<h3> Current Pinkies in Silicon </h3>

<b> Aces </b>, you find a blueprint of what currently is acceptable for us 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=174&frame=2&anchor=19:21:12'>
here </a>. We will adjust the limits later such that the normal situation corresponds to no pinkies. If you see a pinky, unmark the cell. if the pinky persists, perform an HRR and look at the current history. make a note of the history in elog. if pinky persists after HRR, page expert.
<!-- Date: Wed Nov 26 17:43:05.438 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12518&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12518' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12519&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12519' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12520&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12520' width='300'></a></center>
<!-- Author: Dale -->


<!-- Date: Wed Nov 26 17:44:59.180 2003 -->
It looks like Subfarm#16 does not recieve any events. 
(though run is going well)
<!-- Author: Taka -->


<!-- Date: Wed Nov 26 17:45:10.323 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12521&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12521  width='300' align='top'></td><td>The other one came back.</a></td></tr></table>
<!-- Author: Dale -->




<!-- Date: Wed Nov 26 17:58:08.799 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12522&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12522' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12523&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12523' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12524&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12524' width='300'></a></center>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 17;58;47 comment by...Dale -->
Hourly plots for 16:00-17:00


<!-- Date: Wed Nov 26 18:01:41.784 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12525&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12525' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12526&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12526' width='300'></a></center>
<!-- Author: Andrey Korytov -->
<!-- Comment: Wed Nov 26 18;04;49 comment by...Andrey Korytov -->
TrigMon XFT and YMon COT seem to show correlated problems:
--> spike in SL2 around phi=300 degrees
--> some modulation vs phi


<!-- Date: Wed Nov 26 18:20:49.499 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12527&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12527' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12528&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12528' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12529&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12529' width='300'></a></center>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 18;21;17 comment by...Dale -->
Hourly plots for 17:00-18:00



<!-- Date: Wed Nov 26 18:33:56.725 2003 -->
Make HRR requested by Reiner. 
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 19;10;36 comment by...rainer -->
which got one pinky cell back to normal.
<!-- Date: Wed Nov 26 18:47:44.182 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12530&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12530' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12531&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12531' width='300'></a></center>
<!-- Author: Dale -->


<!-- Date: Wed Nov 26 18:56:02.225 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12532&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12532' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12533&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12533' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12534&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12534' width='300'></a></center>
<!-- Author: Andrey Korytov -->
<!-- Comment: Wed Nov 26 19;02;48 comment by...Andrey Korytov -->
<pre>Comments on ObjectMon:
1) There are slides in ObjectMon that do not have reference plots (e.g., two first slides in this posting).
2) Is what marked "BAD" in the third slide really bad?</pre>



<!-- Comment: Wed Nov 26 19;25;51 comment by...Andrey Korytov -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Fotis called and says HADTDC time width (third plot) is OK. </pre></td></tr></td></table>
<!-- Comment: Thu Nov 27 08;40;49 comment by...Phil Schlabach -->
Slide 2 looks good enough. I think the z plot is complaining because there's two little stuff in the BMU rear (i.e. losses coming down the beamline are down). That's a good thing if so. There may be a bit of a gap on the south side in the phi plot due to the bad CCU. That depends on the trigger bias in the input to the plots which always defeat me when I try to understand Objectmon.
<!-- Date: Wed Nov 26 19:17:58.684 2003 -->
COT experts want to change the COT threshold. 
But, their instruction is out od the link now. Please check this.  
<!-- Author: Dale and Taka -->
<!-- Comment: Wed Nov 26 19;26;58 comment by...Dale -->
<a href=
'http://penn01.fnal.gov/~cot/cosmics_02-26-03'> [e.g. try the link] </a>
<!-- Date: Wed Nov 26 19:19:34.489 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12535&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12535' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12536&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12536' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12537&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12537' width='300'></a></center>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 19;20;17 comment by...Dale -->
Hourly plots for 18:00-19:00




<!-- Date: Wed Nov 26 19:30:06.202 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175066">175066</A>
 Terminated at 2003.11.26 19:27:37
<!-- Author: RunControl -->


<!-- Date: Wed Nov 26 19:30:21.733 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175066">175066</A>
TERMINATE: End the run to change COT thereshold.
<!-- Author: Taka x2080 -->




<!-- Date: Wed Nov 26 19:36:08.657 2003 -->
Switched Muon fibers and XTRP cables back to the default pulsar board (#0002, slot 11)
<!-- Author: Burkard -->


<!-- Date: Wed Nov 26 19:38:21.826 2003 -->
<pre>rc complains:  
Strange (but not necessarily fatal) Run Configuration selections: 
Unusual setting for l3NumberOfCores 10, usual setting is 1 
Crate TRIGGER_INHIBITS_00 missing from run 
</pre>
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 20;29;10 comment by...Guillelmo -->
This is strange, is there anybody interested in send more Core files to filter people for those runs???
<!-- Date: Wed Nov 26 19:41:30.692 2003 -->
<pre>Setting COT threshold: 
 
Until we change the COT database, the Ace can set the COT 
thresholds to 225 (old value) or 205 (new value) from any 
cdfdaq account terminal by typing either: 
 
   setcv -f 225 
 
or 
 
   setcv -f 205 
 
from the command line.  This should be done after coldstart in  
Run Control, before activating the run.  If any COT crate has a 
timeout and needs to be shepharded, then the script should be 
re-run before continuing with the run.</pre>
<!-- Author: ambrose -->

<!-- Date: Wed Nov 26 19:47:46.400 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175075">175075</A>
 Activated at 2003.11.26 19:44:41
<!-- Author: RunControl -->


<!-- Date: Wed Nov 26 19:47:47.439 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175075">175075</A>
 Activated at 2003.11.26 19:44:42
<!-- Author: RunControl -->


<!-- Date: Wed Nov 26 19:47:48.867 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175075">175075</A>
ACTIVATE: Start the run after changing COT threshold values
<!-- Author: Taka x2080 -->
<!-- Comment: Wed Nov 26 20;03;25 comment by...Taka -->
We changed COT threshold value from 225 to 205 to test the 
efficiency. <br>
Command for this is: <br>
setcv -f [threshold value] <br>

<!-- Date: Wed Nov 26 19:49:01.466 2003 -->
<pre>We had error:  
Attention!!!. SCPU_TRACER_EVENT_ID Error !!!  
 Hardware EVB has detected a problem with data in  
 SCPU b0eb14 ( FER crate : NOT_AVAILABLE).  
 Datataking is paused: events are not being processed.  
  
 AUTO HRR will be issued.  
  
 N.B. an automatic HRR for HEVB errors will be re-issued (if still needed)   
 </pre>
<!-- Author: Taka -->


<!-- Date: Wed Nov 26 19:49:51.159 2003 -->
L2 decision timeout. (slot12 of L2, SVT)
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 19;51;41 comment by...Taka -->
Again!!


<!-- Comment: Wed Nov 26 19;56;43 comment by...Taka -->
Again due to SVT (slot12 of L2)!
<!-- Comment: Wed Nov 26 19;59;05 comment by...Taka -->
Again due to SVT.
<!-- Comment: Wed Nov 26 20;17;36 comment by...Taka -->
We don't understand this features, but we often have "L2 decision timeout" due to SVT  at the beginning of the run. However, after 
~10min. or so from the run activation, we never see this problem. (from 2 physics run experiences) again. Is this a hint to solve the problem? 
<!-- Date: Wed Nov 26 19:53:23.411 2003 -->
Prescale was automatically changed. 
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 19;54;00 comment by...Taka -->
L1_TWO_TRACK trigger was pre-scaled



<!-- Comment: Wed Nov 26 20;24;43 comment by...jdl -->
You don't have to note these.  They are listed in the run summary.
<!-- Date: Wed Nov 26 19:58:35.491 2003 -->
Prescale was changed. 
L2_CEM10_ISO
<!-- Author: Taka -->



<!-- Date: Wed Nov 26 20:02:44.471 2003 -->
Prescale was changed automatically. : L1_TWO_TRK2_DPHI90_DPS
<!-- Author: Taka -->



<!-- Date: Wed Nov 26 20:05:34.264 2003 -->
Current L1 accept rate is ~8000Hz, L2 ~113Hz.
<!-- Author: Taka -->


<!-- Date: Wed Nov 26 20:06:46.008 2003 -->
<b> 
COT thresholds have now been changed in the database to 205 mV 
for the even (XFT) superlayers. 
</b> 
<p> 
After a coldstart, running the command: 
<pre> 
   setcv -cr 
</pre> 
from a cdfdaq account terminal (which reads back the DAC values) 
should show threshold (DTH) values of 205 for even and 225 for 
odd superlayers.
<!-- Author: ambrose -->


<!-- Date: Wed Nov 26 20:08:51.225 2003 -->
Prescale was changed
<!-- Author: Taka -->


<!-- Date: Wed Nov 26 20:12:40.469 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030>Dave (COT expert) wants to make new Database. when next coldstart will happen, please page Dave (he is in home now.) to make sure 
new Database will be used!! </td></tr></td></table>
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 23;41;16 comment by...Pekka -->
Dave did check that the COT thresholds were not correctly in the database when we did the next coldstart.  
<!-- Date: Wed Nov 26 20:16:51.865 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12538&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12538' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12539&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12539' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12540&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12540' width='300'></a></center>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 20;17;35 comment by...Dale -->
Hourly plots for 19:00-20:00 



<!-- Date: Wed Nov 26 20:24:02.912 2003 -->
L2 decision timeout dut to SVT. (again)
<!-- Author: Taka -->




<!-- Date: Wed Nov 26 20:48:24.494 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175066">175066</A>
RUNSTATUS: <PRE>Marked Bad, explanation:
COT - 1st hundred cells of SL7 off
IMU - 20 scintillators missing in TSU East
TOF - Number of channels are flakey
</PRE>
<!-- Author: cdfscico -->



<!-- Date: Wed Nov 26 21:08:17.847 2003 -->
Suddenly lots of errors: 
 
Busy Condition in VRB/EVB forwarded by crates: 
VRB_ISL_06 
TRIGGER_SCALERS_00 
 Busy conditions do not represent a problem with the front end 
 crates themselves, but with the EVB system. 
 
Attention!!!. SCPU_TRACER_EVENT_ID Error !!!  
 Hardware EVB has detected a problem with data in  
 SCPU b0eb15 (forwarded by FER crate CCAL_00).  
 
RXPT Errors LOOP --> we need to look at b0svx06
<!-- Author: Dale :: (run <a href='/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175075' target=_top>175075</a>) -->
<!-- Comment: Wed Nov 26 21;11;15 comment by...Dale -->
realtime busy and latched busy crate : b0tsi03

<!-- Comment: Thu Nov 27 01;46;00 comment by...rainer -->
<b> reminder from silicon ace class </b> 
 <i> <p>
Busy TO: Means VRB has no more space for events.  Exceedingly common , as EVB stops when any data corruption  is detected anywhere (normally NOT in a Silicon crate) and the Silicon VRBs fill up first.  Find data corruption and page responsible group
</i><p>
here, from error log file, at 9:01pm
<pre>CT: 2003.11.26 21:01:11
1'11" b0l3pcom1.fnal.gov:main:9:01:06 PM->Host b0eb15.fnal.gov, task tRec_0
SCPU-P5-E-TracerEventId: Event 542058, crate 2, channel 1 has either bad Tracer ID or bad markers around Tracer word.
 Tracer word event ID is 9, should be 10.
Tracer word = 0x01d90502 (I think).
Channel data = 0x0000012b 0x01d90502 0x43454d44 0x00100002 0x00000000 0x0000003d 0x00000001 0x00c00062 ...
... 0x00000000 0x00000000 0x00000000 0x00000000 0xaaaaaaaa 0x55555555 0x01d90502 0x80000000 -->  
 Additional Information: 

 Attention!!!. SCPU_TRACER_EVENT_ID Error !!! 
 Hardware EVB has detected a problem with data quality in 
 SCPU b0eb15 (forwarded by FER crate CCAL_01). 
 Datataking is paused: events are not being processed. 
 
 AUTO HRR will be issued.  
 N.B. an automatic HRR for HEVB errors will be re-issued (if still needed)  
 in 30 secs. [MLE]
</pre>
whatever it was, it persisted, so the EVB got stuck but silicon fills up first with buffers so pulls BUSY T0. highest event volume in L00 which is in b0svx06, so most likely loser in the 
'who has the most buffer space' game if no events are built by EV and shuffled towards L3 and onwards. So your conclusion is incorrect - it's not b0svx06 you need to worry about but about the branch with data corruption.<p>

problem persisted as you found out, but not silicon's fault.
<!-- Date: Wed Nov 26 21:14:36.687 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175075">175075</A>
 Terminated at 2003.11.26 21:11:53
<!-- Author: RunControl -->


<!-- Date: Wed Nov 26 21:16:33.344 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175075">175075</A>
TERMINATE: End the run to recover from DAQ error.
<!-- Author: Taka x2080 -->


<!-- Date: Wed Nov 26 21:19:32.379 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175076">175076</A>
 Activated at 2003.11.26 21:17:26
<!-- Author: RunControl -->


<!-- Date: Wed Nov 26 21:20:58.478 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175076">175076</A>
ACTIVATE: Start the run after verifying COT threshold.
<!-- Author: Taka x2080 -->



<!-- Date: Wed Nov 26 21:21:38.259 2003 -->
We have busy timeout :  
 
Busy Condition in VRB/EVB forwarded by crates: 
VRB_ISL_06 
Busy conditions are produced by the VRB and are forwarded 
 by the front end crates to the busy crosspoint.  Busy 
 conditions do not represent a problem with the front end 
 crates themselves, but with the EVB system.v
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 21;23;23 comment by...Taka -->
<pre>Again!!</pre>
<!-- Comment: Wed Nov 26 22;05;11 comment by...Taka and Dale -->
<pre>We reset - and clean the EVB - we then able to run succesfully.</pre>
<!-- Comment: Thu Nov 27 01;47;42 comment by...rainer -->
see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2003&action=view&page=989&frame=2&anchor=21:08:17.847'>
above. </a>
<!-- Date: Wed Nov 26 21:21:55.798 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12541&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12541' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12542&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12542' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12544&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12544' width='300'></a></center>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 21;22;35 comment by...Dale -->
Hourly plots for 20:00-21:00
<!-- Date: Wed Nov 26 21:22:10.586 2003 -->
During next patch of smooth running, I'd appreciate it if someone 
could check that the SRC logic analyzer (on 1st floor) is  
in "Level 2" waiting.  If it is in "Level 1" (and CDF is 
taking data smoothly) please call SRC pager; otherwise please 
put a note in the silicon elog.  This is not super-urgent, it's our fishnet for catching the SRC L2w/oL1 error; has no effect on data-taking.
<!-- Author: adf -->

<!-- Date: Wed Nov 26 21:22:35.061 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175076">175076</A>
 Terminated at 2003.11.26 21:20:22
<!-- Author: RunControl -->



<!-- Date: Wed Nov 26 21:23:10.042 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175076">175076</A>
TERMINATE: No data was taken since b0svx06 busy timeout.
<!-- Author: Taka x2080 -->



<!-- Date: Wed Nov 26 21:27:59.164 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175077">175077</A>
 Activated at 2003.11.26 21:25:42
<!-- Author: RunControl -->


<!-- Date: Wed Nov 26 21:28:07.234 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175077">175077</A>
ACTIVATE: Start the run.
<!-- Author: Taka x2080 -->



<!-- Date: Wed Nov 26 21:29:13.523 2003 -->
<pre>2 pink guys in L00 and ISL: 
 
                 where                   Current 
 L00 5VDOIM  Barrel 1  Wedge 2  Layer 5  1310.0 
 ISL AVDD  Barrel 5  Wedge 1  Layer 1    1565.0 
 
unmarking.</pre>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 22;14;08 comment by...Taka & Dale -->
<pre>ISL AVDD  Barrel 5  Wedge 1  Layer 1 became pink again.

Current = 1570.0

history plot to come below.</pre>
<!-- Date: Wed Nov 26 21:30:21.808 2003 -->
Busy timeout again. : <br> 
 
  State       ACTIVATE 
(MLE) b0tsi02:Messenger:9:26:05 PM->BUSY timeout 
(MLE) b0tsi02:Messenger:9:26:09 PM->BUSY timeout 
(MLE) b0svx06:Messenger:9:26:10 PM->Silicon Timeout:BUSY- Slots:  10:fa20 20:f840 08:fa00 18:f820 16:f800 12:fa40  
<!-- Author: Taka -->

<!-- Date: Wed Nov 26 21:32:30.804 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175077">175077</A>
 Terminated at 2003.11.26 21:29:48
<!-- Author: RunControl -->


<!-- Date: Wed Nov 26 21:32:31.709 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175077">175077</A>
TERMINATE: Busy timeout from b0svx06.
<!-- Author: Taka x2080 -->



<!-- Date: Wed Nov 26 21:37:53.855 2003 -->
We clean up L3 again as suggested by error message.
<!-- Author: Taka -->

<!-- Date: Wed Nov 26 21:40:06.575 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175078">175078</A>
 Activated at 2003.11.26 21:37:18
<!-- Author: RunControl -->


<!-- Date: Wed Nov 26 21:40:07.020 2003 -->
Run <A HREF="/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175078">175078</A>
ACTIVATE: Start run. 
<!-- Author: Taka x2080 -->



<!-- Date: Wed Nov 26 21:42:24.376 2003 -->
L2 decision timeout (SVT)!
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 21;42;51 comment by...Taka -->
Again!!

<!-- Comment: Wed Nov 26 21;48;01 comment by...Taka -->
Again (SVT)


<!-- Comment: Wed Nov 26 22;02;08 comment by...Dale -->
L2 decision timeout like above.
<!-- Date: Wed Nov 26 22:01:15.466 2003 -->
<pre>I checked the SRC logoc analyzer. He is waiting for Level2 timing. 
 
</pre>
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 22;03;07 comment by...Dale -->
<pre>FrontEnd crate Error: VRB_ISL_06.  HRR - successfully.</pre>



<!-- Comment: Wed Nov 26 22;48;22 comment by...adf -->
Thanks for checking LA!
<!-- Comment: Thu Nov 27 01;31;11 comment by...rainer -->
Here the  ISL SRC was pulling <pre>
errorfile175078.log:(MLE) b0svx06:Messenger:9:55:57 PM->SRC Fatal Error:Sl 5 Too Many L1A 2 L1A to Buff 
<pre>
the only front end error so far. if I interprete correctly here the SRC is complaining about too many L1s, so L2 is not directly involved - different problem.
<!-- Comment: Thu Nov 27 01;33;45 comment by...html fix -->
</pre>
<!-- Comment: Mon Dec  1 09;25;10 comment by...   -->
</pre>
<!-- Date: Wed Nov 26 22:06:34.239 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12545&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12545' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12546&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12546' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12547&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12547' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12548&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12548' width='300'></a></center>
<!-- Author: Andrey Korytov -->
<!-- Comment: Wed Nov 26 22;15;44 comment by...Andrey Korytov -->
<pre>!!! L1 and L2 trigger rates are red and blue...

In this run, COT thresholds were set lower:

--&gt; L1 trigger rates have become red, 
    but were not red in the previous run...
    Note that Muon trigger, although has the same rate, 
    is now red. The *expected rate* is now lower... WHY?

--&gt; L2_TWO_TRK2 goes crazy, 
    factor of 40 (!) above the expected rate...
    The same story in the previous run.</pre>


<!-- Comment: Mon Dec  1 14;27;49 comment by...Matt W. -->
The expected x-sections from the DB are a function of luminosity and a few parameters calculated from past runs, so (1) they should change as the store progresses and the L drops and (2) they get out of date quickly if hardware mods are made during a store.  With the COT thresholds set lower, the expectations from the DB for all the track-based triggers will be old and need updating, so they should be out of range.  The other out of range triggers are noticed and explained by Steve, Jonathan, and others above.
<!-- Date: Wed Nov 26 22:17:06.932 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12551&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12552  width='300' align='top'></td><td>ISL AVDD  Barrel 5  Wedge 1  Layer 1 history plot</a></td></tr></table>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 22;18;51 comment by...Dale and Taka -->
<a href=
'/cgi/elog/elog.pl?nb=2003&action=view&page=989&frame=2&anchor=21:29:13.523'>
See above. </a>


<!-- Date: Wed Nov 26 22:19:27.434 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12553&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12553  width='300' align='top'></td><td>TrigMon: XFT COT L2 occupancy spike grew a lot since the previous run. is it due to lower COT thresholds or something else?</a></td></tr></table>
<!-- Author: Andrey Korytov -->
<!-- Comment: Wed Nov 26 22;27;15 comment by...Andrey Korytov -->
COT SL2 occupancy spike around cell No.160 indeed went up from ~0.6 in previous run to about ~0.9. 


<!-- Date: Wed Nov 26 22:27:42.479 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12555&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12555' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12556&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12556' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12557&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12557' width='300'></a></center>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 22;28;45 comment by...Dale -->
Hourly plots for 21:00-22:00 


<!-- Date: Wed Nov 26 22:32:10.605 2003 -->
Maybe only delayed. But we don't have any look area data for  
this run. 
<!-- Author: Taka :: (run <a href='/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175078' target=_top>175078</a>) -->


<!-- Date: Wed Nov 26 22:37:45.985 2003 -->
I quickly check the old look area data to the beam line  
for SVTD and SVDD (from SVT). Data of beam line looks staying 
(0,0). However, TrigMon figures are quite fine. 
This is odd!! 
<!-- Author: Taka -->


<!-- Date: Wed Nov 26 22:44:13.772 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12558&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12558  width='300' align='top'></td><td>The e-log note from the previous shift seems to indicate that the problem might have gone. Nope, it is still there!</a></td></tr></table>
<!-- Author: Andrey Korytov -->
<!-- Comment: Wed Nov 26 23;15;02 comment by...Dale -->
<P>
Actually just some (momentary) wishfull thinking by Phil.  Fairly clear that this has been bad since 
<a href=
'/cgi/elog/elog.pl?nb=2003&action=view&page=988&frame=2&anchor=10:20:41.447'>
the problem happened after the closing of the torids.</a>
[<a href=
'/cgi/elog/elog.pl?nb=2003&action=view&page=988&frame=2&anchor=13:30:10.240'>
See the previous plots here. </a>] 
 Experts (Davit, Phil [spl], etc.) know about this but it is a good idea to still relook at this plot and look for a change.


<!-- Date: Wed Nov 26 23:05:19.653 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12559&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12559' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12560&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12560' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12561&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12561' width='300'></a></center>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 23;05;44 comment by...Dale -->
Hourly plots for 22:00-23:00


<!-- Date: Wed Nov 26 23:11:06.921 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12563&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12563' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12564&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12564' width='300'></a></center>
<!-- Author: Taka -->
<!-- Comment: Wed Nov 26 23;16;49 comment by...Taka -->
Left: Impact parameter distribution from Online monitor (run#175078), right: impact parameter vs phi from 
offline data (run#175075). 
Online board has good beam information (and impact parameter), but offline has odd distribution?? Couldbe a bug, but very very strange!!.
   
<!-- Comment: Wed Nov 26 23;18;31 comment by...Taka -->
Information used here here are come from SVTSPYMON (left), SVTD (right). 
<!-- Date: Wed Nov 26 23:14:56.951 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12565&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12565  width='300' align='top'></td><td>TrigMon: Cal tower L1 occupancy.  Data distributions look more or less OK (there might be  some activity at phi=5, though).  However, the problems with Data vs Sim plots seem to  get worse... Compare with the plots posted yesterday,  Nov 25 EVE shift (both have about the same statistics).</a></td></tr></table>
<!-- Author: Andrey Korytov -->





<!-- Date: Wed Nov 26 23:24:24.354 2003 -->
<center><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12566&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12566' width='300'></a><a href='/cgi/elog/elog.pl?nb=2003&action=view&page=-12567&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/elog.pl?nb=2003&action=view&page=-12567' width='300'></a></center>
<!-- Author: Andrey Korytov -->
<!-- Comment: Wed Nov 26 23;26;17 comment by...Andrey Korytov -->
Another new XFT spike in COT SL8. And, again, it may be related to COT SL8 high occupancy in the same area...
<!-- Date: Wed Nov 26 23:25:16.223 2003 -->
<pre>Pink cells for SVX/ISL/L00: 
 
SVX AVDD   Barrel 0  Wedge 10  Layer 1 
SVX AVDD   Barrel 1  Wedge 10  Layer 3 
SVX VBIAS  Barrel 1  Wedge 10  Layer 4 
ISL AVDD   Barrel 5  Wedge 1   Layer 1 
 
The first 3 are known to Rainer. 
</pre>
<!-- Author: Dale -->



<!-- Date: Wed Nov 26 23:32:51.597 2003 -->
HRR is requested by Reiner. 
<!-- Author: Taka -->


<!-- Date: Wed Nov 26 23:37:37.213 2003 -->
L1 accept rate ~6800Hz, L2 rate ~110Hz right now. 
<!-- Author: Taka :: (run <a href='/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175078' target=_top>175078</a>) -->


<!-- Date: Wed Nov 26 23:40:26.424 2003 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2003&action=view&page=-12568&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2003&action=view&page=-12568  width='300' align='top'></td><td>History plot of ISL AVDD  Barrel 5  Wedge 1  Layer 1.  Note that it went back to good (current in accepted levels) after HRR.  Still good (green cell).</a></td></tr></table>
<!-- Author: Dale -->
<!-- Comment: Wed Nov 26 23;44;33 comment by...Dale -->
<P>
Current went bad around the time of the start of the new run (with the COT treshold changed).  [<a href=
'/cgi/elog/elog.pl?nb=2003&action=view&page=989&frame=2&anchor=21:20:58.478'>
See above.</a>]
</P>


<!-- Date: Wed Nov 26 23:54:19.798 2003 -->
<table border=0><td><tr><td bgcolor=#e0e030>B0DAP53 top monitor (where XMon and SiliMon Displays pop up) has some synchronization problems---need to be fixed or replaced! </td></tr></td></table>
<!-- Author: Andrey Korytov -->

<!-- Date: Wed Nov 26 23:57:41.633 2003 -->
<TABLE BORDER=2 CELLSPACING=1 CELLPADDING=1 BGCOLOR=WHITE>
<TR BGCOLOR=YELLOW><TH>Run Number</TH>
<TH>Data Type</TH>
<TH>Physics Table</TH>
<TH>Begin Time</TH>
<TH>End Time</TH>
<TH>Live Time</TH>
<TH>L1 Accepts</TH>
<TH>L2 Accepts</TH>
<TH>L3 Accepts</TH>
<TH>Live Lumi, nb-1</TH>
<TH>GR</TH>
<TH>SC</TH>
<TH>RC</TH></TR>

<TR><TD><A HREF=/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175066>
175066</A> 
x2ABDA</TD>                                                             
<TD>BEAM</TD>                                                           
<TD>PHYSICS_1_05 [8,345,404]</TD>                                       
<TD ALIGN=CENTER>15:00:45</TD>                                          
<TD ALIGN=CENTER>19:27:37</TD>                                          
<TD ALIGN=CENTER>04:21:09</TD>                                          
<TD ALIGN=RIGHT>    121,554,504</TD>                                    
<TD ALIGN=RIGHT>     2,166,155</TD>                                     
<TD ALIGN=RIGHT>     394,756</TD>                                       
<TD ALIGN=RIGHT>  206.481</TD>                                          
<TD ALIGN=CENTER>0</TD>                                                 
<TD ALIGN=CENTER>1</TD>                                                 
<TD ALIGN=CENTER>1</TD></TR>                                            
                                                                        
<TR><TD><A HREF=/java/cdfdb/servlet/RunSummary?RUN_NUMBER=175075>
175075</A> 
x2ABE3</TD>                                                             
<TD>BEAM</TD>                                                           
<TD>PHYSICS_1_05 [8,345,404]</TD>                                       
<TD ALIGN=CENTER>19:44:42</TD>                                          
<TD ALIGN=CENTER>21:11:53</TD>                                          
<TD ALIGN=CENTER>01:14:32</TD>                                          
<TD ALIGN=RIGHT>     31,373,365</TD>                                    
<TD ALIGN=RIGHT>       542,097</TD>                                     
<TD ALIGN=RIGHT>     103,067</TD>                                       
<TD ALIGN=RIGHT>   49.299</TD>                                          
<TD ALIGN=CENTER></TD>                                                  
<TD ALIGN=CENTER>1</TD>                                                 
<TD ALIGN=CENTER>1</TD></TR>                                            
                                                                        
<TR><TD>Totals</TD>                                                     
<TD> </TD>                                                              
<TD> </TD>                                                              
<TD> </TD>                                                              
<TD>23:55:01</TD>                                                       
<TD ALIGN=CENTER>05:35:41</TD>                                          
<TD ALIGN=RIGHT>     152,927,869</TD>                                   
<TD ALIGN=RIGHT>      2,708,252</TD>                                    
<TD ALIGN=RIGHT>       497,823</TD>                                     
<TD ALIGN=RIGHT>  255.779</TD>                                          
<TD> </TD>                                                              
<TD> </TD>                                                              
<TD> </TD></TR>                                                         
                                                                        
</TABLE>
<!-- Author: End of Shift Report -->



<!-- Date: Thu Nov 27 00:14:32.623 2003 -->
<font color=red>Shift Summary: </font>The shift was spent collecting data after an initial store of 15x10**30 was inherited. 
We focused on taking good quality data, and collected over 300 nb-1.   
Highlights of the shift included: 
<ul> 
<li> Adjusting the COT thresholds from 225 to 205.   
This caused an approximately 10%  
increase in various 2-track trigger rates that Jonathan had earlier  
speculated  
were being unreasonably impacted by the higher COT thresholds. 
<li> Swapped out the spare pulsar board and began running with the default one. 
We continued to have a number of L2 timeouts, especially at the beginning of th 
run.  They seemed to go away after the first 10 minutes or so. 
<li> We had the DAQ system "fall apart" once where, there were a host  
of timeouts.  The EVB eventually had to be cleaned up by hand.   
<li> The CO reviewed all the monitoring plots, and identified a slew of  
small anomalies 
that are recorded in the shift log.   
Having brought them into the open, we now have to  
proceed to address these issues one-by-one.  
</ul> 
MCR plans to have us sit on this store till 11 AM tomorrow morning, at  
which time we  
would immediately go into shot setup.   
<br><b>End of Shift Numbers</b>
<table><tr><td width=60% align=left>
<b>CDF Run II <p></b>                       
<pre>
Runs                   175066-175076
Delivered Luminosity   398  
Acquired Luminosity    363  
Efficiency             91
   
</td></tr></table></pre>
<!-- Author: Pekka -->