<!-- Title: 18:37:48  Fri Jun 29 2007 -->
<!-- Crewchief: L2 trigger -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Start a new page right before Lucas leaves (going back to Pisa this Sunday, but he will be back in Oct.!).  Vadim, Laura, Gene and I, as well as everyone else, will really miss him (so will all the pulsar boards, mezzaine cards, AUX cards,  every single cable, and all the nicely labeled spare component boxes, and the fantastic <a href= 
'http://www-cdf.fnal.gov/internal/upgrades/daq_trig/l2cal/l2cal_home.htm 
'> L2CAL web page </a>  he designed...). 
 
<p>  
Lucas, you have done a wonderful job here for our L2 trigger upgrade. It seems to me that everything here is much nicer and elegant, soon after your touch. Just look at the clean teststand room and the L2CAL web site. It is so nice to see that you have already done amazing things at this young age. 
<p> 
 
We will all miss Lucas. To make it easier for everyone, I will post a few photos of him.  
 
<p> 
Lucas, Please come back! 
 
<p> 
 
Ted for everyone


<!-- Date: Fri Jun 29 18:39:15 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-438&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-438' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-439&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-440' ></a><a href='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-441&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2upgrade&action=view&page=-442' ></a></center>
<!-- Author: Ted -->


<!-- Date: Fri Jun 29 19:09:32 2007 -->
<pre>===== A brief summary of what Lucas and I have done ==== 
 
In the past two weeks or so, I had the opportunity to work with Lucas closely on the Pulsar spare issue. Here is a short summary of what we have done (most of the work was done by Lucas, I was just there to keep him entertained).  
 
(1) Eight Pulsars (4 with P3, 4 without) were sent the PREP for testing. All four with P3 came back to B0. The ones without P3 will stay there to have P3 installed later (so that we can prepare spares for other pathes), 
 
(2) Prepared one pair of Pulsar Muon/L1/XTRP Tx and Rx and fully cabled up, with the goal to recover the Pulsar Muon path teststand capability later. The spare Muon Rx was later actually swapped into the system recently. 
 
(3) Prepared one pair of RECES Pulsar Tx and Rx, with the goal to recover testing capability of Taxi mezzanine cards if needed in the future. 
 
(4) Prepared one spare Pulsar SVT Rx; 
 
(5) Prepared one SLINK Tx and use this setup for debugging a few Pulsars with known problem recently (Lucas's SLINK teststand set up has been proven to be crucial for debugging the pulsars with known problem below). 
 
We have successfully debugged three problem Pulsar boards, located the exact problem on each board (each has one single problem, such as trace being cut by a scratch. two of them should be easy to fix). We couldn't have done this at all without Lucas SLINK teststand setup. by the way, this is the first time we find real problem on a few pulsar boards, out of ~ 100 pulars running in the system. Lucas is one of a few who actually learned how to debug Pulsar board... 
 
  
</pre>
<!-- Author: Ted for Lucas -->


<!-- Date: Mon Jul 2 11:32:45 2007 -->
<pre>Conclusions from L2_Torture test (more details with the exact description of the tests with sizes of all events, exact failure modes etc is posted on the Davis e-log but thought people don't want pages in this e-log.). 
I've separated the cases in terms of # of large inputs on each PCI bus. 
The assumptions are that it does not matter which FILAR the inputs are on if they are both on the same PCI bus (i.e inputs in FILAR 1 and 2 have the same effect). This has been observed numerous times before. 
 
Details of the test: 
* Using 6 XFTs on 2 FILAR cards (0 and 1 for these tests) 
* Using the merged old inputs to get reference for bunch counter etc (location of merged input does not change outcome of tests, size ~70 words) 
* L1 accept rate: starts at ~1Hz and reaches 1.7kHz by about 600 events. Ran all tests for 1000 events. 
 
4 Large inputs on 1 FILAR (1 PCI bus): 
 
1) 4x(140-193 words)= total 560 -  773 
- OK for ~1000 events 
 
2) 3x(140-193) + 1x(280-386) = total 700 - 955 
- 2 HRR in 1000 events: largest packet is corrupt 
 
3) 4x(221-287) = total 884 - 1148 
- Ran for only 50 events (&lt;10Hz) then after each HRR only ~10 events 
- Data corrupt on random packet 
 
 
3 Large inputs on 1 FILAR (1 PCI bus): 
 
