<!-- Title: 13:30:55  Sat Apr  2 2005 -->
<!-- Crewchief: SVT people -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>New page</pre>


<!-- Date: Tue Apr 12 18:51:59 2005 -->
<pre>We put the HW set we the LC cut active. SVT plots look good. Tests of the trigger table are going on.</pre>
<!-- Author: Stefano & Jahred -->
<!-- Comment: Tue Apr 12 23;14;16 comment by...Ted -->
<pre>the new trigger table tests were sucessful. we declared them the default tables. From now, SVT LC cut is enabled (for good).
besides the SVT LC cut enable, the other new thing added to the new trigger tables is the DCAS threshold setting to kill the ring of fire at L2. for details, see main shift e-log. </pre>


<!-- Date: Wed Apr 13 00:00:50 2005 -->
<pre>We uploaded the patterns from Jan. 06 that were generated with a beam position at y=1692 um (x=-570), much closer to the new beam position than the previous patterns. The new ("old") patterns were successfully tested with fakehits.</pre>
<!-- Author: Jahred & Stefano -->


<!-- Date: Wed Apr 13 09:42:53 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-334&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-334' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-335&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-335' width='300'></a></center>
<!-- Author: Stefano -->
<!-- Comment: Wed Apr 13 09;47;26 comment by...Stefano -->
<pre>These two plots show the timing distribution for the two run 196366 and 196440. Both runs have instantaneous luminosity ~80E30. Run 196366  is w/out LC cut, run 196440 is with LC cut. </pre>

<!-- Comment: Wed Apr 13 10;30;37 comment by...Jahred -->
<pre>Three comments:

1) If you're viewing these, the order is reversed - the new run with LC cut on (196440) is on the left, and the old run is on the right (so they're switched in order).

2) You can't read the mean off these plots, but I took a look at the histograms: mean with LC cut on: 24.72 us, mean with LC cut off: 26.03 us.

3) I think it's probably hard to say for certain how much if this effect (if any of it at all) is due to the LC cut, though it certaintly can't hurt to look at the distrbutions.</pre>

<!-- Comment: Wed Apr 13 16;50;00 comment by...Ted -->
<pre>I have also looked for any possible  SVT LC cutting effects.  here is what I found so far:

Run number:              B_charm_highPt (nb) at luminosity of 70.

196440 (LC cut on)            250 nb

196275                        230 nb

192348                        265 nb

195740                        260 nb

not clear if there is any noticeable change. overall L2 latency is all at around 35 us. I have shown this to Roberto (who just came back from airport!). maybe we need high luminosity to see the effects more clearly.

there are other studies on this new trigger table on killing of "ring of fire" at L2 for clustering, details see trigger table e-log.
</pre>

