<!-- Title: 15:50:49  Mon Feb 11 2002 -->
<!-- Crewchief: L2 group et al. -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>L2 for physics. 
Switch to TTL arbitration.</pre>


<!-- Date: Mon Feb 11 16:31:41 2002 -->
<pre>L2 Meeting 2/11/02 
 
L2 Status - bad Iso cable caused problems over the weekend.  
Replacing with spare cable fixed the problem. 
 
Spare cables - We need spare cables for every board. These should 
kept in the L2 cabinet. 
 
Running without SVT. If L2 is in a partition without SVT, XFT 
or Calorimetry, then it won't get data from that subsystem and 
will report a L2 decision timeout. If L2 is run in autoaccept 
mode then the error checking is disabled. Greg will talk to  
online group to have Run control to automatically go into  
autoaccept mode when L2 is being run without any of L1, b0l2cl0x, 
b0svt06, b0svt07, b0xtrp00.  
  In the long term we should have the mod_done bits sent to the 
alpha set according to which subsytems are in the partition.  
This would be used to enable the appropriate error checking. 
 It would also be useful for the interface boards themselves 
to be disabled.  
 
Error code- Checking for Isolation errors in in the new error 
code, but not in any existing executable. Peter Wittich will 
recompile a number of physics tables to pick up the new error 
handling code. Also, Isolation errors will be promoted from  
warning to error. 
 
MBus Arbitration testing 
 The testing last week with the new backplane convinced us 
that the noise levels are too high to ever make PECL arbitration 
fully reliable. 
 Stephen will send out a plan for how to convert to TTL arbitration. 
 
New Jet triggers. Test with Cosmic rays wasn't useful because 
of hot trigger towers. Some changes are needed to the Java code 
that makes the header files. Otherwise the exe is ready for 
testing with beam.</pre>
<!-- Author: Stephen -->


<!-- Date: Mon Feb 11 20:24:51 2002 -->
Remove from SVT hwset SB4W0L2 that was re-integrated today but gives too many DTO because occasionally (actually very frequently) sending leading 0 instead of correct header+bc words. 
To my knowledge this can only be done superceeding RC hfMask  
with something from hwset...<br><br> 
Also reenabled DTO from b0svt02 that was disabled on Sunday  
morning because of too many DTO when fib06 was dropped from the partition.   
<!-- Author: Marco  -->


<!-- Date: Tue Feb 12 17:11:19 2002 -->
This afternoon Roberto straightened the bent pins on the b0l2de00 magic bus.  After he was done, we took the b0l2de00 for torture tests.  During these tests, the TeV was doing pbar studies.<p> 
all CAL, L1/L2CAL, L1GL, L2DE, SVT06-07, SCALERS, XTRP, L3<br> 
L2autoaccept = 0; nosvx=stephen1.hfospy; extra 1 = 1<br> 
All files to look area.<p> 
<b>138975</b> L2_TORTURE[3,233].  L1A=23kHz, L2A=125Hz, 51% dead, mostly from L2, 4 full buffers.  All boards OK except SVTlist.  SVTlist sent 1 mb word/event (confirmed with the scope on the backplane).  However, in TrigMon, Ntracks was always 2, with the second track's data always 0.  Also in this run XMon noticed that the L1 scalers in TL2D were not there.<br> 
<b>138976</b> PHYSICS_0_04[5,260].  Current default trigger table.  L1A=2.9kHz, L2A=234Hz, 99% dead, mostly from TS, 4 full buffers.  In this table, the high rates were from the fake XTRP tracks passing the track triggers.  It appears that most of these events were cut by L3.  The cal trigger rates were small.  In this run all boards were OK.<p> 
It appears that L2_TORTURE[3,233] has not been updated since Stephen added the L1 scalers and changed the track accounting for SVT.  Otherwise, all is well.
<!-- Author: Greg and Matt -->


<!-- Date: Tue Feb 12 17:55:56 2002 -->
Preliminary work with the new magic bus in b0l2de01: put all of the BOSSGRIN/OUT jumpers from the previous backplane onto the new, including 
the inside of slot 21. Did not put the breakout board with the mb testpoints in slot 3, so all signals were taken directly from the backplane pins. Removed the 0.1uF caps 
from the BOSS and BOSSREQ drivers on SVTlist 07. 
<p> 
Ran with SVTlist07 in slot 7, alpha in slot 3. l2exe: L2_TORTURE_v-3_L2Auto (from reloading the alpha with alpha_nots_linux). L1mode: calib cont, L2mode: L2 Auto 
Accept. SVTlist07 had the 34 usec delay firmware. START_LOAD, BOSS, and DSTROBE looked normal on the scope. Turned on the readout and took run 138967 with 
fake tracks from SVT. There were no errors in TrigMon for that run. 
<p> 
Tests will continue tomorrow.
<!-- Author: Natalia, Matt -->


<!-- Date: Wed Feb 13 09:35:55 2002 -->
<pre>I will be running some diagnostics on b0svt00 in the next 15-30 min.</pre>
<!-- Author: Luciano -->
<!-- Comment: Wed Feb 13 09;50;01 comment by...Luciano -->
<pre>AMboard in b0svt00 slot 10 SN=04 has a bad AMplug. I will swap
it ASAP.</pre>


<!-- Date: Wed Feb 13 10:21:51 2002 -->
<pre>I'm taking SVT crates 00-05 for a few hours to fix the faulty AMboard and run standalone diagnostics.</pre>
<!-- Author: Luciano -->
<!-- Comment: Wed Feb 13 13;00;35 comment by...Luciano -->
<pre>I am now finished with SVT crates</pre>
<!-- Date: Wed Feb 13 12:59:50 2002 -->
<pre>This is what I did with SVT: 
 
-Crate 03: 
   - Unplugged AMboard #23 in crate 03 slot 10 to check AMplug  
     configuration. This board was swapped in a couple of  
     weeks ago. 
   - Plugged back in AMboard #23 
 