1)3x(140-193) = total 420 - 579 
- OK for ~1000 events 
 
2) 2x(140-193) + 1x(280-386) = total 560 - 772 
- OK for ~1000 events 
 
3) 1x(140-193) + 2x(280-386) = total 700- 965 
- OK for ~1000 events 
 
4) 3x(280-386) = total 840 - 1158 
- HRR after ~800 events (rate ~17.kHz) 
- Data corrupt in last large packet to arrive to PC 
- No more failured for ~800 events 
 
5) 3x(221-286)  = total 663 - 858 
- OK for ~1000 events 
 
6) 2x(221-286) + 1x(423-639) = total 865 - 1211 
- HRR after ~800 events 
- Data corruption on largest event + bunch counter mismatch 
- Previous event for largest packet is where the problem lies: Shuld have been ~530 words but was 837!!! 
-&gt; Looks like 2 events where merged together for previous event but did not get corruption as found trailer and header OK.  
- Ran fine for next ~200 events 
 
7) 1x(221-286)+2x(423-639) = total 1067-1564 
- No HRR for ~1000 events  
- Quite a few single events that were bad but never 3 in a row 
 
8) 3x(423-639) = total 1269-1917 words 
- Ran for ~300 events (rate &lt;10Hz)  
- then many HRR (approx every 50 events) 
- Data corruption on large data size, bunch counter mismatch 
- No problems seen in sizes of previous event 
- Completely stopped running when rate went to ~1.7kHz (after ~630 events) 
 
 
2 Large inputs on 1 FILAR: 
1) 2x(560-760) = total 1120-1520 
- No problems for ~1000 events (rate ~1.7kHz) 
 
2) Did not try any higher.... 
 
 
 
Conclusions: 
4 Large packets:  
* Runs fine when max size on FILAR &lt;770 
* Few corrupted events when size ~950 
* Breaks when max size ~1150 
 
3 Large packets: 
* Runs fine up to max size on FILAR &lt; 960 
* Only few HRR up to size ~1500 
* Few HRR when rate ~10Hz-1.5kHz, dies for  rate ~1.7kHz for max sizes ~1900 
 
2 Large packets: 
* No problems with total max size ~1500 
</pre>
<!-- Author: Alison -->


<!-- Date: Mon Jul 2 22:40:45 2007 -->
<pre>Errors on PC 0.10: 
Below is a summary of the problem we have been having over the past few days on the 0.10 (parasitic) PC. 
 
* Problem with the communication with TED: 
1) Friday evening before I could start the tests and then again in the middle of the tests the PC refused to talk to TED. TED was waiting for a response and the PC was waiting for Algo Unlock (ACK). 
I really don't know what fixed the problem in the end. Lots of fiddling around with the system. 
Software reboot did not solve the problem. 
2) Saturday evening same thing happened again to Anadi and I. This time a hardware reboot solved the problem (shutdown then powering off from the front of the PC and back on again). 
 
* Problem with the FILAR 2 channel 3 (currently CLUSTER) 
1) Friday I had the hardest time getting this channel to talk to the PC. Sometime it would work then the next test it would not. 
Wiggling the fibers usually solved the problem for a few more tests. Sometimes the cause was not obviously that channel but it just was not getting data and when the executable died it complained about that channel. 
2) Saturday we didn't have problem with that channel 
3) Sunday Anadi has many problems with that same input 
4) Today I again had problems with that input. Wiggling it once solved the problem. 
</pre>
<!-- Author: Alison + Anadi -->
<!-- Comment: Mon Jul  2 23;23;49 comment by...Alison -->
<pre>Addendum:
More problems with that input on the FILAR.
No wiggling has solved the problem.
As the problem appears on activate only I could still run the tests to see if the code picks up from RC the ignoreL2Stereo and ignoreL2Cal (see next entry).
Do we not have a working spare FILAR?</pre>