<!-- Comment: Wed Apr 13 17;27;57 comment by...Jahred -->
I also took a look at the L2_BJET15_D120 trigger (exotics people saw a large reduction in rate - see <a href = http://fcdfwww.fnal.gov/internal/WebTalks/Archive/0412/041213_ExoticTrigger/02_041213_ExoticTrigger___other_1_0_longCluster_et.pdf> webtalks </a>)<p>

Run (L2_BJET15_D120 (nb))<p>
196440: 118<p>
196275: 117<p>
192348: 126<p>
195740: 125<p>

So I see a similar effect - smaller rates in the recent two runs, but the LCC run doesn't have the lowest rate. It's hard to say anything for sure right now, I think. A higher lum store would help.

<!-- Comment: Wed Apr 13 18;15;17 comment by...Jahred -->
<pre>I may be getting in over my head here, but in any case:

For LCC run, Rate(L2_BJET15_D120)/Rate(L1_TWO_TRK2__TWO_CJET5) = 0.847%

For the strange recent run of 196275, it's 0.858%. Not a huge change, but a rate decrease of 1.3% is better than a rate increase.</pre>


<!-- Date: Thu Apr 14 19:55:44 2005 -->
<pre>====== email I sent to the svt mailing list ==== 
 
 
I had a long discussion with Roberto this afternoon, and later Vadim joined us. Here is our current understanding about SVT fast abort effect on overall L2 latency.  The conclusion is: fast abort still helps to improve the overall L2 latency, esp. for Pulsar system. 
 
For the Pulsar system in its current configuration, the Puslar decision CPU receives non-SVT data package about 15 us after L1A at high luminosity (dominated by muon/xtrp package arrival time, as well as showermax). With fast abort enabled, the SVT data or EOE word (for events do not need SVT info) arrives to Pulsar decision CPU in about 6 us... so there is no waiting at all for SVT. 
 
Now with fast abort disabled, I was first under the wrong impression that the SVT data or EOE word (again for events do not need SVT info) will arrive in about 15 us sharp, therefore the effects will be small since the non-SVT data latency is already at 15 us.  Turns out recent timing measurements by Pulsar shows that SVT data/EOE word arrives at Pulsar decision CPU with a rather wide distribution mostly centered around 20+ some us (since it has to wait to collect all SVX data for the event). This means that Pulsar CPU will still wait for SVT data after it receives the non-SVT data and finish the non-SVT algorithm (in general, Pulsar CPU only takes ~ 1 us to finish the algorithm, while it takes Alpha ~10 us on average to finish algorithm)... So the overall L2 latency will be longer with fast abort disabled. 
 
 
For Alpha system, disabling fast abort has less effect at high luminosity. this is because the muon/xtrp data package formed by RunIIa Pulsar muon board has to send the data over an XTRP cable to XTRPList to transfer data over MagicBus... and the data transfer runs at 132 ns clock (very slow)... in addition, at higher luminosity, Alpha will take longer to run the non-SVT algorithm. This probably explains why there wasn't much difference with or without SVT fast abort enabled when Alpha was doing the driving at high luminosity (observed in one recent run). 
 
Anyway, based on what we learned from the recent Pulsar timing measurements, it is pretty clear that Pulsar system will benefit much more from SVT fast abort than Alpha.  In the future (~this summer), we will improve the non-SVT latency by a few us by using CERN FILAR PCI cards... in that case, fast abort will have even more effect on reducing the overall L2 latency. 
 
In principle, SVT "fast abort" could be done in the decision CPU software, but it would make things much more complicated from system point of view. 
 
Roberto, Vadim and I agree that we will do a simple test at high luminosity soon with SVT fast abort enabled again, since now Pulsar is doing the driving alone, we should be able to see the effects clearly. 
 
If confirmed, then we should be able to run at even higher luminosity with small deadtime (due to L2) with the current highlum table. 
 
 
In any case, looks like it is still important for SVT group to fix the fast abort features SOON, so that we can enable it again. We will know for sure how much it saves us soon.  
cheers, 
 
Ted 
 
ps. I will post this email into SVT e-log. 
</pre>
<!-- Author: Ted -->


<!-- Date: Thu Apr 14 20:03:47 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-336&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-336  width='300' align='top'></a></td><td>This is the Pulsar timing measurements for the high luminosity run this morning: 
 
the lower right one is the SVT package arrival time (in us) to the PCI card (end of the package). This is with fast abort disabled, and one can clearly see that the earliest arrival time starts around 18-20 us or so...not 15 us as I was told earlier. this plot was made by Vadim. 
</td></tr></table>
<!-- Author: Ted -->


<!-- Date: Fri Apr 15 13:02:24 2005 -->
<pre>I updated the startup table scripts for crates svt00 to svt08 to load the current version of SVTVME and SVTMON. 
The modified scripts are: 
/cdf/code-common/cdfonline/vxboot/ups/svtb.table 
/cdf/code-common/cdfonline/vxboot/ups/b0svt08.table 
</pre>
<!-- Author: Alberto -->


<!-- Date: Mon Apr 18 11:28:24 2005 -->
<pre>Since last Friday we are loading the "current" version of SVTVME on the crates  
instead of the "development" version. 
 
There are updated SVTVME instruction at the usual link: 
http://www-cdf.fnal.gov/upgrades/daq_trig/trigger/svt/svtvme/svtvme_maint.html 
 
The new procedure to be used in order to load a new version of the code is  
longer, but it allows to use the "development" version for development, and  
give us a fall back option when new code fails. 
</pre>
<!-- Author: Alberto -->


<!-- Date: Fri Apr 22 05:05:51 2005 -->
<pre>This is the summary of the fast abort/long cluster tests with 
the high lum trigger table: 
 
Run #    Fast abort enabled     LC cut    L1A rate    L2 latency 
 
196872        yes                yes        7.8 kHz     38 us 
 
196874        yes                no         7.2 kHz     38 us 
 
196875        no                 no         4.2 kHz     46 us 
 
196877        no                 no         3.8 kHz     45 us 
 
196878        yes                no         3.6 kHz     43 us 
 
Luminosity was 67e30 for the first run, 60e30 for the last run. 
High Lum trigger table was always used. We had a lot of fun.</pre>
<!-- Author: Roberto and Stefano -->


<!-- Date: Sat Apr 23 05:26:37 2005 -->
<pre>New test of the svtmon v2_0b, the result is not clear. 
After the last changes now the libraries is loaded on the crate b0svt6 with no error, but when i started the test run all the crates b0svt00-b0svt08 remain red, so i rebooted them one by one and they started. 
Now i leave them with the standard configuration and nothing changed. 
</pre>
<!-- Author: Benedetto -->


<!-- Date: Mon Apr 25 20:28:56 2005 -->
<pre>New test today with the same libraries of the previus entry, this time the run (n195957) started immediatly with no errors. The out level of the crate 06 was 3 an i stored the messages. 
Then the crate 06 was restarted , and another short run in the standard configuration (n196963). 
</pre>
<!-- Author: Benedetto -->


<!-- Date: Tue Apr 26 16:29:12 2005 -->
<pre>Yesterday I swaped svt09's CPU, which was a 2301, with a 2304 I got from Frank C.</pre>
<!-- Author: Alberto -->


<!-- Date: Wed Apr 27 13:35:03 2005 -->
<pre>The new "svt09" CPU has some problem. 
I swaped it with the one from the teststand.</pre>
<!-- Author: Alberto -->
<!-- Comment: Thu Apr 28 20;45;04 comment by...Alberto -->
<pre>Now I put in the teststand a 2301 vme CPU which works, but it is not the default "2304".</pre>


<!-- Date: Fri Apr 29 13:58:21 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-337&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-337' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-338&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-338' width='300'></a></center>
<!-- Author: Ted -->
<!-- Comment: Fri Apr 29 14;13;16 comment by...Ted -->
<pre>======= SVT average latency reduced =========

I looked at today's high luminosity run with high lumi table. and noticed that the online average L2 latency is about 41-42 us, instead of 46 us we saw in the past few weeks (note it was 39 us in March). Since this is with the same trigger table as we used in the past few weeks, I looked at the SVT latency timing and turns out that the average is now 37 us!(it was 41-42 us in the past few weeks and 36 us in March). See the plots above. On the left is an high lumi run a few days agao, and on the right is the run this morning. Since the Long Cluster cut is still enabled for both cases, this is a clear indication/evidence that LC has nothing to do with the change (this is what we expected of course), something else is causing it! and now we have to find out what it is. Maybe we should contact Silicon peple as well.

Anyway, for more details on this and related issues, see my talk
at Trigger Hardware meeting on April 22rd, it is also available
&lt;a href=
"http://hep.uchicago.edu/~thliu/projects/Pulsar/Pulsar_doc/Ted_L2Latency_fastabort.pdf"&gt;here&lt;/a&gt;.</pre>

<!-- Comment: Fri Apr 29 15;28;37 comment by...roberto -->
<pre>It looks like that during run 197186 (high lum) there were no prescale changes, in particular L1_TWO_TRK10, which should have been processed by svt. Check also the L2 accept rate vs lumi for the runs 197186 and 197071 (yesterday high lum record)</pre>

<!-- Comment: Fri Apr 29 16;44;40 comment by...Ted -->
<pre>Roberto and I looked into this in more details.  and Roberto is right that it is caused by the prescaled problem.  in particular, the L1_TWO_TRK10.   without prescale change, the trigger mix will have much less SVT triggers, therefore the SVT latency will be smaller on average.

we compared this run with a few other high lumi runs in the past. the difference can be all explained by the prescale changes (changed for all other runs except the run today).  the test run in March which showed 39 us L2 latency didn't have prescale change (becuase it was very short run, prescale didn't kick in yet). But the comparison with Alpha is still ok, becuase in the case of Alpha driving, there was no prescale change (also short run).