- Crate 00: 
   - unplug AMboard #4 from slot 10 
   - swap AMplug #219 out and replace with #223 
   - plug AMboard #4 in again 
   - AMboard #4 STILL FAILS am_test_vme 
   - remove AMboard #4 and plug AMboard #28 (from spare cabinet) 
     into slot 10 
   - tag Amboard #4 as "bad" and store in spare cabinet 
   - AMboard #28 passes both am_test_vme and am_test_data_loop 
 
- All crates 
   - run standalone diagnostics on all AMboards: OK 
   - update web pages with test results: 
             /svtdaq/amtest/ 
 
N.B.: in order to run SVT diagnostics I had to ask Marco to 
stop SVT monitoring in all crates. Otherwise we keep getting 
"FISION: network protocol error" while running am_test_data_loop. 
This needs to be investigated.</pre>
<!-- Author: Luciano -->



<!-- Date: Wed Feb 13 13:41:15 2002 -->
More backplane studies:<p> 
<b>139040-41</b> L2_TORTURE[2,233]. L1A=23khz, L2A=43hz, 23% dead with 4 buffers in use.  Deadtime all from L2.  Data in TrigMon was the same as yesterday.<p> 
<b>139052</b> PHYSICS_0_04[5,260].  L1A=3khz, L2A=230hz, 99% dead with 4 full buffers.  No deadtime from L2.  No data errors in TrigMon.<p> 
Moved XTRPlist, SVTlist, Clist, and L1int to the lower crate.  Kept the standard firmware in all boards.<p> 
<b>139063</b> l2exe/L2_TORTURE_v-3_L2Auto loaded with alpha_nots_linux.  No L2 processors.  Readout on.  In TrigMon, SVTlist, Clist, and L1int had no errors.  All the data from XTRP was 0 in TL2D.<p> 
Put everything back in b0l2de00, and checked that everything was okay again with run 139064 (L2_TORTURE).
<!-- Author: Matt -->


<!-- Date: Wed Feb 13 20:50:28 2002 -->
<pre>Reces trigger test: 
 
 
 (1) Test to send the trigger threshold from TriggerDB -&gt; 
     run controll -&gt; SMXR. Basically it works, but still some  
     bugs to be fixed. 
 
 (2) Make trigger table ELECTRON_RECES_TEST_v4. Generated  
     L2 header file is almost ok, but one problem to be fixed. 
     Needed to compile the L2 executable by my hand, since 
     I didn't update the official area. 
 
 (3) Test the trigger table ELECTRON_RECES_TEST_v4, no beam. 
     Needed to load the l2exe by my hand. Run 139138,  
     I compare the trigger rate between the Old (Photon) 
     and new (PhotonReces) trigger rate (spike) 
 
    Old      L2_EM12_ISO              3005 events 
    New      L2_RECES_EM12_ISO_NOCES  3005 events 
 
 
 
 I think it's ready for testing with beam</pre>
<!-- Author: masa -->


<!-- Date: Wed Feb 13 20:54:34 2002 -->
<pre> 
Messenger: processStatechange Config [0] 
Slot 12: 00000000000000000000000000000000 
Messenger: processReadoutlist 
TRIG: Closing MyTrig slot: 
 3 
TRACER: Closing MyTRACER 
Set FER_GLOB_Delay to 0 
Crate Id         151 
Output-&gt;EVB/VRB  0/2 
Trigger mode     2 
Verbosity:       Minimal 
Mode             0  (RE 0) 
 
TRACER: VISIONopen Name=geo32:/slot=2 
Init for runtype 1 
Configuring L2 Processor in slot 3  
Executable file name: l2exe/L2_TORTURE_v-3_B0L2PR00  
========&gt;&gt;&gt;&gt;&gt; CLIST begin  
Writing 0x1 to address 0x40030c in slot 14  
FISION: S_errno_EIO (0x5): VME BERR received! 
========&lt;&lt;&lt;&lt;&lt; CLIST end  
TRIG: VISIONopen Name=geo32:/slot=3 
Cannot configure readout - check readout list. 
Readout process not started. Error status: 1 
Enabling TAXI to send data to VRB 
Error Processing Readout List ! 
Sent ack to Run Control: 0 ERROR ERROR  
ID PROM check failure in slot 2 (ASCII blank)  
No connection to tracer  
Statechange failed  
Messenger: processStat</pre>
<!-- Author: hray -->
<!-- Comment: Wed Feb 13 21;00;35 comment by...hray (and matt in spirit) -->
Trying to test CLIST spare SN 2 yet again.  Yet again it will not work/causes disruptions in the l2de00 crate which will not allow us to run.  Three times I tried powercycling the crate and reseating the clist.  All three times the crate fails CS.  The above message is from the vxlogin to the crate.  In RC the error logger gives the following messages:  ID PROM check failure in slot 2.  No connection to tracer.  I powercycle once more to put the old SN1 back in and voila! the crate now passes CS fine.  For comparison, below I have the snippit of vxlogin stuff that spews on CS.  During the problems with SN2 I opened cdfvme package and read address x70400328.  It showed xfff...7f.  We should see ...e000 for this address.  This is a definate sign of once more the VME not working properly here but fine in Michigan.


<!-- Date: Wed Feb 13 21:01:06 2002 -->
<pre>Messenger: processStatechange Config [0] 
Slot  2: 0030 001 TRACER__V2.1A           
Slot  3: 1234 025L2PROC                   
Slot 12: 00000000000000000000000000000000 
Messenger: processReadoutlist 
Set FER_GLOB_Delay to 0 
Crate Id         151 
Output-&gt;EVB/VRB  0/2 
Trigger mode     2 
Verbosity:       Minimal 
Mode             0  (RE 0) 
 