<!-- Comment: Tue Jul  3 18;40;29 comment by...Ted -->
<pre>this fiber wiggling thing is so weird... we never had to do this to a FILAR before (and we only had 1-2 people touch the filars a few times over a few years, mostly during the inital commissioning setup. but it was just a few times). 

please check the LED lights before wiggling anything... the LEDs have useful information about the status of the link. for example, if the link is really down when it happens, and by wiggling the fiber the link comes back up, then you learn something.... otherwise, it is just the usual TWA.</pre>
<!-- Comment: Tue Jul  3 19;15;27 comment by...Ted -->
<pre>I vaguely remember hearing a story about long ago (few months back), there was an accident with one SLINK fiber being pulled suddenly, and the force was so strong that the optical receiver actually came out of a FILAR. There is still a piece of it lying around somewhere in the trigger room (that's how I knew, kuz I saw the piece and then asked around). But I have no clue with the details and who saw this. is this channel/filar the same channel/filar with that accident? if so, then it may explain the problem. and i can take a close look at it.

anyway, just trying to help.</pre>
<!-- Date: Mon Jul 2 23:35:03 2007 -->
<pre>Testing of ignoreL2Cal and ignoreL2Stereo: 
I modified NodeAlgo to read the parameters from RC. 
Checked out from CVS latest version of l2_common to pick up Anadi's code changes. 
Did not work. 
By default these must be set to be ignored as I only get "waiting for RECES MUON CLUSTER". 
Unchecking the box in RC (expert options) did not cause any more channels to be "waiting for" during the config stage. 
 
This could be also a problem of testing it on the parasitic PC. 
Next between store time someone should try this from the decision PC. 
 
</pre>
<!-- Author: Alison -->




<!-- Date: Wed Jul 4 10:53:29 2007 -->
<pre>The old decision PC (0.3) is now definitely retired! 
I removed the FILAR card from it (SN 103) to replace the one we believe has the faulty channel 2 (SN108). 
I put a "backbone" onto the card in 0.10. 
</pre>
<!-- Author: Alison -->


<!-- Date: Wed Jul 4 11:43:12 2007 -->
<pre>Diagnostic of FILAR problem: 
 
1) Swapped to new FILAR board 
* Problem still there: channel 2 does not come up (and green light not on on FILAR card) 
-&gt; Not the board itself! 
 
2) Swapped inputs between XFT2 and CLUSTER 
* FILAR does not come up at all... 
* Light still off on channel 2 
 
3) Wiggled them again + restarted NodeAlgo 
* FILAR does not come up 
* Light now off on channel 3 
 
4) Next wiggling attempt 
* FILAR does come up 
* Light all everywhere 
* Configs but takes forever to start up channel 3 
-&gt; Same problem as before but on a different channel 
-&gt; Stays with CLUSTER (eventually) 
 
5) Swapped all inputs between FILAR 1 and FILAR 2 
* After a few iterations all channels came up with no problem 
-&gt; Leave this configuration and request and EOS test 
 
EOS test goals: 
- If problem does not come back: keep it this way (as FILAR 1 and 2 are on same PCI bus so does not matter if the inputs are switched) 
- If problem comes back in CLUSTER path (and decision PC is not complaining about CLUSTER): switch CLUSTER fiber to one of the spares</pre>
<!-- Author: Alison -->
<!-- Comment: Wed Jul  4 12;05;39 comment by...Alison -->
<pre>More information:
It seems that over the past 24h there have been many errors on the CLUSTER path also in the decision PC.
"Waiting for CLUSTER  packet(s)...."

What I don't understand is the following:
* If it's a problem with CLUSTER (and not the known stuck bit problem, the rate seems to high for it to be this problem) why does it not appear in the decision PC when we are not running parasitically?
* If it's a problem with the fiber or the 0.10 PC why does it complain in the main PC (istead of waiting for all packets as I would expect if there were no problems)?