so the puzzle with L2/SVT latency is solved, the only thing left to check is how much is exactly due to fast abort at high luminosity with high lumi table.

so now the only puzzle left is why the prescale didn't change for today's high lumi run.

Ted and Roberto </pre>


<!-- Date: Sat Apr 30 18:14:03 2005 -->
<pre>Today I swapped the cables for the splitter MRG used to send data to the vertical slice. 
Now it is sending data from wedge 04 instead of wedge 00. 
 
I made the following tests: 
run 197241 fakehits with the default configuration (svt09 parasitic) 
run 197248 and 197254 fakehits using AMSRW and AM++ in crate svt09. The RW was disabled. 
run 197252 same as above but with RW enabled. 
 
In the first test I made sure that the prepared hwset and mapset were ok using the parasitic mode and SPY dumps. 
With run 197248 and 197254 I sent the output of the AMSRW to an HB in crate svt09 and then I sent the HB output back to the TF in crate svt02. Those two run where sucessuful. 
 
Run 197252 did not work, because the output format of the AMSRW is not fully compatible with that of the old HB, it is missing the wedge info. 
We need a patch to the RW firmware in order to make it work. 
 
 
</pre>
<!-- Author: Alberto -->


<!-- Date: Sat Apr 30 18:23:22 2005 -->
<table><tr><td><a href=/elog/notebooks/svt/Sat_Apr_30_2005_182314.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-342  align='top'></a></td><td>look at wedge #4, that has been filled in with data from AMSRW and AM++ in crate svt09.</td></tr></table>
<!-- Author: Alberto -->


<!-- Date: Thu May 5 10:58:38 2005 -->
<pre>The infamous version v2_0b of spymon is now online. 
Includes the spydumps from fast abort merger. 
They will appear as soon as there will be some data 
inside. 
Also the debug output from Neu beam width fitter as been  
curbed a bit. 
 
v2_0b is now devel version of spymon and is chosen 
by default at boot-time. All crates have been rebooted. 
 
In case of any problem it will be enough to switch to current 
version which still point to the version which was running  
up to now.</pre>
<!-- Author: Marco & Benedetto -->


<!-- Date: Sat May 7 15:31:38 2005 -->
<pre>Today i have restored the svtmon v2_0a in the boot file of the svtcrates and then i have rebooted all the crates. 
Now the crates run with the current version of svtmon, as it was until May 5.  
At the beginning of the store 4132 all the histograms and the web pages are ok. </pre>
<!-- Author: Benedetto -->


<!-- Date: Sun May 8 16:19:21 2005 -->
<pre>Today we have fixed the code of svtmon v2_0b and loaded again it on all the crates. 
We have tested the histograms, the printout of the crates and the web pages using fakehits run and all is ok. 
The v2_0b now is the development version and run on all the crates, the boot script too point to this version. 
The v2_0a remain the current version. </pre>
<!-- Author: Benedetto -->


<!-- Date: Mon May 9 10:18:03 2005 -->
<pre>We disabled the beam fit in the GB for the fakehits configuration</pre>
<!-- Author: Alberto & Roberto -->


<!-- Date: Mon May 9 18:44:06 2005 -->
<pre>Summary of today test w/o beam: 
 
run 197729 tryed to config with a new hwset/mapset in preparation for tomorrow test 
run 197736 use svt09 with RW active to feed TF in w04</pre>
<!-- Author: Alberto -->