TRACER: VISIONopen Name=geo32:/slot=2 
TRACER: done enabled 
TRACER: select VRB busy 
Init for runtype 1 
Configuring L2 Processor in slot 3  
Executable file name: l2exe/L2_TORTURE_v-3_B0L2PR00  
========&gt;&gt;&gt;&gt;&gt; CLIST begin  
Writing 0x1 to address 0x40030c in slot 14  
FISION: S_errno_EIO (0x5): VME BERR received! 
========&lt;&lt;&lt;&lt;&lt; CLIST end  
Allocating memory for readout  
TRIG: VISIONopen Name=geo32:/slot=3 
Interrupt mode enabled.  Level 2 vector 0x2 
Enabling TAXI to send data to VRB 
Sent ack to Run Control: 0 READY SUCCESS  
</pre>
<!-- Author: hray -->


<!-- Date: Thu Feb 14 16:41:07 2002 -->
mt and I reprogramed dcas fram to implement the had/em cut.  we took a few runs but are still having problems looking at files in the look area.  we're waiting for pasha for help.  we finally with lots of help from arnd got the cdfvme packages up to snuff, and have reposited the most recent files for dcas/l2cal/clique/locos.  mt thinks she knows why the vme is having problems with spare clist.  she will take it back to michigan tomorrow and someone else will bring the other spare clist that is now in michigan that has these changes made  to it here tomorrow and I will test it this  weekend.   
  
<!-- Author: hray and mt -->