Another few questions to everyone:
* Are the fibers somehow connected as master/slave in the AUX cards or do both inputs have the same priority?
* If it is a problem with the fiber, why does the decison PC also complain? maybe this is "normal"?


</pre>


<!-- Date: Mon Jul 9 19:08:37 2007 -->
<pre>just started run 244752. This is running 905 in the main pc (table built from the head of CVS) and 909 (same PHYSICS table, built from the branch). There are no test XFT triggers yet. If this will show no decision mismatches then we will move to build a new table from the branch with XFT test triggers. </pre>
<!-- Author: Anadi, Gene, Vadim -->


<!-- Date: Mon Jul 9 19:13:30 2007 -->
<pre>Test during the week-end: 
1) Friday - owl shift 
Test: L2 tagset 905 (built from the head) on the parasitic against L2 tagset 894 (default on the main PC) 
-L3 tagset for main PC 691 (filter enabled) 
Result: decisions agree before prescale expect for one event with COTSPIKE and the L2 cal triggers (111 and 112 - known to be different). Observe differences after prescale. Problem is resolved on Monday. 
Run: 244649 
Comments: observe high dead time 
2) Friday - evening shift 
Test: L2 tagset 907 (built from the branch with XFT triggers in) on the parasitic against L2 tagset 894 (default on the main PC) 
-L3 tagset for main PC 690 (filter disabled) 
Result: cumulating data for the XFT team 
Run: 244651  
Comments: observe high dead time 
------------------------------------ 
Test: L2 tagset 905 (built from the head) on the parasitic against L2 tagset 894 (default on the main PC) 
-L3 tagset for main PC 691 (filter enabled) 
Result: decision agree before prescale expect for one event with COTSPIKE and the L2 cal triggers (111 and 112 - known to be different) 
Run: 244655 
Comments: observe high dead time 
----------------------------------- 
Test: L2 tagset 907 (built from the branch with XFT triggers in) on the parasitic against L2 tagset 894 (default on the main PC) 
-L3 tagset for main PC 690 (filter disabled) 
Result: cumulating data for the XFT team 
Run: from 244674  
 
The result of this set of tests, along with understanding and solving the different decision after prescale, lead to the validation of L2 tagset 905 (built from the head of the repository).</pre>
<!-- Author: Anadi  -->


<!-- Date: Mon Jul 9 22:28:17 2007 -->
<pre>Testing new L2 tagset: 
1) 
-Run 244720 
-L2 tagset 894 on main PC 
-L2 tagset 907 on parasitic 
-L3 filter disable 
-goal is to collect data for the XFT 
2)  
-Run 244742 to 51  
-L2 tagset 894 on main PC 
-L2 tagset 905 on parasitic 
-L3 filter enable 
-goal is to verify that decisions do agree after prescale (prescales propagate correctly to either main and parasitic PC). They do. 
-L2 tagset 905 is promoted to current L2 tagset and can be run on the main PC (905 is built from the head). 
3) 
-Run 244752 to 54 
-L2 tagset 905 on main PC 
-L2 tagset 909 on parasitic (L2 tagset 909 is built from the xft branch, but does NOT have xft triggers in) 
-goal is to validate the new table. Decision do agree. 
4)  
-Run 244755 to 58 
-Tried to run L2 tagset 910 matched to L3 tagset 692 on **both** the main PC and the parasitic PC. The L2 tagset is built from the xft branch and does have the xft triggers in. We started with no silicon test. However we stopped the run because of L3 problems (L3 expert investigating). The goal was to take a short run with the same trigger table and check if we can ignore the XFT triggers in the main PC even if present in the table.  
5)  
-Run 44759 
Back to run 905 (new current table) from the main PC against 909 (buitl from the branch with xft triggers in) in the parasitic. We use L3 tagset 691 to check the decision. 
-L3 filter enable 
 
</pre>
<!-- Author: Anadi Vadim and Gene -->