<!-- Date: Tue May 10 21:34:45 2005 -->
<pre>Today we did a first test with beam of the AMSRW and AM++ configured with 32k patterns. 
We had some trouble starting the run which was due to l2ctrl. 
Daniel rebooted the l2ctrl pc and then it worked. 
In the end we were able to take 2 minutes of data. 
Since there were troubles starting the test, we took svt09 out of the run control partition. This was done mainly to avoid potential reformatter errors. svt09 has been coldstarted separately.</pre>
<!-- Author: Alberto -->
<!-- Comment: Tue May 10 21;54;14 comment by...Alberto -->
<pre>Run is 197769. I put a copy of the files from the lookarea into npisa21:/data/npisa21/a/annovi/lookarea</pre>


<!-- Date: Thu May 12 08:47:02 2005 -->
<pre>This morning we took a second test run. 
The RW in AMSRW for wedge 4 was left disabled on purpose. 
This time we got 70k events with a 30 minutes run. 
The run # is 197813 and lookarea files are located in:  
npisa21:/data/npisa21/a/annovi/lookarea</pre>
<!-- Author: Alberto -->


<!-- Date: Fri May 13 12:48:33 2005 -->
<pre>Today I took 2 fakehits runs using svt09 for wedge 4, and sanding the output to the look area. 
They are run 198055 with RW enabled 
and run 198056 with RW disabled.</pre>
<!-- Author: Alberto -->
<!-- Comment: Fri May 13 13;00;04 comment by...Alberto -->
<pre>Run 198056 might have some problem, so I took another one: run 198057.</pre>


<!-- Date: Fri May 13 13:03:36 2005 -->
<pre>We gave two gold SVT cables to Sakari. 
One is about 20cm long, the other is about 130cm. 
BTW, I gave a very long one, several meters, to Peter a month or so ago.</pre>
<!-- Author: Alberto & Roberto -->


<!-- Date: Sun May 15 14:02:07 2005 -->
<pre>Today I tried to check if the small 3 slot backplane plugin for the AMBUS P3 fits into the trackeing crates. 
I went to crate svt00 and took off 2 of the metal closing "caps" from the back of the crate. 
The plugin would fit as it fits on the back of svt09. 
However the metal closing "caps" would not fit back with the plugin insterted. I.e. we will have to modify them a little bit. 
Finally, I put the 2 metal closing "caps" back in place.</pre>
<!-- Author: Alberto -->


<!-- Date: Wed May 18 02:03:41 2005 -->
<pre>The Bypass has been re-inserted in SVT. 
Run 198159.</pre>
<!-- Author: Anna Maria -->


<!-- Date: Wed May 18 11:52:02 2005 -->
<pre>We took Pulsar #3167 and reprogramed it with SVT TX firmware. 
It is now located in crate svt09.</pre>
<!-- Author: Alberto & Paolo -->


<!-- Date: Wed May 18 15:47:16 2005 -->
<pre>==== here is what wrote in the main shift e-log ===== 
 
Wed May 18 15:46:24 
 
SVT fast abort is now enabled (after firmware bug fix, thanks Anna Maria). For the current high 
lumi table run, the online average L2 latency reduced by 3 us or so at the beginning of run.   
 
We will keep the fast abort enabled from now on. 
 
 - Ted and Roberto :: (run 198206)</pre>
<!-- Author: Ted -->


<!-- Date: Mon May 23 19:43:05 2005 -->
<pre>Run # 198522 (03077a) is a short test run with a SVT TX board sending data directly to a SVT RX. It can be used to look at the TP2D data format offline.</pre>
<!-- Author: Alberto -->


<!-- Date: Tue May 24 10:10:25 2005 -->
<pre>Jahred has been crying for latest and greatest Leonardo and QII. 
Since he is doing good work, I installed the lastest versions on the SVT teststand PC. QII is now 4.2, and Leonardo is 2004a.30. 
He promised me that he will get TF work at or above 80 MHz.</pre>
<!-- Author: Ted -->


<!-- Date: Wed May 25 15:33:36 2005 -->
<pre>run 198589 (0x307bd) is a test run with a few events being sent from a SVT TX board. The incoming hits are received into a SVT RX board for timing measurements. 
The output from HB, after AMSRW and AM++ processing, is received into a second SVT RX board.</pre>
<!-- Author: Alberto -->
<!-- Comment: Wed May 25 16;17;23 comment by...Alberto -->
<pre>Actually run 198589 has some cabling mistake.
The good run is 198591 (0x307bf) which is a test run with a few events being sent from a SVT TX board. The
incoming hits are received into a SVT RX board for timing measurements. 
The output from AMSRW is received into a second SVT RX board.
RW is disabled.</pre>

<!-- Comment: Thu May 26 16;28;33 comment by...Alberto -->
<pre>run 198620 has the same configuration but with the 2 SVT RX boards running at 60MHz, input MRG at 32MHz and AMSRW at 30MHz.</pre>

<!-- Comment: Thu May 26 18;56;16 comment by...Alberto -->
<pre>run 198620 had some manual HRR and it has bad timing measurements.
run 198621 and 198622 are same as 198620 but without HRR.</pre>

<!-- Comment: Thu May 26 19;05;03 comment by...Alberto -->
<pre>run 198625 is receving hits on both SVT RX boards</pre>

<!-- Comment: Thu May 26 19;09;15 comment by...Alberto -->
<pre>run 198626 is same as 198622</pre>


<!-- Date: Fri May 27 12:51:07 2005 -->
<pre>Swapped AM board #16 in crate 4 slot 19 with #01. 
There were mismatches between data and simulation in wedge 9. 
AM board 16 failed am_data_loop test.</pre>
<!-- Author: Roberto -->