<!-- Date: Thu Feb 14 18:54:08 2002 -->
<h3>Updated CVS REPOSITORY!</h3> 
<br> 
I am about to reset the cvs repository in the default area to the head of 
the repo. This will mean that all trigger tables built from now on have the 
new error code and all other changes that we have made for a while.<br> 
<br> 
The last trigger table with the old state of the repo will be PHYSICS_0_04 
v6. The first with the new one is PHYSICS_0_04 v7. The cvs tag for this is 
PHYSICS_04_07 for all files <i>except</i> run.cc which is the revision 1.28 
(don't ask.) &nbsp;The tag corresponds to the head of the repository as of 
last night at 8.50PM local time. The current code has the following setup:<br> 
<ul> 
  <li>isolist, clist sync errors where the buffer number in each cluster 
is checked</li> 
  <li>SVT-XFT BC mismatches produce sync errors</li> 
  <li>L1Int sends != 1 word produces error</li> 
</ul> 
So there are no warnings currently enabled. &nbsp;Also, we are no longer 
busy-looping to generate a L2 timeout but instead sending a L2Timeout directly 
to the TS when we detect an error (rather than a L2A or an L2R). <br> 
<br> 
I have recompiled the following trigger tables by hand: 
<ul> 
  <li>MINIMUM_BIAS_1 v5</li> 
  <li>Cosmics_All v2</li> 
  <li>COMSICS_NOTRACKS v3</li> 
  <li>L2_TORTURE v3<br> 
  </li> 
</ul> 
I need to recompile them as the format of the message that gets passed between 
run control and the alpha has changed, so Arnd and I needed to coordinate 
the change. &nbsp;The old executables will be there with the name _oldErrors 
appended to it. <br> 
<br> 
Please let me know if there are any trigger tables I missed.<br> 
<br> 
I have also <b>updated the cvs repository from the head</b>, keeping the 
old directories there with an _feb14 appended to them.<br> 
<br> 
<br>
<!-- Author: Peter Wittich -->


<!-- Date: Thu Feb 14 19:56:53 2002 -->
<pre> L2 new electron/photon trigger (CentralElectronReces 
and PhotonReces). 
 
 Uprates:  
    handle of the eta tower and xft curvature boundary 
    Reces triggers 
 
 Run 139176: ELECTRON_RECES_TEST_NOSPIKES_v5 
 
 Trigger rate in nb 
 
                old     new    ces 1GeV   ces 3 GeV 
2 GeV 2e        1519   1519     256        -- 
4 GeV e         2433   2433    1365       728       
4 geV 2e         878    878     351       204 
8 GeV e          898    898     665       513 
16 GeV e         170    170     138       114 
12 GeV isog     2044   2044      --      1763 
20 GeV plugg     119    119      --        --     
10 GeV 3g         ??    1.2      --       1.2   
 
 I forgot to put 10 GeV triphoton-old in the trigger table... 
Otherwise the old and new trigger rates show 100% agreement. 
The reductions of the Reces trigger are close to the  
expectation (2-3 for single e and 5-10 for dielectron).  
Need to optimize the trigger threshold by looking at  
the data offline. 
 
 I think it is ready to put the new electron/photon 
triggers in the physics trigger table for further test. 
  
</pre>
<!-- Author: masa -->


<!-- Date: Sat Feb 16 12:13:46 2002 -->
SVT was paged at 22:00 (2/15) because of 15% dead time, mostly 
from L2.  Ace checked SVT processing time, found a pretty flat 
distribution, with mean ~ 200usec.  I wasn't near a terminal, 
so couldn't run script to determine which ladder was responsible. 
Ace tried a cold start, which made the problem go away (presumably by re-initializing the SVX ladder in question).  
<!-- Author: Bill -->


<!-- Date: Sat Feb 16 19:17:41 2002 -->
b0svt06 DTO during physics run; failed to H/R/R.  Ace 
reset crate.  Run continued OK with single crate transitions.  
<!-- Author: Bill -->
<!-- Comment: Sat Feb 16 19;23;29 comment by...Bill -->
<pre>b0svt06's last words were:

SVTMON -&gt; Reading spy buff      free 120066400 max 115349824 in 691 blocks: 145s
SVTMON -&gt; Sending spydumps(SS)  free 120067424 max 115349824 in 689 blocks: 142s
SVTMON -&gt; Sending histos (SS)   free 120067424 max 115349824 in 689 blocks: 143s
SVTMON -&gt; sent all histo msg
SVTMON -&gt; Sending Status msg  free 120586592 max 115349824 in 685 blocks: 15540s

This is followed by

Attaching network interface dc0... done.
Attaching network interface lo0... done.

evidently after ace did reset_crate


</pre>

<!-- Comment: Sat Feb 16 19;24;06 comment by...Bill -->
Arnd suggests that we ought to add time stamps to these
print statements.


<!-- Comment: Sat Feb 16 19;28;10 comment by...Bill -->
The previous crash was b0svt01 at 09:15 on Feb 15.


<!-- Comment: Sat Feb 16 19;30;56 comment by...Bill -->
Before that, it was b0svt03 at 10:55 on Feb 14.



<!-- Date: Sun Feb 17 00:17:40 2002 -->
Arnd and I disabled VxMon messages (typically every 10 sec) 
on b0svt0*, using 'memset(monconfig+4,0,1)', to see whether 
conflict between smartsockets messages from the two threads 
was the cause of SVT crashes.  This was around 20:00.  At 
00:10, b0svt04 became unresponsive.  I rebooted it and guided 
the Ace through the appropriate magical sequence of single-crate  
state transitions.  We're back on the air.  
<!-- Author: Bill -->


<!-- Date: Sun Feb 17 19:04:21 2002 -->
<pre>b0svt01 crashed at 18:00 and again at 19:00.  We did not 
re-disable VxMon between the two crashes.  In both cases, 
its last words were 
 
SVTMON -&gt; Sending spydumps(SS)  free 115031664 max 108519528 in 881 blocks: 485s 
 
SVTMON -&gt; Sending spydumps(SS)  free 114391328 max 108263704 in 791 blocks: 488s 
</pre>
<!-- Author: Bill -->
<!-- Comment: Sun Feb 17 19;07;29 comment by...bill -->
aha, we must have been repartitioned since the last time a
crate crashed, because I see that vxmon is enabled in all
of the crates ...


<!-- Comment: Mon Feb 18 01;45;21 comment by...Marco  -->
We can't judge yet on the effect of not having vxspymon messages going around. On the other hand from the latest crashes I saw <br>
2 occurence while sending a "dump" message (b0svt01)   <br>
1     "     while sending a "status" message (b0svt06)  <br>
1     "     while sending a "histo" message  (b0svt04)  <br>

As expected SVT crates seems to crash while managing various smartsocket messages and not in various vme readout/data manipulation.<br>
With all the crates now rebooted we might expect a lower rate
of crashes "while sending dumps" since SPYMON avoids large messages unless there is an SVT_ERROR/SVT_FREEZE.


<!-- Date: Mon Feb 18 09:14:11 2002 -->
Currently, SVT mean processing time is about 150 usec, even 
though I see no source of long readout times from SVX 
(except in W4B0B1, which is disabled at the Merger board). 
Interesting. 
<p> 
In other news, b0svt04 just crashed.  I think it takes each 
Ace a few tries to learn the magic incantation needed to reset 
an individual crate in the middle of a run.  I led him through 
it, and it was OK. 
<p> 
  
<!-- Author: Bill -->


<!-- Date: Mon Feb 18 10:13:14 2002 -->
<pre>Arnd points out that we hadn't disabled monconfig-&gt;sendStatus. 
(We were disabling monconfig-&gt;sendMonitorII only.)  Did that 
now, too.  Also, removed DTO and accompanying FER error  
message for BC mismatch; replaced with CDF error from b0svt06. 
(It doesn't happen much these days, anyway.) 
 
Let's see if we still crash when there's only one source of 
smartsockets messages on the crate ... 
</pre>
<!-- Author: Bill -->


<!-- Date: Mon Feb 18 19:57:47 2002 -->
An amusing thing just happened: SVT started the run (139367) 
with the wrong beam spot.  Unfortunately, it was off by only 
about 300 microns, not the few mm it used to be off by, so 
every track was in the 100um-1000um sweet spot, causing a 
big L2A fraction, and hence 50% dead time, for the first few 
minutes of the run, until SVT found the beam, and then the 
dead time abruptly fell to a couple of percent.  Fun! 
<p> 
I just made non-volatile the volatile changes to the Hit 
Finder "boot" chip that I made a couple of weeks ago, which 
allows us to read out the SVX ladder-by-ladder readout times. 
I did this so that I could swap a couple of boards and not 
have them have the wrong firmware.  This is loaded in the 42 
boards that are in the production SVT crates, but no others 
for now.  (This has no effect on data processing, just  
monitoring.) 
<p> 
I just ran 14K events from yesterday (run 139299) through svtsim, 
and found that 35/14000 = 0.25% of events have some kind of 
SVT/svtsim disagreement.  The mismatches typically look like a 
cluster that is displaced by a fraction of a strip, i.e. as if 
the charge were read out incorrectly.  I see that this happens 
in only a few SVX wedges: SB0W7, SB1WA, SB2W7, SB3W7, SB4W3, SB4W6, SB4WB, SB5WB, with SB2W7 and SB4W3 dominating the 
mismatches. 
<p> 
Just to check the possibility that these may be HF board 
problems, I made two swaps: hf_w11_b4b5 (was SN 40, now SN 42) with hf_w11_b2b3 (was SN 42, now SN 40), and hf_w03_b4b5 (was 
SN 32, now SN 33) with hf_w03_b2b3 (was SN 33, now SN 32). 
<p>  
<!-- Author: Bill -->
<!-- Comment: Tue Feb 19 12;00;57 comment by...Bill -->
The pattern of mismatches did not change after moving boards
around (fortunately!).  The search continues ....


<!-- Date: Mon Feb 18 22:54:32 2002 -->
b0svt00 crashed at 20:50.  Muge expertly reset the crate 
and guided it through the appropriate sequence of 
single-crate transitions, keeping the run intact.  
<!-- Author: Bill -->


<!-- Date: Tue Feb 19 09:42:45 2002 -->
I tried to set the clock on the alpha in the lower crate. It looks like either the boot prom code or the hardware has a y2k bug: 
 
<pre> 
AlphaPC164> date 991231235900  
AlphaPC164> date  
Dec 31 23:59:01 1999  
AlphaPC164> date  
Dec 31 23:59:29 1999  
AlphaPC164> date  
Dec 31 23:59:47 1999  
AlphaPC164> date  
Aug 18 06:28:31 19133  
</pre> 
Hmmm.... :) Not a serious problem, but somewhat amusing.
<!-- Author: Peter Wittich -->



<!-- Date: Tue Feb 19 14:40:31 2002 -->
Tested spare CLIST SN3 today.  Good news is that it ran/we got data.  Bad news is that of course it now needs to be debugged - CLIST TrigMon plots not on the diagonal.  *sigh*.  See <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=149&frame=2&anchor=14:17:36'> 
shift elog 
 </a> 
 
  
<!-- Author: hray, natalia -->


<!-- Date: Wed Feb 20 00:19:39 2002 -->
<pre>Last few days' SVT crate crash history (from errmon, but it 
correlates well with Marco's list): 
 
2/19 06:02 run 139375 b0svt05 
2/18 21:32 run 139269 b0svt04 
2/18 20:49 run 139369 b0svt00 
2/18 09:08 run 139339 b0svt04 
2/18 02:50 run 139336 b0svt06 
2/17 18:53 run 139302 b0svt01 
2/17 00:12 run 139278 b0svt04 
2/16 19:04 run 139277 b0svt06 
</pre>
<!-- Author: Bill -->


<!-- Date: Wed Feb 20 13:55:08 2002 -->
We just did a test of the fiber splitting concept, with CLIST. 
We borrowed a 2-to-4 splitter from the SVT test stand (same  
kind used for G-links in SVX readout) and inserted splitter plus 
about 10 nsec length of extra fiber in the middle of the two 
upper CLIST input fibers.  The effects on CLIST should be 
(a) data arrive about 10 nsec later and (b) the light intensity 
should be about a factor of 2 lower. 
<p> 
We started a run with PHYSICS_1_01[1,265], and TrigMon showed 
us its happy diagonal lines for the CLIST data.  (Before that, 
we started a run with a test table, and saw some messages about 
"unknown client" that we didn't recognize.  Matt thought this 
was probably a software issue, though it's odd that it would  
have changed in the past 10 minutes.) 
<p> 
So we think it is probably feasible to use SVX-style optical 
splitters for the various L2 optical inputs.  It may be 
interesting to test this at high rate toward the end of a store. 
<p> 
  
<!-- Author: Heather and Bill -->


<!-- Date: Wed Feb 20 18:25:55 2002 -->
Now, after approximately 38.64 usec, every SVT Hit Finder will 
ignore whatever remains of its input data, which after such a 
long time is bound to be junk.  In the test stand, this 
behaved as expected.  We're going to try a cosmics run in a bit, 
to make sure the real system is OK with this change.  
<!-- Author: Bill -->


<!-- Date: Wed Feb 20 20:08:44 2002 -->
Backplane Wednesday.<p> 
The plan:<br> 
1) run with 1 alpha and 2 tracklist boards with delays. study.<br> 
2) repeat (1) with delays removed.  do this for fun and posterity.<br> 
3) move all interface boards (except reces) to bottom crate.  make similar test as before but with alpha cutting and completing handshake with the TS.<p> 
Some preliminaries:<br> 
 We found that the L2exe loaded with the "alpha_nots_linux" command, L2_TORTURE_v-3_L2Auto, was not compatible with the new error handling code.  The outcome of this problem was that the alpha would report 10^8 errors to the crate processor, which would then try and print all the messages to the minicom screen.  This then required a power cycle of the crate to get the crate processor back. Stephen has "recompiled the L2_TORTURE_v-3_L2Auto to work with the new error handling code. This exe zeros out the error registers, but doesn't actually check for errors."  But we haven't tried to run it since he made the change.<p> 