<!-- Date: Tue Jul 10 01:09:08 2007 -->
Earlier today, Vadim and Anadi fixed the the large deadtime that we have been seeing for the past few days. 
<p> 
The cause was that the "parasitic" L2 program running on the spare PC mis-interpreted its config message. That caused it to have the wrong prescales associated with trigger decisions. So while the decisions before prescale were right, they were wrong after the prescale. Since the L2_INCLUSIVE triggers satisfy every event before PS (by construction) and were incorrectly assigned PS=1, the spare PC was treating every event as a Level 2 accept and sending TL2D to the L2TS pulsar for every L1A rather than to the short L2 reject packet. That led to the large L2 latency. 
<p> 
The reason the readout time was long for the b0l2pu02 crate was that it was not only TL2D but the extra-long readout list 7 version, so it took longer to read than the normal TL2D readout from the actual decision PC in b0l2pu01 giving us extra readout deadtime as well. 
<p> 
The reason this bug was missed by the TL2D comparisons in DAQErrorFilter running in Level 3 is that we expect differences in rate-limited triggers after prescaling. Therefore we don't check them.  
<p> 
The outstanding question in Level 2 front-end code is why the Pulsar 05 crate takes longer to set Tracer-Done than the 00 and 03 crates that are believed to have the same configuration as 05.  This appears to be the largest non-COT crate, so it does affect the minimum Done time and therefore contributes to deadtime.
<!-- Author: jdl -->
<!-- Comment: Tue Jul 10 08;53;14 comment by...Ted -->
<pre>I took a quick look, the only differences between Pulsar_05 and 00/03 are:

(1) RESETOK = 0 for Pulsar_05 crate, while it is 1 for all others;
(2) POWERSUPPLYTYPE shows up as "null", while it is "Alacrity Model # 1.3" on all others.

(2) shouldn't have anything to do with readout. how about (1) ...</pre>

<!-- Comment: Tue Jul 10 13;51;03 comment by...Ted -->
Bill confirmed that (1) shouldn't have anything to do with readout either.


<!-- Comment: Mon Jul 16 16;31;57 comment by...Ted -->
<pre>
==== email from Bill today ====

I have marked "RESETOK=1" in the hdwdb for b0l2pu05 

Probably the reset line was repaired in the past, but we forgot 
to mark "resetok=1" afterwards...

</pre>
<!-- Date: Wed Jul 11 08:44:03 2007 -->
<pre>Attempt at reducing number of HRR due to XFT. 
Upon closer investigation it seems that sometimes HRR are issued when there is only a single event with a problem. 
e.g the XFT data is corrupt (error 1), the XFT bunch counters don't match (of course becausee the data is bad: error 2), the bunch counters don't agree (of course because XFT is bad: error 3) -&gt; HRR. 
I modified NodeAlgo to be a little more clever about such cases. 
Tested between stores today and it seems to be doing it's job. By chance the XTCs were sending all bits on which caused many data corruption problems which enabled me to validate the code. 
 
I also cleaned up NodeAlgo.cc and .icc. 
Added a flag to have the option of listening to RC for the ingores (of L2Cal or L2Stereo) or taking them from the code (as it done currently: decision PC is ignoring XFT but parasitic PC is reading out XFT). 
 
</pre>
<!-- Author: Alison -->


<!-- Date: Wed Jul 11 08:47:22 2007 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>New labels have been put on all fibers going into the parasitic PC. 
These labels have GREEN edges and all contain the word "parasitic" (with the exception of Tracklist as there is still only 1 tracklist fiber) and are descriptive of the input.  
</pre></td></tr></td></table>
<!-- Author: Alison -->


<!-- Date: Wed Jul 11 09:58:18 2007 -->
<pre>We tested the table with L2 tagset 910 built from the branch running on the main PC against table with L2 tagset 911 built from the head after we merged head and branch, running in parasitic PC. We run ignoring XFT. We saw no difference in decision for all triggers but bit 144: L2_Z_ZZZ_TEST_XFT_STEREO_5TRK4_RL10HZ [1]. We are investigating </pre>
<!-- Author: Anadi Gene Vadim -->