<!-- Date: Fri May 27 14:38:31 2005 -->
<pre>All previous runs are bad for different reasons. 
Run 198673 is good. It has the same configuration of run 198620. 
The frequency of the boards are: 
SVT TX 40MHz 
MRG    32MHz 
AMSRW  24MHz (RW off) 
SVT RX 40MHz (receving hits) 
SVT RX 50MHz (receving roads) 
 
Run 198662 is same as 198673 but the HB is included. 
The frequency of the boards are: 
SVT TX 40MHz 
MRG    32MHz 
AMSRW  24MHz (RW off) 
HB     24MHz 
SVT RX 40MHz (receving hits) 
SVT RX 50MHz (receving HB output) 
</pre>
<!-- Author: Alberto -->


<!-- Date: Fri May 27 19:18:04 2005 -->
<pre>The previous run had the BITMAP enable which is not working with the oldHB. 
So I took another set of runs with the BITMAP disabled. 
 198687 BITMAP disabled, RW disabled, HB included 
 198688 BITMAP disabled, RW disabled, HB excluded 
 198689 BITMAP disabled, RW enabled,  HB excluded 
 198692 BITMAP disabled, RW enabled,  HB included</pre>
<!-- Author: Alberto -->
<!-- Comment: Mon May 30 11;41;28 comment by...Alberto -->
<pre>run 198689 is bad (i.e. for some reason it has RW off)
198740 BITMAP disabled, RW enabled,  HB excluded
All previous run are with 128k patterns.
 </pre>


<!-- Comment: Mon May 30 15;19;38 comment by...Alberto -->
<pre>The correct list of runs is:
 198687 BITMAP disabled, RW disabled, HB included 
 198748 BITMAP disabled, RW disabled, HB excluded 
 198689 BITMAP disabled, RW enabled,  HB excluded (or 198740)
 198692 BITMAP disabled, RW enabled,  HB included</pre>
<!-- Date: Mon May 30 11:52:21 2005 -->
<pre>I just took a set of runs with 32k patterns. 
198741 32k, BITMAP disabled, RW enabled,  HB excluded 
198742 32k, BITMAP disabled, RW enabled,  HB included 
198743 32k, BITMAP disabled, RW disabled, HB included 
198744 32k, BITMAP disabled, RW disabled, HB excluded</pre>
<!-- Author: Alberto -->
<!-- Comment: Mon May 30 16;11;46 comment by...Alberto -->
<pre>198755 32k, BITMAP disabled, RW disabled, HB&TF included 
198754 32k, BITMAP disabled, RW enabled,  HB&TF included </pre>

<!-- Comment: Mon May 30 16;30;17 comment by...Alberto -->
<pre>Runs 198755 and 198754 are bad.
The correct list of runs is:
198741 32k, BITMAP disabled, RW enabled,  HB excluded 
198742 32k, BITMAP disabled, RW enabled,  HB included
198761 32k, BITMAP disabled, RW enabled,  HB&TF included  
198743 32k, BITMAP disabled, RW disabled, HB included 
198744 32k, BITMAP disabled, RW disabled, HB excluded
198762 32k, BITMAP disabled, RW disabled, HB&TF included 
</pre>


<!-- Date: Wed Jun 1 16:57:51 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-345&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-346  width='300' align='top'></a></td><td>Today wit Jahred and Alberto we have tested the latest version of svtmon for b0svt09. This version includes the spydumps and the histograms of the AMSRW and the TFPP. We have observed data in each  of them.</td></tr></table>
<!-- Author: Benedetto -->


<!-- Date: Wed Jun 1 17:20:41 2005 -->
<pre>Edited the bootup script for the test stand crate so that it loads the svtvme libraries in my home directory ~jahred/work/svtvme. This  will make testing much easier for now (since SVT upgraders can use two crates at a time).</pre>
<!-- Author: Jahred -->
<!-- Comment: Wed Jun  1 17;44;28 comment by...Jahred -->
<pre>Well, the test stand doesn't have enough memory to cs the TF++, so I've put things back the way they were.</pre>


<!-- Comment: Fri Jun  3 15;55;56 comment by...Jahred -->
<pre>Now that we've updated the CPU in the test stand crate, I'm once again loading my personal svtvme libraries on tstsvt1.</pre>
<!-- Date: Thu Jun 2 16:19:51 2005 -->
<pre>I today Bill gave us two additional 5500 CPUs. 
One is for tstsvt2, the new test stand crate that will be the permanent vertical slice test. We put the other one in svt09. 
So, I put bank in place the 2304 that was sitting in svt09 that I temporarly took from tstsvt1 a few month ago. 
The 2301 that originally was in svt09 and then in tstsvt1 has been returned. 
 
The final picture is: 
tstsvt2, svt09: 5500 
tstsvt1: 2304 
2301 returned 
</pre>
<!-- Author: Alberto -->
<!-- Comment: Thu Jun  2 18;15;00 comment by...Alberto -->
<pre>Bill installed a new kernel into the 5500CPU for svt09.
The new kernal allow us to use up to 512MB of memory.
However this kernel is known to have some troubles with the network interface.</pre>


<!-- Date: Fri Jun 3 08:29:26 2005 -->
<pre>I just took the GB spare and the RW spare off crate svt06. 
GB spare is now in crate svt09. 
RW spare is in the teststand room, labeled as "RW". 
</pre>
<!-- Author: Alberto -->


