<!-- Title: 09:23:00  Wed Dec 24 2003 -->
<!-- Crewchief: SVT group -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>New page for new year.</pre>


<!-- Date: Wed Dec 24 09:24:38 2003 -->
<pre>I cleaned up MRG(slot#12) and GB(slot#13) in b0svt06. 
Now these boards are 3rd floor cabinet in top crate (MRG) 
and bottom crate (GB). </pre>
<!-- Author: Taka Maruyama -->
<!-- Comment: Wed Dec 24 09;29;00 comment by...Taka -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Spare boards of GB and SVX resonant monitor is 
in 3rd floor cabinet for SVT cards. 
(I marked which one is for which).
Bottom crate has these guys.
GB board #004 is a spare board for the normal GB functionality
and no number board is for SVX resonant monitor. 
  </pre></td></tr></td></table>

<!-- Comment: Wed Dec 24 09;41;50 comment by...Taka -->
<pre>Cleaned up MRG is labeled in #26 (looks like serial#).
GB was in slot#13 has no label (serial#) in outside.
I need to improve this.</pre>


<!-- Date: Fri Dec 26 19:38:02 2003 -->
<pre>After cleaning up of b0svt06, we have space from slot#9-14 (6 slots 
spaces.) If you would put something, you could put as you wish.</pre>
<!-- Author: Taka -->


<!-- Date: Fri Dec 26 20:08:52 2003 -->
<pre>Currently, we have COSMIC ray run with Silicon. 
But, we don't have any SPYMON histogram data from b0svt00 
to b0svt05. (06 and 07 is OK). 
Spydump files for current run are either not the area which  
we usually use. 
 
 </pre>
<!-- Author: Taka -->
<!-- Comment: Fri Dec 26 20;51;42 comment by...Taka -->
<pre>We had 2 changes for SPYMON:

(1) changes the running location:  b0dap75  --&gt;  b0dap85
(2) CVS commit the svtvme_fer.c and compiled to use it.
(3) Rebooted all crates. (to install updated svtvme_fer.c)

Is it possible??
 


</pre>


<!-- Date: Fri Dec 26 21:25:17 2003 -->
<pre>I found that we still read/write slot#12(MRG) and #13(GB)  
in spymon. One possibility is to have error is that I removed 
MRG and GB without any spymon changing. 
 
actually, if we vxlogined to b0svt06, we have error message like: 
 
 
readword addr 0, opened as geo32:/slot=12 
status = 5 
SVTMON -&gt; MRGregisters returns with error code -5 
SVTMON -&gt; for board = MRG slot 12 readAllReg got rc =-1 
 
readword addr 400018, opened as geo32:/slot=13 
status = 5 
readword addr 400018, opened as geo32:/slot=13 
status = 5 
readword addr 400018, opened as geo32:/slot=13 
status = 5 
readword addr 400018, opened as geo32:/slot=13 
status = 5 
</pre>
<!-- Author: Taka -->