<!-- Date: Thu Jul 12 21:56:06 2007 -->
<pre>Run 244961  
After a minor problem during the first test (size of an array was not changed properly causing a seg. fault during config.), we could run L2 tagset 913 (built from the head, with new xft and L2cal test triggers in) from the main PC. No process was running on the parasitic PC. XFT was ignored. The test was successful.</pre>
<!-- Author: Anadi Gene Giorgio Vadim -->


<!-- Date: Sat Jul 14 12:31:38 2007 -->
<pre>Uploaded new firmware to tracklist A control FPGA (Version vB5707120). The goal was to fix the L1 trigger bits problem.  Ran a special L2 torture test (L2 auto accept, no L3 processing).  Results look good.</pre>
<!-- Author: Heather -->
<!-- Comment: Mon Jul 16 10;50;48 comment by...Heather -->
<pre>But I was wrong... need more debugging.  The L2 torture tests must be run with XFT in diagnostic mode.  If we get don't get tracks, we don't see errors (which was the case for the L2 torture test I ran saturday).  If we get tracks (tests I did today) then we see trigger bit errors and it looks like we are off by 1 event. In other words:  still debugging trigger bit firmware.</pre>


<!-- Date: Mon Jul 16 14:56:00 2007 -->
<pre>Today between stores we split the XFT Pulsar outputs: 
We added an SLINK card to the transmission boards of the XFT Pulsars. We now have 2 masters for each XFT (one for decision PC, 1 for parasitic PC). The fibers are labelled accordingly. 
 
We also added a new merger board in order to get the timing information for each XFT input (read out from the slave of the first SLINK card). 
 
Ran for a while in AAA_SHOTSETUP_L2UP and after solving a few configuration bugs we ran smoothly. 
 
We were not able to re-produce the data corruption on XFT 2 that was observed at the weekend. 
</pre>
<!-- Author: Laura + Alison -->



<!-- Date: Mon Jul 16 18:41:59 2007 -->
<pre>We tested TEST table PHYSICS_TEST_4_02 [57,920,696]  running on both the main and the parasitic PC. Pass1 and taus (3x3 matrix and number of towers with Et&gt;30x0.125&lt;5) were added to the L2tagset (however no change to the table was made, so the tau test triggers are still prescaled to 0). This table will be tested during the store tomorrow morning to be promoted to deafult physics table</pre>
<!-- Author: Anadi Vadim -->


<!-- Date: Tue Jul 17 16:40:25 2007 -->
<pre>Today we tested L2 tagset 920 in PHYSICS_TEST_4_02 [57] run on the main PC against the current table (L2 tagset 918 in PHYSICS_4_02 [9]) run on the parasitic PC. We compared the decision taken by the two PC in different runs, looking at the results of *non* test triggers. The decision is the same except for events fired only by L2 bit 142 (since it was changed). The table can be promoted to PHYSICS based on these results. However we should use a new L2 tagset for l2pulsar_algo because of minor changes to the code (taus are included into the new L2 tagset; they use 3x3 matrci for clustering and a cut on the number of towers above a threshold).  
We took several test runs to cumulate statistics and to test algorithms on the parasitic PC, once done with the decision checking.  
Runs 
-245213 NO SI 
-245214 Silicon 
-245220 Silicon 
-245221 Silicon 
-245223 Silicon 
-245228 Silicon 
In all runs the Online Error Filter was ON. 
Data are good from the trigger point of view even if data are taken with TEST tables.</pre>
<!-- Author: Anadi Gene Vadim -->
<!-- Comment: Tue Jul 17 20;06;13 comment by...Anadi  -->
<pre>Additional tests:
L2 BEAM tests: 
tested L2 tagset 920 in PHYSICS_TEST_4_02 [57,920,696] - decision agrees with the one of the current
table (bit 142 is expected to be different). Several iterations were needed to debug algorithms
running on the parasitic PC 

Runs: 245228; 33; 34; 36; 58 

L2 NON BEAM test: 
tested L2 tagset 921 in PHYSICS_TEST_4_02 [58,921,697]. The test was succesfull.  
Run: 245263  

</pre>