<!-- Date: Fri Jun 3 08:45:07 2005 -->
<pre>I am doing some FAKEHITS testing and encountered this error  
message in b0svt06: 
 
Floating point divide by zero 
Floating point inexact 
Exception current instruction address: 0x07b3a380 
Machine Status Register: 0x0010b130 
Condition Register: 0x48000842 
Fp Control and Status Register: 0xc6008070 
Task: 0x7942138 "SPYMON" 
Stopping readout... Event 0/102147/102147 
 
I saw this occasionally last summer when I was testing svtmon  
code.  Today I saw it twice in ten minutes immediately after  
Alberto removed the spare boards from b0svt06.  Coincidence? 
Maybe - we are now running for 10 more minutes without failure. 
 
This testing was all done with the default version of svtmon with  
beamFit enabled, so it is NOT any of my new code causing this.   
</pre>
<!-- Author: neu -->
<!-- Comment: Fri Jun  3 09;33;25 comment by...Alberto -->
<pre>We took 4 runs without the GB in slot 13.
For all 4 times SPYMON crashed with a divide by 0, after about 5 minutes.
While we ran happily with the GB inserted.

On the last ran without the GB, we increased the verbosity for SPYMON, and we noticed that SPYMON was crashing just after printing messages about a MRG_OUT_SPY.
As far as we understand those messages are for the MRG in slot12.
I.e. they are for the board just before slot13.
So everything is pointing toward the GB in slot13.
We put it back in place and we are now running ok.</pre>

<!-- Comment: Fri Jun  3 11;22;32 comment by...Alberto -->
<pre>Then I tried replacing the spare GB board in slot 13 with another GB board, which is labled "need to connect flash memory" and so it might be out of date ....
Even in this case we get the "Floating point divide by zero" error. </pre>



<!-- Date: Fri Jun 3 17:05:15 2005 -->
<pre>List of test run I'm taking: 
198942 svt09 readout SVTD and SVDD.  
198943 svt09 readout SVDD.  
198944 svt09 readout SVDD.  
198945 svt09 readout SVDD. But no beam info.</pre>
<!-- Author: Alberto -->
<!-- Comment: Fri Jun  3 19;12;26 comment by...Alberto -->
<pre>198968 fakehits with svt00-svt09. SVDD has two block block #9 from svt09 and block #5 from svt06. But no data in svt09.
198970 fakehits with svt00-svt09. SVDD has two block block #7 from svt09 and block #5 from svt06. But no data in svt09.
198973 fakehits with svt00-svt09. SVDD has two block block #7 from svt09 and block #5 from svt06.  With data in svt09.</pre>

<!-- Comment: Fri Jun  3 20;01;38 comment by...Alberto -->
<pre>run 198978 is fakehits with svt00-svt09.
SVDD has two block block #7 from svt09 and block #5 from svt06.
RW in AMSRW is enabled!

run 198980 is the same but with RW disabled.</pre>


<!-- Date: Tue Jun 7 21:35:03 2005 -->
<pre>Run 199075 is a svt09 standalone run. 
The GB board produce the SVDD bank. 
The GBcabledata header for svt09 has been changed to: 
0x10e00ff in order to make it different from the timing measurment of svt06. 
</pre>
<!-- Author: Alberto -->
<!-- Comment: Tue Jun  7 21;35;24 comment by...Alberto -->
<pre>this is in preparation for tonight test :)</pre>


<!-- Date: Wed Jun 8 05:22:54 2005 -->
<pre>We are taking run 199077 with svt09 in parassitic mode. 
The found tracks are being written to the SVDD block #7.</pre>
<!-- Author: Alberto & Paolo -->


<!-- Date: Thu Jun 9 17:46:41 2005 -->
<pre>The new 5500 cpu which was installed in svt09 gave us a lot of problems. 
Bill B. traced it down to a bug in the device driver for the ethernet adapter. The problem has been solved by disabling full duplex for svt09 through the network switch.</pre>
<!-- Author: Alberto -->


<!-- Date: Thu Jun 9 17:47:27 2005 -->
<pre>We are taking data with svt09 in parassitic mode. 
Today RW for AMSRW is enabled while fastabort and killOnBit18 for all crates are disabled.</pre>
<!-- Author: Alberto -->
<!-- Comment: Thu Jun  9 17;48;05 comment by...Alberto -->
<pre>The list of taken runs is:
199152, 199154, 199156, 199157</pre>

<!-- Comment: Thu Jun  9 17;49;25 comment by...Alberto -->
<pre>During run 199152 there was an EVB problem, that was traced to svt09. After cleaning up EVB, powercycle svt09 and reseat svt09 tracer we were running happily again.</pre>

<!-- Comment: Thu Jun  9 21;12;04 comment by...Alberto -->
Also run 199158 was taken with svt09


<!-- Date: Sun Jun 12 11:50:12 2005 -->
<pre>We are taking data including svt09. 
Today configuration is: 
- AMSRW with RW disabled 
- a normal RW is inserted between HB and TF 
- killonbit18 and fastabort are disabled 
 
First run 199224 was very short. 
Second run is 199225 was short also, because of troubles with the accelerator.</pre>
<!-- Author: Alberto -->


