[Halld-level1] Data stream scalers, summary of the meeting

[David Lawrence]

Hi Elliott,

   I agree that we need to keep track of what is running on the ROC. 
However, it seems like it will be hard to make any decisions until we 
have a ROC with a CPU of the type we intend to deploy. We'll need to run 
tests to see just what the resource usage is. If we end up with a 
quad-core SBC running 10 servers, but each only taking 1% of a CPU, 
we'll be using only 2.5% of the available cycles. In that case, there 
may be no problem to solve. When do we expect to have a SBC of the type 
we will deploy for physics?


-David

On 1/23/12 4:10 PM, Elliott Wolin wrote:
> Hi,
>
> Alex raises an important point.  ROC's must handle the full data rate
> and cannot have extraneous processes running on them that might
> interfere.  I've heard of a number of servers people want to see running
> on the ROC's, probably too many.  We have to carefully consider every
> process that runs on a ROC, and may need to combine the functionality of
> multiple servers into a smaller number (perhaps just one...).
>
> I will put this topic (servers) on the Online meeting agenda next week.
>
> Alex...I'd like to put you on the agenda next week to present the work
> on scalers you described in your email...let me know if you have a
> scheduling conflict.
>
> Thanks,
>
>
>
> On 01/23/2012 03:45 PM, Alexander Somov wrote:
>> Hi,
>>
>> The server runnning on the ROC might not be just an EPICS IOC,
>> but more complicated. It should handle messages/requests
>> from other debugging programs and provide an arbitrage for
>> accessing registers. For the trigger debugging I would not rely
>> on EPICS but just use 'standalone' debugging tools.
>>
>> At high rate we have to be sure that EPICS doesn't interfere with
>> the CODA readout (it should not, but has to be checked). Anyway,
>> the data stream scalers themself should provide a reasonable
>> online dq/monitoring tool.
>>
>> Cheers,
>>          Sascha
>>
>>
>>
>> Hi Dave,
>> There will be scalers that will be available for monitoring
>> programs. These registers will be written and readout independent
>> of CODA DAQ. This info is going to be available in EPICS for general
>> purpose monitoring.
>> Whenever there is a need, we will have EPICS IOC running on the VXS
>> crates CPU.
>> At least that is the plan.
>> Hovanes.
>>
>> On 01/23/2012 01:32 PM, David Lawrence wrote:
>>> Hi Sasha,
>>>
>>>       Are they counting even when the DAQ system is not currently taking
>>> data? I would think we would want an out-of-band way of getting at the
>>> scalers. That way, we can display them at any time (e.g. while tuning
>>> the beam in between runs). Maybe you mentioned something about this
>>> before...?
>>>
>>> -Dave
>>>
>>> On 1/23/12 1:25 PM, Alexander Somov wrote:
>>>> Hi Elton,
>>>>
>>>> A good point.
>>>>
>>>> You don't need to disentangle the whole events.
>>>> Scalers will have a tag in the fadc event block;
>>>> one will need to search for the corresponding tags
>>>> only; should be straight forward.
>>>>
>>>> Cheers,
>>>>             Sasha
>>>>
>>>>
>>>>
>>>> On Mon, 23 Jan 2012, Elton Smith wrote:
>>>>
>>>>> Hi Sasha,
>>>>>
>>>>> Thanks for the summary. In mode a) can easily scan through a file and
>>>>> pick out the events with scalers (without disentangling the whole
>> event)?
>>>>> Elton Smith
>>>>> Jefferson Lab MS 12H5
>>>>> 12000 Jefferson Ave
>>>>> Suite #16
>>>>> Newport News, VA 23606
>>>>> (757) 269-7625
>>>>> (757) 269-6331 fax
>>>>>
>>>>>
>>>>> On 1/23/12 9:10 AM, Alexander Somov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I brief summary of the data stream scaler
>>>>>> implementation  discussion last Friday
>>>>>> (Jan 20th, 2012):
>>>>>>
>>>>>> 1. Scalers will be integrated into the data readout
>>>>>> block of each FADC; they will be readout using DMA.
>>>>>>
>>>>>> 2. There are two ways of the implementation:
>>>>>>         a) scalers will be added to the last event in
>>>>>>            the block. A user needs to specify the block
>>>>>>            prescaling factor, i.e., the number of blocks
>>>>>>            after which the scalers should be added
>>>>>>            (for instance, add scalers in each 10000's readout
>>>>>>            blocks).
>>>>>>         b) Scaler readout will be handled by the special
>>>>>>            trigger type generated by the TS (the trig2 line
>>>>>>            going from the TI to the fadc can, for instance, be
>>>>>>            used for the scaler trigger distribution). Similar
>>>>>>            to a), scalers will be added to the readout block.
>>>>>>            Implementing this mode will require more efforts.
>>>>>>
>>>>>> 3. Edd and Bryan will start implementing mode a).
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>             Alex
>>>>>> _______________________________________________
>>>>>> Halld-level1 mailing list
>>>>>> Halld-level1 at jlab.org
>>>>>> https://mailman.jlab.org/mailman/listinfo/halld-level1
>>>>> _______________________________________________
>>>>> Halld-level1 mailing list
>>>>> Halld-level1 at jlab.org
>>>>> https://mailman.jlab.org/mailman/listinfo/halld-level1
>>>>>
>>>> _______________________________________________
>>>> Halld-level1 mailing list
>>>> Halld-level1 at jlab.org
>>>> https://mailman.jlab.org/mailman/listinfo/halld-level1
>>> _______________________________________________
>>> Halld-level1 mailing list
>>> Halld-level1 at jlab.org
>>> https://mailman.jlab.org/mailman/listinfo/halld-level1
>> _______________________________________________
>> Halld-level1 mailing list
>> Halld-level1 at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-level1