<!-- Date: Fri Jul 20 14:59:16 2007 -->
<pre>Uploaded new firmware to the tracklist control A (version b5707190).  This firmware has the L1 trigger bits after the track-list (right before the SLINK trailer word).  This firmware also has the XFT abort bit set as bit 0 of the SLINK trailer word.  Bits 15:1 are hardcoded to 0 in the SLINK trailer word.  In other words, the SLINK trailer word bits 15:0 will be 0x1 or 0x0.   
 
I tested this firmware with several L2 torture tests with varying XFT bit masks and it is giving us what we expect for the L1 trigger bits and the XFT abort bit.</pre>
<!-- Author: Heather -->
<!-- Comment: Mon Jul 23 18;05;49 comment by...Heather -->
<pre>Correction: the slink trailer word bits 15:0 will be 0x0000, 0x0001, 0x0002, or 0x0003.</pre>
<!-- Date: Mon Jul 23 16:20:00 2007 -->
<pre>I moved the XFT fibers into the decision PC. 
Ordering of the inputs is now identical to the parastic PC. 
NodeAlgo.icc and .cc were merged and Anadi uploaded them to CVS  (tag vup07_4). 
Changed in the RC setting that: AAA_CURRENT, AAA_CURRENT_L2UP, AAA_SHOTSETUP, AAA_SHOTSETUP_L2UP now all consider the XFT inputs (i.e. ignoreL2Stereo is no longer enabled). 
The caveat is that if the initial lumi is about say 200e30 we expect L2 TO because of these inputs.</pre>
<!-- Author: Alison -->



<!-- Date: Wed Aug 1 18:12:42 2007 -->
<pre>Summary of test trying to mimick the SL3 mask section only scenario: 
 
This scenario would have:  
1 XFT pulsar reading only SL3 where we only look at the mask section (would be fixed 84 words per event).  
The other 2 XFT pulsars would share the SL5 and SL7 inputs. 
 
 
The test I performed was the following: 
XFT1: disable all but the 4 SL7 inputs (data size expected 60-90 words at high lumi) 
XFT2+3: leave as it (more stingent tests than having only SL5 and SL7). 
 
We were concerned only about the Filar/PCI/PC transfers and possible data corruption so removed all XFT algorithm + triggering. 
 
Running in the parasitic PC. 
 
 
Base-line: Sunday's test with XFT in the default configuration running in the decision PC: 
Lumi 240-200 (~1h of data taking). 
Observed a total of 21 errors split into the following: 
 	XFT bunch counter mismatches: 	6 
	XFT 1 data is corrupt: 			5 
	XFT 2 data is corrupt: 			5 
	XFT 3 data is corrupt:			5 
 
 
Current test with "SL3 mask only" imitation: 
Lumi 260-216 (~50min of data taking). 
Observed a total of 0 errors (except for those immediately following problems with b0l2pu01 and 02 that amounted to 5 errors) 
 
 
-&gt; This is a strong indication that having the mask section only for SL3 should push the boundry at which we might see data corruption. 
How far this boundry will be pushed might be able to be determined from L2 torture tests during the shut-down by varying the sizes of the inputs. 
 
</pre>
<!-- Author: Alison -->


<!-- Date: Thu Aug 2 11:38:55 2007 -->
<pre>00055001 00010000 0094f33f 00000100 9f040000 00000002 00963400 18140100 
 01000096 95153f00 00010000 04000000 000002a6 94500000 14010000 00009618 
 00331501 3f000000 00009532 00000001 02ab0400 00000000 00009634 96181401 
 00010000 0095543f 00000100 b2040000 00000002 00945000 18140100 01000096 
 00003315 763f0000 01000095 00000000 0002b704 3c000000 0100008d 00962914 
 4b150100 00000045 0095983f 00000100 bb040000 00000002 00963400 18140100 
 01000096 00454b15 ba3f0000 01000095 00000000 0002bf04 50000000 01000094 
 00962914 4b150100 00000045 0095dc3f 00000100 c3040000 00000002 00963400 
 18140100 01000096 00454b15 fe3f0000 01000095 00000000 0002c704 50000000 
 01000094 00962914 4b150100 00000045 e0f00000 
</pre>
<!-- Author: vr -->