<!-- Date: Mon Jun 13 15:34:41 2005 -->
<pre>Minicom access for tstsvt2 is through: minicom ttyC160 </pre>
<!-- Author: Alberto -->


<!-- Date: Sat Jun 18 16:51:54 2005 -->
<pre>I've installed the new patterns and costants that Jahred has produced last night. The beam position used for the generation is 
(x=-0.0872,y=0.1654,mx=0.0005652,my=0.0001236) 
</pre>
<!-- Author: Stefano -->


<!-- Date: Mon Jun 20 19:47:47 2005 -->
<pre>We are taking data including svt09.  
Today configuration is:  
- AMSRW with RW disabled  
- a normal RW is inserted between HB and TF  
- killonbit18 disabled  
- "slow abort" i.e. wait for svt09 is active 
 
run # is 199657</pre>
<!-- Author: Alberto -->


<!-- Date: Mon Jun 20 20:41:06 2005 -->
<pre>I changed the mapset file to use exactly 32k patterns for w00 and w04.</pre>
<!-- Author: Alberto -->


<!-- Date: Wed Jun 22 08:44:09 2005 -->
<pre>We are taking data including svt09.   
Today configuration is:   
- AMSRW with RW disabled (and no normal RW) 
- killonbit18 enabled 
- RW in w04 is disabled as well 
- "slow abort" i.e. wait for svt09 is active  
 
run # is 199727</pre>
<!-- Author: Alberto -->


<!-- Date: Wed Jun 22 11:04:55 2005 -->
<pre>I've removed the board 31 from crate 04 sl 18. I've put instead of it board 04. The database needs to be updated. I hadn't time to test the old board, but from the SVTmon report it looks like we have a higher failures rate in that wedge and the last board change  made by Roberto, seemed not to solve the problem.</pre>
<!-- Author: Stefano -->


<!-- Date: Wed Jun 22 12:54:31 2005 -->
<pre>Today we bypassed with a short cable the RW for w04. 
After that we run fakehits and w04 was having almost 0% efficiency. 
The solution was to powercycle crate svt08. 
I suspect that since we never reset the FIFO for RW boards, not even at coldstart or HRR, the FIFO might get into a strange state when touching the cables. In my hypotesis this is due to the fact that there are actually 2 FIFOs that can get out of sync when touching the cable.  
I think that this might be the same problem we have seen month ago with the RW. 
I would suggest to powercycle the RWs in case of troubles with the RWs or after touching any RW cable. 
</pre>
<!-- Author: Alberto -->
<!-- Comment: Wed Jun 22 22;53;40 comment by...Ted -->
<pre>always reset the FIFOs in firmware (all FIFOs, internal or external) during CDF Recover. I told this to Roberto last year. I assume that this is taken care of in the new AMS/RW Pulsars.</pre>
<!-- Date: Wed Jun 22 16:41:13 2005 -->
<pre>Almost all SRAM mezzanines for SVT Pulsars are now in the teststand room.</pre>
<!-- Author: Alberto -->
<!-- Comment: Fri Jun 24 16;06;44 comment by...jahred -->
<pre>All (100%) of the mezzanines are @FNAL (or in Pisa).</pre>


<!-- Date: Fri Jun 24 16:09:16 2005 -->
<pre>I've had trouble today using the SVT test-stand computer (NCDF110) to program boards using QII. I get a jtag error when I try to configure the ByteBlaster: "Attempted 
to access JTAG server -- internal error code 82 occcured" 
 
The problem remains when I power-cycle the computer, when I use different versions of QII, when I unplug/replug in the cables, and even when I reinstall the QII drivers (as per Sakari). This was working yesterday. Hopefully we'll get some help with this on Monday. In the meantime, use the Pulsar test-stand crate on the other side of the room for programming boards.</pre>
<!-- Author: jahred -->
<!-- Comment: Fri Jun 24 16;17;19 comment by...jahred -->
<pre>Use ncdf17 and the upper half of 2TSO3 - just don't touch the bottom part of the crate (so I was told by Sakari)</pre>


<!-- Date: Tue Jun 28 10:54:17 2005 -->
<pre>This morning I tested v2_0c of svtmon.  This version can be found 
in the standard area 
 
   /cdf/code-common/cdfonline/svtmon/v2_0c 
 
This code is completely compatible with v2_0b.  What's new is the  
version2 of the beam-width fitter, code that runs within the  
SVTbeam portion of svtmon.   
 
The code has been tested several times, both in-between stores  
and at low luminosity.  A high lum test is coming in the next  
store, which would have been this morning if not for the quench  
and lost stack.  I do not expect there to be any problems. 
 
v2_0c has been made the "devel" version of svtmon and will  
remain so unless the whole-store test coming up indicates that 
there are problems.  The "devel" svtmon version is now loaded 
by default upon reboot of b0svt06, and Aces are instructed 
to start the "devel" versions of SVTSPYMON and spy_manager on 
dap85 in the event of troubles.  So v2_0c should be picked 
up automatically.  </pre>
<!-- Author: neu -->
<!-- Comment: Wed Jun 29 17;08;45 comment by...neu -->
<pre>There was a small problem at the beginning of the last store: 
the values for the width of the beam and its errors were not 
properly initialized and took on NaN as their values; 
spy_manager did not know how to send such a value to ACNET
and promptly crashed.  

I got spy_manager to work at the beginning of the last store once
the width was fit for the first time and was sending real values
to ACNET.  That was a temporary fix.