<!-- Date: Sun Dec 28 17:24:30 2003 -->
<pre>Operation maneger wants to recover missing spydumps and ROOT files, 
so that I temporarily enter the MRG (serial#26) board and GB (#004) 
board in b0svt06. 
(Data was taken in missing configuration and it was fine, 
Also, b0svt06 spydumps and SPYMON histograms are OK,  though) 
 
After this action, we recover the spydumps (from b0svt00 to 
b0svt05) and SVTSPYMON histograms, corresponding attached crates. 
We can expect the ROOT files will be OK, too. 
 
However, we need to improve the monitor programs as soon as  
possible since these 2 cards are unnecessary any more in hardware 
configuration. And this improvement is not so diffcult, I guess. 
</pre>
<!-- Author: Taka -->


<!-- Date: Mon Dec 29 01:17:43 2003 -->
A guess for the source of L2 Decision timeout is shown 
<a href= 
'/cgi/elog/elog.pl?nb=2003&action=view&page=1084&frame=2&anchor=08:32:50.990'> 
here </a>.  
(We had sometime strange behavors of L2 in cosmic ray run.) 
 
 
 
<!-- Author: Taka -->


<!-- Date: Tue Dec 30 20:51:00 2003 -->
<pre>This is the information on run#176696 of discrepant events 
between svtsim(top line)/SVTD(bottom line).  
It looks hit information is always  
different each other, but, can we conclude HF has problem??  
 
 
 run   eve   ixft w road  z z h0  h1  h2  h3  h4  phi  crv ip chq tfs 
176696 10269 109  5 977   0 0 725 0   578 600 568 3220 -73 -7  1   4  
                  5 24688 1 0 732 0   578 600 568 3219 -73  2  0   4 
 
176696 26370 114  5 28547 1 0 712 520 760 0   623 3264 -2   1  2   2  
                  5 8643  1 0 712 0   760 742 623 3264 -1  -1  1   4 
 
176696 35539 123  5 1352  1 1 712 0   600 708 584 3377  73 -107 36 4  
                  5 3658  1 1 704 568 600 708 0   3358  87   9  42 1 
 
176696 41268 107  5 7998  1 1 540   0 589 715 562 3182 -88  4  0   4  
                  5 7265  1 1 0   632 589 715 562 3173 -84  40 4   5 
 
176696 52992 123  5 6713  1 1 616 992 616 633 600 3597 -57 30 12 2244  
                  5 2160  1 1 944 992 764 668 584 3623 -66 -6 1  2190 
 
176696 52992 128  5 6385  1 1 0   666 552 568 584 3636  5 -9  2    5  
                  5 4713  1 1 760 800 552 568 584 3639  4 -16 1    4 
 
176696 95052 112  5 246   1 1 547 589 684 579 604 3082 77 -2  5    0  
                  5 7711  1 1 547 0   684 579 604 3083 77 -3  2    4 
 
176696 123289 110 5 10780 0 1 992 588 570 544 612 3112 23 -3 11    5  
                  5 3791  1 1 960 0   570 544 612 3117 22 -8  8   14 
 
176696 123289 111 5 10780 0 1 992 588 570 544 612 3111 30  1  15    5  
                  5 3791  1 1 960 0   570 544 612 3116 29 -6 15   14 
</pre>
<!-- Author: Taka Maruyama -->
<!-- Comment: Tue Dec 30 21;01;42 comment by...Taka Maruyama -->
This is the study for the svtsim/SVTD which is observed in
previous physics run.
<a href=
'/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=12&frame=2&anchor=12:10:20'>
[link here] </a> 



<!-- Date: Wed Dec 31 12:53:49 2003 -->
<pre> 
 
One SVT card in b0svt02 slot#13 (wedge#05, barrel#0 and #1), HitFinder board (serial#16), was swapped 
to serial#22. This board had some strange behaviors in previous physics run. &lt;a href= 
'/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=12&frame=2&anchor=12:10:20'&gt; [link here] &lt;/a&gt; 
And data shows most likely this board is wrong. Swapped card is now in b0svt07 slot#13, temporary. (not 
using now since this is assigned for L00). With internal SVT test, data looks fine. If you have problems in 
b0svt02, please page SVT.  
</pre>
<!-- Author: Taka Maruyama -->
<!-- Comment: Wed Dec 31 12;54;16 comment by...Taka Maruyama -->


One SVT card in b0svt02 slot#13 (wedge#05, barrel#0 and #1), HitFinder board (serial#16), was swapped
to serial#22. This board had some strange behaviors in previous physics run. <a href=
'/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=12&frame=2&anchor=12:10:20'> [link here] </a>
And data shows most likely this board is wrong. Swapped card is now in b0svt07 slot#13, temporary. (not
using now since this is assigned for L00). With internal SVT test, data looks fine. If you have problems in
b0svt02, please page SVT. 



<!-- Date: Thu Jan 1 22:24:37 2004 -->
<pre> After swapping HF of b0svt02 slot#13, we have 2/1000 events  
mismatches between svtsim / SVTD. (e.g. I confirmed this  
using run#177627 data of the first 1000 events: this should  
be followed by daily SVTmon news).  
 
 This is a proper good news for a happy new year. 
 Now, we have almost usual SVT status except L2 decision  