We also found that the default running L2_TORTURE expects to readout reces.  If reces is not in the crate, the alpha seems to stop and wait, and the L2 timeout is pulled, but <i>without</i> an associated message from the error handling code in the alpha or crate minicoms.  Stephen recompiled the L2_TORTURE exe so that we could run without reces in the lower crate.  However, we later observed similar behavior with the TEST_TWO_TRACK table when we tried to run it with Nathan Eddy towards the end of our tests.<p> 
The results from each test are explained below with the relevant plots attached.
<!-- Author: Greg, Natalia, Heather, Matt -->


<!-- Date: Wed Feb 20 20:11:14 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-575&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-575' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-576&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-576' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-577&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-577' width='300'></a></center>
<!-- Author: Greg, et al. -->
<!-- Comment: Wed Feb 20 20;28;15 comment by...Greg, et al. -->
<b> Step 1</b><br>
We successfully ran in b0l2de01 with SVTlist7 sending fake SVT tracks and XTRPlist3 sending fake XTRP tracks.  We used L2_TORTURE_v-3_BOL2PR00 with the alpha interacting normally with the TS.  All that is required is to book b0l2de01 instead of 00, and the hardware DB correctly determines to which alpha to listen.  We ran with the entire trigger and calorimeter, and SVT, XTRP, and the scalers.  L2AutoAccept = 1.  Runs 139458-65.<p>
The first plot is the signals from directly on the backplane, with the standard termination card.  Bossgrout is taken from SVTlist's slot 12.  The others are spread out in different slots between 20 and 12.<p>
Natalia then modified one of the termination cards with testpoints to have the crucial testpoints on the back of the card, so that we could put scope probes on while plugged into slot 21.  Three of the 8-testpoint sets were moved.  The second plot is the signals from the backplane, without moving scope probes, with the modified termination card.<p>
The third plot is the same signals (minus start_load, which was not on the moved testpoints) with the probes on the termination card testpoints.<br>