I wrote in some protection to prevent this type of problem from 
happening, and tested it today.  The fix worked, and the new
code was put into CVS, compiled into v2_0c of svtmon and is
currently running in beam.  There have been no troubles 
since the fix was implemented.

This version remains the default svtmon ("devel" version) that 
is picked up by b0svt06 every time it is rebooted; also the Ace
instructions for restarting spy_manager and svtspymon will
also pick up this version.</pre>


<!-- Date: Wed Jun 29 19:04:29 2005 -->
<pre>We are taking data including svt09.    
Today configuration is:    
- AMSRW with RW disabled  
- normal RW enabled 
- killonbit18 enabled for SVT and not for svt09 
- "slow abort" i.e. wait for svt09 is active   
 
run # is 200231</pre>
<!-- Author: Alberto -->


<!-- Date: Thu Jun 30 11:23:22 2005 -->
<pre>I got administrator privileges on NCDF110, which now has the updated drivers for Quartus. The programmer function once again works.</pre>
<!-- Author: jahred -->
<!-- Comment: Fri Jul  1 01;18;46 comment by...Ted -->
<pre>nice to see Jahred is a happy boy once again...:)</pre>
<!-- Comment: Fri Jul  1 11;20;52 comment by...jahred -->
<pre>Well, it turns out that with the latest updates you need admin privileges to program in QII. No idea why, but I requested that Ivan and Paolo get this access as well.</pre>
<!-- Date: Thu Jun 30 13:42:59 2005 -->
<pre>I checkout 2 Pulsars from prep. 
Pulsar # 3169, property # 570744, serial 014240-0008 
Pulsar # 3170, property # 570615, serial 014240-0011 
Pulsar # 3169 will be used by Jahred as a second TF++ 
Pulsar # 3170 is spare. It is located in the crate on the floor just after the door of the teststand room</pre>
<!-- Author: Alberto -->
<!-- Comment: Mon Jul 11 16;41;08 comment by...Alberto -->
<pre>Pulsar # 3170 has been programmed as AMSRW.</pre>
<!-- Date: Mon Jul 4 21:26:14 2005 -->
<pre>AM board #12 in crate svt01 (slot9) didn't coldstart. 
I replaced it with #02 and now it is ok.</pre>
<!-- Author: Alberto -->


<!-- Date: Tue Jul 5 14:42:51 2005 -->
<pre>I've tested the boards 12,16 and 31. 16 and 31 were removed because of large failure rates in b0svt09. And they looks fine. AM #12 is the one that Alberto swapped yesterday. It had a fuse blown.  
 
There's a problem with the DB: all the informations stored before the 27th of May are not shown in the webpage. They are stored in tools/am_test/archive. 
 
Now all the 3 board are fine and are located int teststand.</pre>
<!-- Author: Stefano -->


<!-- Date: Wed Jul 6 09:51:51 2005 -->
Today I have changed the HF in W5 (crate b0svt02 sl. 13) as we had a higher failure rate in the B0,B1 in that wedge. I took the board from the teststand. The old one is now in the crate beside the test stand, flagged as "probably bad".
<!-- Author: Stefano -->


<!-- Date: Wed Jul 6 17:50:56 2005 -->
<pre>svt09 is now receiving a copy of MRG data from wedge 00.</pre>
<!-- Author: Alberto -->


<!-- Date: Thu Jul 7 16:11:08 2005 -->
<pre>We are taking data including svt09.     
Today configuration is:     
- AMSRW with RW disabled   
- normal RW enabled  
- killonbit18 enabled for SVT and not for svt09  
- "slow abort" i.e. wait for svt09 is active    
</pre>
<!-- Author: Alberto -->
<!-- Comment: Thu Jul  7 16;22;21 comment by...Alberto -->
<pre>- AM++ readout sorted by roadID

run # 200660</pre>

<!-- Comment: Thu Jul  7 18;13;24 comment by...Alberto -->
<pre>also run # 200661</pre>


<!-- Date: Thu Jul 7 18:20:34 2005 -->
<pre>We are taking data including svt09.      
Today configuration is:      
- AMSRW with RW enabled    
- AM++ readout sorted by roadID 
- normal RW bypassed  
- killonbit18 enabled for SVT and not for svt09   
- "slow abort" i.e. wait for svt09 is active      
 
run # 200662</pre>
<!-- Author: Alberto -->
<!-- Comment: Thu Jul  7 19;46;21 comment by...Alberto -->
<pre>also run # 200663</pre>



<!-- Date: Mon Jul 11 21:24:39 2005 -->
<pre>I've changed the AMS in b0svt04/slot 17 (wedge 9 of SVT). I took Fake Hits and everything looks fine so I keep the new board in the crate. I've done this to check if the failures in the W9 are given by the AMS.</pre>
<!-- Author: Stefano -->


<!-- Date: Wed Jul 13 18:14:39 2005 -->
<pre>Run 200961 is a svt09 standalone run with readout AMSRW DAQ buffers. Only the input DAQ buffer is readout. 
 
Run 200962 reads out both input and output AMSRW buffers. 
</pre>
<!-- Author: Alberto -->
<!-- Comment: Wed Jul 13 21;35;26 comment by...Ted -->
<pre>somehow run 200962 didn't show up in the shift e-log. this happened to us before as well. still wondering what could be wrong with the system.

in any case, if you can readout the input&output DAQ buffers, it is a milestone for SVT upgrade in my mind.  cheers.</pre>