Difference between revisions of "Feb 2013"

Revision as of 18:08, 7 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

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