<!-- Date: Wed Feb 20 20:30:10 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-578&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-578' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-579&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-579' width='300'></a></center>
<!-- Author: Greg, et al. -->
<!-- Comment: Wed Feb 20 20;32;12 comment by...Greg, et al. -->
<b>Step 2</b><br>
No delays.  Can you tell the good plot from the bad?<br>


<!-- Date: Wed Feb 20 20:33:08 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-580&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-580' width='300'></a></center>
<!-- Author: Greg, et al. -->
<!-- Comment: Wed Feb 20 20;39;00 comment by...Greg, et al. -->
<b>Step 2, continued</b><br>
To give you an idea of the rate of collisions in the board addresses.  A rate of about 1/20 collisions was confirmed by manually triggering the scope on the backplane and counting the bad events.  At this point we were running with a L1A = L2A rate of 340 Hz.<br>


<!-- Date: Wed Feb 20 20:53:50 2002 -->
<b>Step 3</b><br> 
Now we took L2 torture runs with all boards except Reces in b0l2de01, interacting normally with the TS.  The following runs were taken with the standard L2 torture test: L2_TORTURE_v-3, the full trigger and calorimeter, and SVT and XTRP sending fake tracks.  A hot PEM tower in the ADMEMs (eta 6, phi 22) also contributed by causing Clist and ISOlist to see 3 clusters/event.  The boards (slots) were: XTRPlist3 (9), L1int (10), SVTlist07 (12), Clist (14), ISOlist (20).<p> 
139468.  Tagging.  L1A = L2A = 340 Hz; no errors in TrigMon or the error handling code.<br> 
139471.  Tagging.  Same as previous.<br> 
139472.  Cutting.  L1A = 400 Hz, L2A = 340 Hz.  The L1A rate was limited by the hot PEM tower, which caused all the events to pass L2 and L3, resulting in a huge deadtime in the TS and a low L1A rate.  No errors in TrigMon/error handler.<br> 
139473.  Cutting.  Removed the PCAL with the hot tower.  L1A = 22 kHz, L2A = 55 Hz, 16% dead (all from L2).  These are the usual numbers from L2_TORTURE.  No errors in TrigMon/error handler.<p> 
We put the upper crate back together and took run 139476 with b0l2de00 and the SEVB (HEVB died) and the usual L2 torture configuration.  No errors in TrigMon/error handler.
<!-- Author: Greg, et al. -->


<!-- Date: Wed Feb 20 23:59:48 2002 -->
I am running DAQ and SVTSPYMON on the tracking crate of SVT 
(b0svt00 - b0svt05 ) to test hypothesis on the SVT crate crashes.  
Crates svt06 and svt07 are free.
<!-- Author: Marco  -->
<!-- Comment: Thu Feb 21 16;23;52 comment by...Marco  -->
Well, I think we are in a better shape now! <Br><hr>
<font color =red>
350 Million events collected in one night where the readout code running over 8 Khz and SPYMON looping more than 3000 times sending > 100 histograms on smartosocket at each iteration. </font>




<!-- Date: Thu Feb 21 18:01:53 2002 -->
<pre>Results of tests on spare CLIST sno 3 using fully loaded top crate and L2_TORTURE_PHOTON table (only some of CCAL frontend calorimeter crates booked, plus usual L1CAL, L2CAL, TS and ALPHA). 
 
run 139570 with CLIST sno 3 and new PROM sync_8_2 (same firmware as in working CLIST sno 1, sync_8_1, plus fix for reset logic). 
My validation code reports cluster mismatch errors for CLIST plus a lot of enerby bits errors for L1_Interface. 
 
run 139579 with CLIST SNO 3 and sync_8_2 after removing decoupling capacitors on BOSS and BOSSREQ. Same errors reported. 
 
run 139583 with CLIST SNO 1 and sync_8_1 (i.e. old working CLIST with old working firmware). Same kinds of errors reported! 
 
For all of these runs the MB backplane signals on the scope look fine, as well as no errors seen in Alpha minicom window. Talked to Steve Miller; not completely clear whether the Monitor code should work in RC for this table. I can't do a more complete test using L2_TORTURE table because I don't have all of the needed frontend crates. 
 
I conclude that CLIST SNO 3 needs to be tested with crate in more "stable" conditions.</pre>
<!-- Author: monica -->


<!-- Date: Fri Feb 22 14:40:52 2002 -->
<pre>Two TTL modified boards back from prep. 
Alpha rev. D-1. 
Tracklist #3.</pre>
<!-- Author: Matt, Greg, Peter -->


<!-- Date: Fri Feb 22 17:46:04 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-582&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-582  width='300' align='top'></td><td>As a point of comparison, this trace was taken from the  testpoints on the breakout board in b0l2de00, with the  original magic bus an the crate sending data as normal in  a L2 torture test.  I tried to keep all scales the same as  those during the new backplane studies on Wed.  The noise  in this plot looks a little worse than seen on the new magic  bus.  However, the comparison is not exact, because those  traces had only 2 tracklist + 1 alpha sending data, while  this crate is fully loaded.</a></td></tr></table>
<!-- Author: Matt -->


<!-- Date: Fri Feb 22 19:04:29 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-583&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-583' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-584&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-584' width='300'></a></center>
<!-- Author: Natalia, Matt -->
<!-- Comment: Fri Feb 22 19;35;29 comment by...Matt -->
Various arbitration signals from the TTL modified tracklist (XTRPlist03) to the TTL modified alpha (D-1).  Took two runs with the usual torture test setup: L2_TORTURE[3,233]; L2AutoAccept = 1; full CAL and trigger system:<p>
<b>135693</b>  xtrplist03 in sync the entire run.  L1A = L2A = 211 Hz.  99% dead, all deadtime as usual from TS and r/o.<br>
<b>135696</b>  extra 1 = 1.  All rates and deadtime the same.  Only 1 error seen in TrigMon: xtrp segment bit 0 mismatches, but not in every track.  We saw something like this before in pT when the error was coming from a single xtrp board.  I had the shift crew run extra1 = 1 in their cosmic runs with the upper crate and xtrplist05 immediately afterword.  The errors were still there (at least in run 139699).<p>
Finally, we put alpha D-2 back into the lower crate.


