Difference between revisions of "Feb 2013"

Latest revision as of 15:18, 26 February 2013

Date : 6 Feb 2013 (K.Allada)

We are now using the new FADC(v2) and a fixed pulser.

I did few more checks to find out why we are getting "data not ready" errors at trigger rates beyond ~250KHz (with PTW =75 samples). This is related to datascan becoming zero for few-tens-of-events/100 triggers, and this becomes worse as we go to higher trigger rates. When this happens the event is empty. And since we do blocking, we get a empty blocks. Blocksize is 100.

Also, note that the theoretical limit (from the excel sheet) with PTW=75 samples and FADC v2 is around ~430 kHz. We should be able to take this much rate with a fixed pulser.

From the routine tiSetTriggerHoldoff(1,40,0), the trigger limit, without additional deadtime, is 40*16=640ns (= 1.56MHz). So this is fine...we are not there yet.

Below is a table showing observed data rate from the Run Control GUI for different trigger rates. It seems like the data rate is saturating at ~5K Bytes/sec ( which is around 250 KHz) and that's when the datascan becomes zero (error).

run      trigger rate    observed event rate   observed data rate    error condition

1910      31 kHz         31 kHz                 ~600 Bytes/sec         no error
1909      85 kHz         85 kHz                 ~1500 Bytes/sec        no error
1908      121 kHz        121 kHz                ~2200 Bytes/sec        no error  
1907      168 kHz        168 kHz                ~3000 Bytes/sec        no error
1906      251 kHz        251 kHz                ~5000 Bytes/sec        no error
1905      315 kHz        315 kHz                ~5200 Bytes/sec        error
1904      434 kHz        434 kHz                ~5200 Bytes/sec        error

(Note added by Bob: actually, these are kBytes/sec.  The rcgui reports incorrectly Bytes/sec.)

To check if disk is a limitation, I turned off writing to disk in the coda config. And I still see these errors. So disk may not be an issue. (adaq1 has 1.1 GB/sec speed)

Next is the network. We have 100MBits/sec (12.5 MBytes/sec). How can we max out at 5K Bytes/sec? How can I turn off transfer through the network (instead write to local memory) to check the limitation?

I tried this by replacing dma_dabufp in faRead() with dummy pointer to local memory, but I could not make it work yet. I am still seeing these errors (although now the raw data contains full of 0x000000s)

Date : 7 Feb 2013 (R. Michaels)

Info about network speed.

According to Brent Morris, we have gigabit between adaq1 and hallasfi1, so I think network should not be an issue. To check this, I tried turning off writing to the network.

Recommended procedure is to do this:

	  //	  dma_dabufp += nwords;

which allows DMA transfer but doesn't put data to network.

We see the same problems as before. About 1/3 of events have 0xda00bad2 in the datastream, and the printouts "ERROR: Data not ready in event".

Observations at high rate in integral mode:

Input 342 kHz in scalers
Busy output 3420 Hz in scalers.  This is also the "In-EvtRate" in the Run control GUI.
Block size 100 ... implies 100% livetime since 100*3420 = 342 kHz (don't believe it, though)
xcefdmp shows normal events with about 518 words or 2072 bytes.
but some events with less bytes and about 1/3 of events empty (0xda00bad2 flag).
Assuming 2/3 events have data, then expect a data rate = 2/3 * 3420 * 2072 bytes = 4.7 MBytes/sec.
I would conclude tha the "In-DataRate" field is kBytes/sec, although the histogram Y axis is labelled Bytes/sec.

K. Allada:

In the readout list a flag is added on the top to change the mode(RAW,PUSE INTEGRAL) of FADC250. You just have to change it and rest is taken care.

#define FADC250MODE 3  /* mode 1(RAW) 3(PulseIntegral) */

 The data rate histograms on coda run control are kB/sec and not bytes/sec as it indicates (its a bug!) 

Found that at high rates (> 250KHz) the fadc is skipping events. The trigger counter from the fadc sometimes increments by 25. And this number 
seems to be constant, always 25. 

Date : 20 Feb 2013 (R. Michaels)

Getting ready to test the helicity-correlated asymmetries with the new FADC DAQ. I've set up the helicity board and set up a NIM circuit to generate signals with an asymmetry and rate that is tunable. At the moment we can get 200 kHz < f < 2 MHz and 0.1% < A < 4%. Note, A and f tend to be anti-correlated.

Info about helicity board (halog 385791) http://hallaweb.jlab.org/halog/log/html/1302_archive/130214131309.html

Info about asymmetry generating circuit (halog 385793) http://hallaweb.jlab.org/halog/log/html/1302_archive/130220124926.html

Date : 21 Feb 2013 (R. Michaels)

Noticing that the DAQ was unstable in RAW mode, I let the BLOCKLEVEL be adjustable based on the FADC250MODE. For 1 (RAW) BLOCKLEVEL is 1, and for 3 (pulse integral) it is 100. This made the DAQ stable as it doesn't require too much memory. In addition, the minimum event size is observed to be MAX_EVENT_LENGTH = 1024*250. We also have MAX_EVENT_POOL = 200, though I guess this could be increased now.

The helicity bit was plugged into channel 9 and this channel enabled. BTW, it seems channel 8 does not work. I see the bit go on/off in the data. Will try to measure an asymmetry. Run 1997 is a longish run (10 min, 50K events) to hunt for an asymmetry.

What to expect ? The signal is 150 mV into the V2F with a 30 mV modulation from helicity. Given the V2F calibration f (kHz) = 200 + 210 * V, we expect about a 1.3% asymmetry on a nomimally 235 kHz signal.

Date : 25 Feb 2013 (R. Michaels)

Today I managed to find an asymmetry in the FADC. Some problems before (apart from really dumb problems) : double pulsing going to FADC and significant deadtime ("ERROR: Data not ready in event xxxx"). The former was cleaned up by adding more modules and using discriminators, and the latter (DT) is rather fatal -- it dilutes the asymmetry more than I'd expect ! I expect A_obs = A_true * (1 - DT) where DT = deadtime, so DT is effectively a dilution.

Observations of rates
Case ... Signal source to V2F .... rate (kHz) ... comment
A ...... nothing ................. 192 ........... pedestal
B ...... NIM-true DC level ....... 138 ....... subtracts from pedestal
C ...... TTL-true DC level ....... 256 ....... adds to pedestal
D ...... NIM-helicity signal ..... 192 and 138 observed, helicity-dependent, average 161
E ...... Add TTL-true to above ... 192 and 250 observed, helicity-dependent, average 227
F ...... We can add a random pulser to any of these cases, f > f_case.

Observed asymmetries
Case ...... Deadtime ? ..... Expected A ..... Observed A (in data)
A, B, or C ..... none ........ zero ........... zero
D .............. none ........ 17 % ........... 20 %
E .............. none ........ 13 % ........... 14 %
F with 126 kHz .. YES ........ 8 % ............ 0.6 % !!!!
F with 17 kHz .. none ........ 11 % ........... 10 %

The errors in A are around 1 or 2 %, I guess. I don't know how much deadtime was in the 4th test, nor do I know yet why the dilution is so big. Pretty good start, though. With no deadtime, the system makes some sense.

Later, I learned to measure f+ and f- (for + and - helicities) but looking at scalers with a NIM-true added to the V2F input (+) or not (-). This gives more precise predicted asymmetries. I also dilute the asymmetry using a random pulser to achieve a range of asymmetries. Results:

The sign of A is negative, and this agreed between data and prediction, but I show absolute value.
A = (f+ - f-)/(f+ + f-), and take abs. value.
Run .... f+ .... f- .... A predicted .... A observed (sign agreed) 
....... (kHz)... (kHz)
2034 .. 118.5 .. 128.6 .... 4.1 % ........ 4.0 %  
2035 .. 193.0 .. 128.6 .... 20 % ......... 20 %
2036 .. 224.6 .. 169.5 .... 14 % ......... 17.6 %  
2039 .. 290.4 .. 235.1 .... 10.5 % ....... 14.4 %  
2040 .. 226.2 .. 216.4 .... 2.3 % ........ 1.8 %
2041 .. 292.3 .. 282.4 .... 1.7 % ........ 1.5 %

Notice that for runs 2036 and 2039 the observed Asy is higher than predicted, while for runs 2040-41 it's lower.
Thinking ....

Date : 26 Feb 2013 (K. Allada)

There are two kinds of trigger losses in FADC at high rates (> ~250 KHz)

1. FADC can lose triggers within a block (usually trigger counter skips by 25 counts, it happens few times within a block) 2. FADC can lose an entire block (that means block_size of triggers get lost, and you get messages like "ERROR: Data not ready in event xxxx")

The deadtime calculation should take care of these two cases when this happens.

I checked two runs 1904 (434 KHz with DT=89%) and 1905 (315 KHz, DT=59%). Seem too high!