timeouts in lower luminosity, which might be due to L2.     
</pre>
<!-- Author: Taka Maruyama -->
<!-- Comment: Thu Jan  1 22;30;24 comment by...Taka Maruyama -->
<pre> The source of the error in the swapped board (serial#16),
which is now in b0svt07 slot#13, should be investigated.

 </pre>

<!-- Comment: Fri Jan  2 04;59;30 comment by...Taka -->
<pre>I examine 6000 events of #177627 and #177214.
We have 23 events mismatched events.
This means 0.38% level of mismatches is still happened.
 </pre>


<!-- Date: Fri Jan 2 17:58:17 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-177&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-177  width='300' align='top'></a></td><td>SVT failure from daily autoSVT monitor. 
We have three main sources for svtsim/SVTD mismatches. 
We should look the data more. </td></tr></table>
<!-- Author: Taka Maruyama -->
<!-- Comment: Fri Jan  2 17;59;43 comment by...Taka -->
<pre>Daily SVTMon shows we have still 0.6% level svtsim/SVTD mismatches.
(though, normally, we have below 0.2%!!).</pre>


<!-- Date: Sat Jan 3 16:46:53 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-178&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-178  width='300' align='top'></a></td><td>Daily autoSvtMon shows that we still have 0.47% svtsim/SVTD  
mismatches. Here is the mismatch map. 
It seems that the main sources of mismatches is  
W5B0,W5B1 and W10B1. We changed HF for W5B0 and B1, and got 
one order smaller mismatches in these parts, however it is 
still dominant one. </td></tr></table>
<!-- Author: Taka Maruyama -->


<!-- Date: Mon Jan 5 22:12:06 2004 -->
<pre>  In recent runs, we unfortunately prescaled 1/1000 SVT related 
 triggers at the bigining of the run (typically luminosity is 
 from 45E30 to 35E30) since there are following reasons. 
 
  (1) L3 subfarms #1, #2, #16 is out.  (3/16) 
  (2) L3 process time for one event increased after the 
     shutdown. (I heard this from someone, maybe wrong) 
  (3) As a result, deadtime at that time is above the 50% !! 
 
  Solving item(1) is not enough to recover the situation. 
 And item(2) is not sure that we can achieve now. 
 Anyway, our system is almost limit at the half of the design  
 luminosity. 
   
  We plan RoadWorrier to get high purity, and it helps  
 this situation also.  
 </pre>
<!-- Author: Taka Maruyama -->


<!-- Date: Tue Jan 6 01:56:17 2004 -->
 Interesting features for the SVT processing timing is shown 
in 
<a href= 
'/cgi/elog/elog.pl?nb=2004&action=view&page=16&frame=2&anchor=01:34:01.712'> 
main e-log. </a> <br> 
 We have 2 peaks in the distribution. And new 2nd peak  
is appeared after the shutdown at least. I will investigate 
this features.   
<!-- Author: Taka (suggested by Masa) -->
<!-- Comment: Wed Jan  7 07;02;07 comment by...Stefano -->
Looks like the timing problem was due to SVX readout and it has been fixed by 2pm the same day (January 6), see Steve Nahn'a
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=17&frame=2&anchor=14:32:46.872'>
entry</a>
in main e-log.
<!-- Comment: Wed Jan  7 07;20;28 comment by...Taka -->
<pre>Thank you, Stefano.
Thanks to Steve Nann's smooth work, we eliminated this problem.</pre>
<!-- Date: Tue Jan 6 10:28:56 2004 -->
<pre>I found there are very similar SVT tracks in run#177384. 
These uses all same SVX hit information and similar XFT track. 
I show following example:    
 
 run   eve  w road x0  x1 x2 x3  x4    crv      phi    ip   csq z z xft        
177384 2474 7 8585 744 600 0 648 696 0.0002223 3.75825 -0.001 4 0 0 173 
177384 2474 7 8585 744 600 0 648 696 0.0005733 3.75365 0.01  17 0 0 174 
 
Actually, I don't know this is the problem or not. 
Different run data could provide the hints. 
And this might be related to timing issue.</pre>
<!-- Author: Taka -->
<!-- Comment: Tue Jan  6 10;55;03 comment by...Taka -->
<pre>I roughly scanned this run's data.
And such a tracks is only happened less than 5% of events rate.
So, these cannot make a such a large 2nd peak.
 
</pre>


<!-- Comment: Wed Jan  7 07;04;59 comment by...Stefano -->
This does not look a problem. There are two very close XFT tracks that point to same SVX hits. Everythink is legal. And this could also make phyisical sense (e.g. a delta ray in the COT inner can). Of course it could also be and XFT fake, but SVT can not say.

<!-- Comment: Wed Jan  7 07;19;10 comment by...Taka -->
<pre>I see. But, one suggestion is inverse GhostBusting, which means 
we can bust same SVX hits track but has close XFT using chisq,
also. How about it?? Most likely, this is due to fake XFT track.
 </pre>



<!-- Date: Wed Jan 7 08:38:19 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-179&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-179  width='300' align='top'></a></td><td>Recently, W10B1 has serious mismatches. 
I will look the data more to investigate this.</td></tr></table>
<!-- Author: Taka Maruyama -->
<!-- Comment: Wed Jan  7 09;30;45 comment by...Taka -->
<pre>Here is the example of the mismatched data.

mismatch: 177416 84782 232 10 824  1 1 582 557 554 656 0 6642 -22 8 2 1 
                           10 1400 1 1 568 557 554 656 0 6643 -22 2 5 1

mismatch: 177416 84782 233 10 172  1 1 653 700 641 555 518 6574 43 -2 0 0 
                           10 3773 1 1 0 700 641 555 518 6573 43 -5 0 5

mismatch: 177416 84782 236 10 1049 1 1 652 0    733 534 664 6779 -33 0 2 4 
                           10 4874 1 1 632 1008 733 0   664 6782 -34 -14 7 10

mismatch: 177416 84782 237 10 5153 1 1 696 547 737 0   648 6873 -68 -13 13 2 
                           10 25   1 1 0   547 737 603 648 6874 -69 -22 22 5

mismatch: 177416 84782 238 10 8631 1 1 654 0   664 763 520 6695 54 -5 0 4 
                           10 4884 1 1 0   552 664 763 520 6694 53 -11 1 5

mismatch: 177416 84782 242 10 5560 1 1 0   552 648 549 568 6950 -35 -2 6 5 
                           10 320  1 1 648 584 604 600 692 6986 -55 -5 8 0
</pre>

<!-- Comment: Wed Jan  7 09;36;13 comment by...Taka Maruyama -->
<pre>format is 

run   eve   ixft w road  z z h0  h1  h2  h3  h4  phi  crv ip chq tfs 

and top line is SVTD and bottom is svtsim. 
Looks like this is due to the HF error since we have
different hit information in all of the events. </pre>

<!-- Comment: Wed Jan  7 09;57;01 comment by...Taka -->
<pre>roadID distribution looks fine.
</pre>

<!-- Comment: Wed Jan  7 18;19;57 comment by...stefano -->
of course it could also be a problem with the g-link receiver board in the back of the crate, or with the svx readout itself, or the g-link splitter. is this the HF that was swapped already ?
It could be worth to swap with the HF in the next slot, to see if problem moved from barrel 1 to barrel 3 (e.g.) or stays with barrel 1. Of course the other thing to do is to take advantage of the GhostBuster features and connect the spare output of the suspected HF to one spare GB to read hit list in the data in each event, to compare directely with svtsim on SIXD bank. At the same time one would need to get simulataneus dumps of input/output spy buffers from that HF to look for HF problems. If all fails, we can think of more exotic  problems like bad pins in P3 connector in that crate/slot. Doing all of this is probably too much and unrealistic. I suggest to star with swapping the two nearby HF's.


<!-- Comment: Wed Jan  7 19;14;24 comment by...Taka -->
<pre>Of course, I agree the possibility.
But, I already swapped the board.
So, if it stays barrel#1 more, I swapped the board corresponding
to b1 to another one.

Thank you for the suggestion.</pre>


<!-- Date: Wed Jan 7 19:22:49 2004 -->
<pre>I swapped the HF board at b0svt05, slot#4 (serial#48) to  
serial#06 (stayed at b0svt07, slot#15). 
This is to recover the problem mentioned above. 
(W10B1 mismatch problem) 
 
Of course, this could be a problem in other part (fiber signal 
reciever, fiber splitter or SVX readout itself.) as mentioned 
by Stefano. 
But, if this problem stays even after this swapping, problem is 
caused by upstream with 100%C.L.. 
 
We will be able to see the data quite soon.  
 
 
</pre>
<!-- Author: Taka -->
<!-- Comment: Thu Jan  8 03;31;40 comment by...Stefano -->
Thanks Taka.
<p>
It may even be possible to simply swap the fibers
in the back sending SVX data from b0b1 to the HF that
usually process b2b3 and viceversa. Of course merger/am/hb etc will not care, only thing to check is if the HF programming needs
to know which barrel it is processing (so a new hwset is required) or wether it is all transparent. In this way we could learn
something without moving boards around. Moving boards is always unpleasant, also HF has a very delicate P3 connector which is dangerous to touch.


<!-- Date: Thu Jan 8 09:00:43 2004 -->
<pre> Before autoSVTMon coming, I quickly reprocessed the data on  
run#177480. We still have 29event/5598events mismatches (0.52%). 
 
 Out of 29events, W10B1 has 6events(21% of error), and W5B0B1 
has 8events(28%). Therefore, HF swapping reduced the error, 
but error rate is quite similar to that of 1-Jan-2004. 
 
 Now, I think what Stefano suggested is close to truth, 
means that more upstream component of HF has problem. 
This matthers not only error rate but also maybe HF broken since 
we already observed W5B0B1 and W10B1 HF had trouble and has  
been swapped. 
(I am wondering 0.5% is current basic error rate, and this 
wired data broke HFs. and gradually this error rate was  
glowing up.)   
  
 This is only guess, but need quick investigation for this one. 
</pre>
<!-- Author: Taka -->
<!-- Comment: Thu Jan  8 09;27;06 comment by...Taka -->
<pre> I talked with David who is the Silicon expert.

W10B1L0 has small occupant error which send the junk data,
thus this could cause the SVT error. (Also, we can find 
all errors which I mentioned above has L0 problem.)

W5B1 has also small error but does not have W5B0.

Anyway, error rate for SVT could be caused by SVX itself.
</pre>

<!-- Comment: Thu Jan  8 10;35;14 comment by...Stefano -->
<pre>One more reason to investigate the possibility to simply swap SVX filbers in the back of the crate and see what happens. Making a new hwset should be very easy.</pre>


<!-- Date: Fri Jan 9 02:43:48 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030> We have many L2 decision timeout yesterday's evening shift 
(every 5min), but, occupancy of this error is reduced very  
much after Silicon tripping recovery. 
 Now, I could imagine L2DTO would be due to the Silicon itself, 
especially related this tripping related thing. 
 See main e-log for  
<a href= 
'/cgi/elog/elog.pl?nb=2004&action=view&page=25&frame=2&anchor=00:57:31.231'> 
[here] </a> <br>  
</td></tr></td></table>
<!-- Author: Taka Maruyama -->
<!-- Comment: Fri Jan  9 03;50;14 comment by...Taka -->
<pre> This time tripping place is B0W5, which we are observing the 
mismatches anytime. Seems that it could send the data out of timing. Interesting!!
  </pre>


<!-- Date: Sat Jan 10 10:35:44 2004 -->
<pre> According to the daily autoSVTMon, we have same error level as  
it was. (1.7%)  And it is due to the W10B1. 
We should totally doubt the possibility of upstream thing from HF. 
But, as Marco / Unki pointed out, junk data from SVX does not  
affect the svtsim as far as junk data is coming with correct  
timing and svtsim do not assume the data type. 
 In that sense, splitter ot G-link reciver is more suspicious? 
 
 </pre>
<!-- Author: Taka -->
<!-- Comment: Mon Jan 12 06;16;14 comment by...stefano -->
try swapping optical fibers in the back, to rule out
possible problems with g-link receiver.

<!-- Comment: Mon Jan 12 13;47;14 comment by...Taka -->
<pre> OK, I'll try the swapping with new hwset during next 
beam dumping.</pre>


<!-- Date: Mon Jan 12 13:50:35 2004 -->
New beam position after the orbit smooth 
<a href= 
'/cgi/elog/elog.pl?nb=2004&action=view&page=32&frame=2&anchor=12:28:25.918'> 
main e-log. </a> 
It is slightly worse than before (as of 1_jan-2004, e.g.). 
(x went to -300um: far from center.)
<!-- Author: Taka -->


<!-- Date: Mon Jan 12 14:04:00 2004 -->
 We had new COT track PT cut in L3 (Pt>1.0GeV/c), so that 
L3 is not a bottle neck of the deadtime. It may allow 380Hz 
 L2 rate from our yesterday's experience. 
(See main e-log, which Masa entried 
<a href= 
'/cgi/elog/elog.pl?nb=2004&action=view&page=32&frame=2&anchor=12:24:36.906'> 
here. </a> ) <br>   
 It is interesting for us to look the deadtime of next high luminosity run. (still not 100% sure what will be going on) <br> 
 
 
 Next target is event builder. But, growth term of SVT is still 
problem in higher luminosity for a while (than processing time, 
maybe). As Marco pointed out, tighter Chisquare cut is effective. 
We also need to tackle the other possibility?? 
<!-- Author: Taka Maruyama -->


<!-- Date: Tue Jan 13 17:44:52 2004 -->
<pre> 
 
 To estimate the source of the mismatches between SVT emulator  
and data, we swapped the optical fiber coming from the SVX at  
G-link reciever level (backward of VME crate).   
The optical fibers corresponding W10B0B1 was swapped to W10B2B3.   
Also we have W5B0B1 &lt;--&gt; W5B2B3 swap.   
If SVX readout itself is the source of  
this problem, wedge of mismatched data will not move, but G-link  
reciever is wrong, we have problem in swapped wedge.  
 
 To test this, following lines of hwset were changed. 
 
hf_w05_b0b1_evenBarrel                  0   --&gt;  2 
hf_w05_b0b1_oddBarrel                   1   --&gt;  3 
 
hf_w05_b2b3_evenBarrel                  2   --&gt;  0 
hf_w05_b2b3_oddBarrel                   3   --&gt;  1 
 
 Wedge#10 was changed as well. Threshold of these wedges were 
also changed.  
If you have troubles, please page SVT. 
 </pre>
<!-- Author: Taka Maruyama -->
<!-- Comment: Tue Jan 13 19;59;14 comment by...Taka -->
<pre>Run#177793 is the run for the swapping SVX fiber test.</pre>


<!-- Comment: Wed Jan 14 19;15;36 comment by...Taka Maruyama -->
<b> Actually, we have swapped condition in 
 run#177793 to run#177800. </b>
<!-- Date: Wed Jan 14 05:49:43 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-181&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-181  width='300' align='top'></a></td><td>We have correct data with swapped configuration as shown in 
this figure, but svtsim does not corresponds to this changing. 
Data itself is fine, but we need to have improved svtsim.</td></tr></table>
<!-- Author: Taka -->


<!-- Date: Wed Jan 14 06:13:00 2004 -->
<pre> We switch back the configuration of SVT. (optical fiber   
swapped to recover the configuration before run#177793)  
The data looks OK during this configuration changing period.  
 
 Only problem for these data is that svtsim does not corresponds 
to hwset. (this configuration). After improvement of the svtsim, 
we will report the results. </pre>
<!-- Author: Taka -->



<!-- Date: Thu Jan 15 18:38:45 2004 -->
<pre> SVT data quality is quickly checked with run#177926. 
Optical fiber was already swapped back and have normal condition. 
 
 mismatch rate between svtsim / SVTD is 0.65%. 
 (42 / 6474 events), 22 Out of 42 is from W5B1, but  
 only 1 event from W10B1.  
 
 We didn't do any special actions, but mismatch 
at W10B1 was gone. Therefore, now we are wondering  
W10B1 was due to the fiber connection at g-link reciever 
unless Silicon guys did something special. 
(according to their e-log, they didn't, though) 
 
 W5B1 is still slightly wired. May need more investigation.    
 
</pre>
<!-- Author: Taka  -->

<!-- Date: Fri Jan 16 07:50:13 2004 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Fri Jan 16 07:50:13 2004 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->


<!-- Date: Fri Jan 16 08:21:43 2004 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->



<!-- Date: Fri Jan 16 08:55:39 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre> We set b0svt06 to be syncronized to the other crate using  
b0svt06&gt; svtGfr 1 
 
 And investigated L2DTO problem. 
We HALTED run and ran the "whodunnit". There is no harmful  
crates as we already knows. So, only possibility is GB (SVT 
last board) has problem.  
 
I also see the b0svt06_20040116081325.dat, made around 8:13am. 
(after svtGfr = 1). I found All End of Events are same (7e1150) 
in all SVT crates (including last board, GB).  
This means that we don't have any data 
stopping place inside SVT. (final possibility is terminated since 
GB does not stopped the data). 
 
We can say only SVT has no problem it seems that. 
To solve the problem, we need to have another way.  
</pre></td></tr></td></table>
<!-- Author: Taka -->

<!-- Date: Sat Jan 17 09:02:17 2004 -->
<pre>
 
Merger b0svt07/10: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=1110, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=0001, FIFOMT=1110, InpEna=1110, Ena&!MT=0000
 
Ena&!MT summary: 000000000000000000
 
</pre>
<!-- Author: svt whodunnit script -->