<!-- Comment: Mon Feb 25 14;34;59 comment by...Matt -->
Some notes on these signals.  All traces were taken from the modified breakout board in slot 21.  Also, the TTL PAL on XTRPlist03 does not yet have the 0.1 uF decoupling caps.
<!-- Date: Sun Feb 24 00:56:09 2002 -->
SVT vs svtsim: 
<p> 
Looked at 25K events from runs 139369,70. 
<p> 
0.33% of events have a mismatch (where denom = events having at least one SVT track).  0.14% of tracks have a mismatch.  Most of these are in SB3W4 and SB2W7. 
<p> 
Hand scan of svtsim intermediate data reveals that most of these are due to strip numbers out of order.  Fixed a bug in Hit Finder emulation for out-of-order strips.  This cures 57% of mismatching tracks. 
<p> 
Of remaining mismatches (0.06% of tracks), 90% are in SB4W3.  Hand scan shows this is always a L0 mismatch, where hit coordinate is 
off by a fraction of a strip. 
<p> 
Went back to run 139299, before hf_w03_b4b5 and hf_w03_b2b3 were 
interchanged.  The problem did not move with the Hit Finder. 
<p> 
The chisq distributions for the data tracks and the svtsim tracks 
both seem reasonable (no big difference), so it's not easy to tell whether the problem is on the SVT or the SVX/VRB side of 
the fiber split. 
<p> 
I guess next time I'm in B0, I'll try exchanging the VTM, and if 
that doesn't work, I'll see if Steve Nahn wants to exchange the  
corresponding VRB. 
<p>  
<!-- Author: Bill -->


<!-- Date: Sun Feb 24 18:06:50 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-585&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-585  width='300' align='top'></td><td>Here's the feature near phi=0 that Marco noticed in  January, back when we had much more urgent worries. It's still here.  This plot is TF phi vs OBSP phi in GEANT single muons run through svtsim, for about a +- 5 degree range in phi.</a></td></tr></table>
<!-- Author: Bill -->


<!-- Date: Mon Feb 25 14:09:20 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-587&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-587  width='300' align='top'></td><td> </a></td></tr></table>
<!-- Author: Stephen -->
<!-- Comment: Mon Feb 25 14;11;05 comment by...Stephen -->
<pre>TTl arbitration test at Michigan. Alphas in slots 3 and 6.
Clist sending from slot 13.
Scope probes are on backplane at locations
boss slot12
bossreq slot 19
bossgrin slot 13
</pre>


<!-- Date: Mon Feb 25 14:12:05 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-588&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-588  width='300' align='top'></td><td>Same setup as above</a></td></tr></table>
<!-- Author: Stephen -->


<!-- Date: Mon Feb 25 14:13:15 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-590&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-590  width='300' align='top'></td><td>Dstrobe driven by Clist. Dstrobe measured at slot 6</a></td></tr></table>
<!-- Author: Stephen -->



<!-- Date: Mon Feb 25 16:35:21 2002 -->
<pre>Modified the new magic bus termination card  
(i.e. the one without breakout pins and with  
bossgrout jumpered to bosgrin) to remove the  
termination on the BOSS and BOSSREQUEST lines. 
The traces from the P3 to the sip were cut for 
these two signals as close to the P3 as possible. 
Matt has labeld the card appropriately. 
------------------------------------------------- 
The second termination card also  now dedicated to the  
lower crate (with breakout pins) has not yet been 
modified as this will be a more complicated operation. 
</pre>
<!-- Author: Greg and Matt -->


<!-- Date: Mon Feb 25 18:05:38 2002 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-591&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-591' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-592&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-592' width='300'></a></center>
<!-- Author: Greg and Matt -->
<!-- Comment: Mon Feb 25 18;28;18 comment by...Greg and Matt -->
Using the termination board with the cut traces between the P3 connector and the BOSS (S29, pin 5) and BOSSREQ (S29, pin 6) termination, in slot 21.  Both of these captures are from the same scope trigger.  1 Alpha in slot 3, 1 tracklist in slot 9.<p>
BOSS from slot 8, <br>
BOSSGRIN from slot 9, <br>
DSTROBE from slot 6 and <br>
BOSSREQ from slot 19.<p>
Still see the roughly 30 ns rise time on boss and bossreq, plus some large ringing and noise.  These are from the 7407 drivers on tracklist that only sink 40mA.  Dstrobe now looks much better, the culprit was probably an ungrounded scope trace.

<!-- Comment: Mon Feb 25 18;54;27 comment by...Greg and Matt -->
On the backplane, in slot 9, we looked at the EVLOADED signals from tracklist03.  These signal come from drivers (7406) that have the same 40 mA sink that the BOSS drivers do.  However, we didn't see anything like the long rise time and ringing that was observed on BOSS and BOSSREQ.

<!-- Comment: Tue Feb 26 08;27;03 comment by...Stephen -->
<pre>Note that the 74f07 chips can sink 64mA, so the 7407 can always
be replaced by those.</pre>


<!-- Date: Tue Feb 26 16:03:18 2002 -->
<pre>Picked up 2 TTL modified Tracklist cards from  
PREP. #3 was previously modified and has had  
extra bypass capacitors added near the PAL. 
#7 has the (now) full TTL modification. 
Beginning tests in bottom crate ...</pre>
<!-- Author: Matt and Greg  -->


<!-- Date: Tue Feb 26 19:27:18 2002 -->
We couldn't complete the TTL tests with 2 tracklists in the lower crate, because it appears that XTRPlist03 - the tracklist board first modified - occasionally causes large noise on BOSSGRIN and takes BOSS several times in one event.  The frequency of this was roughly 1 in 3 events, just looking on the scope.  Each time it takes BOSS, it sends at least 1 dstrobe.  See below for an example of a "multiple BOSS grabbing" event.  Inexplicably, in TrigMon the board NEVER loses sync as expected when this occurs.  It's almost as if the board takes and releases BOSS each time it needs to send a dstrobe for that event.<p> 
This happens even when the board is alone in the b0l2de01 crate with only 1 alpha.  This was not observed Friday when this was the only board being tested.  The only change to this board since is the addition of the decoupling caps on the PAL.  The newly modified board - SVTlist07, also with the decoupling caps - was tested alone in the same slot (9) as XTRPlist03 and did not show any of this bad behavior.<p> 
We'll check XTRPlist03 in detail tomorrow for any errors added to the TTL mod in prep today.  
<!-- Author: Greg, Natalia, and Matt -->


<!-- Date: Tue Feb 26 19:33:05 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-593&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-593  width='300' align='top'></td><td>XTRPlist03 grabbing BOSS several times in one START_LOAD.   The scope probes are directly on the backplane: boss slot  11, bossgrin slot 9, dstrobe slot 10, bossreq slot 13.   This is with 1 alpha and XTRPlist in slot 9.  No other boards  in the crate.  Events where this board took BOSS as normal  and sent 2 dstrobes without the large noise on BOSSGRIN or  the releasing of BOSS in between were clearly seen in this  run as well.</a></td></tr></table>
<!-- Author: Greg -->


<!-- Date: Wed Feb 27 17:44:51 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-595&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-595  width='300' align='top'></td><td>  </a></td></tr></table>
<!-- Author: Matt, Stephen -->
<!-- Comment: Wed Feb 27 17;58;35 comment by...Stephen -->
<pre>TTL Arbitration test with 2 tracklist boards and 1 alpha in
bottom crate.
Tracklist SN-3 in slot 9 and SVtlist SN-7 in slot 14.
Signals are in slots
bossreq slot 13
boss slot 11
bossgrin(is really bossgrout) in slot 9
(dstrobe is mislabeled for this picture)
Several features to note:
1. The  spike on the first bossreq is not passed on by tracklist
as bossgrout when tracklist has the bus. This is due to glitch
protection in the firware.
2. The spike on the 2nd bossreq shows up as a spike on bossgrout
from tracklist as the glitch protection is only in place for
when a board has boss. 
3. This is running with a 17us delay for both boards so that
the both request the bus at the same time. Running with no
delay resulted in about a 1us separation between the 2 boards
sending their data.
 </pre>


<!-- Date: Wed Feb 27 18:00:03 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-596&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-596  width='300' align='top'></td><td>The most common error is that a board grabs the bus and doesn't let go. It isn't clear from this picture, why that would happen</a></td></tr></table>
<!-- Author: Matt, Stephen -->
<!-- Comment: Wed Feb 27 18;02;05 comment by...Stephen -->
<pre>This typically happens after several minutes of running.</pre>


<!-- Date: Wed Feb 27 22:04:41 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-597&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-597  width='300' align='top'></td><td>Bossreq(slot 3) Boss (slot 19).  Svtlist is in slot 12 and Tracklist in slot 7 In this case Svtlist gets the bus first, but before boss is fully asserted, Tracklist sends bossreq and also gets the bus. The end result is both boards getting the bus at the same time. Once we put on the stronger drivers, the time for boss to be fully asserted will decrease. That  should fix this problem.</a></td></tr></table>
<!-- Author: Stephen, Matt -->


<!-- Date: Wed Feb 27 22:07:19 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-598&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-598  width='300' align='top'></td><td>Closeup of a more typical situation where Tracklist gets boss first and so doesn't pass on bossgrout to the next  slot.</a></td></tr></table>
<!-- Author: Stephen, Matt -->


<!-- Date: Wed Feb 27 22:13:21 2002 -->
<pre>One other strange thing. We found that if either of the tracklist 
boards was plugged into any slot 14 or higher, then boss would 
constantly be asserted at power up. Note that it wasn't  
completely at ground, but about 0.5 volts above that.  
We had initially been running with a tracklist in slot 14 just 
fine, but then at some point boss became stuck low. This is 
when we discovered this strange slot dependence. 
Note that boss is adjacent to AP_FIFO_EMPTY which the alpha 
drives low in the power up state. However, we couldn't see any 
obviously bent pins on the backplane.</pre>
<!-- Author: Stephen, Matt -->


<!-- Date: Thu Feb 28 09:27:37 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-599&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-599  width='300' align='top'></td><td>Run 140078. TTL test of L1 (slot 10) and Clist (slot 14) boards. Running L2_Torture with CCAL. Scope picture shows L1 and Clist sending data. TrigMon plots don't show any errors.</a></td></tr></table>
<!-- Author: Stephen, Greg -->


<!-- Date: Thu Feb 28 09:29:49 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-600&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-600  width='300' align='top'></td><td>Cluster validation plot from run 140078. TTL modified CLIST and L1 interface card.</a></td></tr></table>
<!-- Author: Greg, Stephen -->


<!-- Date: Thu Feb 28 10:17:14 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-601&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-601  width='300' align='top'></td><td>TTL modified CLIST performance for run 140081. L1 rate = 23 kHz, L2 rate = 50 Hz</a></td></tr></table>
<!-- Author: Greg -->


<!-- Date: Fri Mar 1 13:37:05 2002 -->
<pre>Added SB3W0L4 to list of ladders masked off in Hit Finders. 
It had an average processing time of ~35usec, i.e. right  
near the cut off of 38usec.  JDL may suggest a few others. 
</pre>
<!-- Author: Bill -->