DRS4 Forum
  DRS4 Discussion Forum  Not logged in ELOG logo
Entry  Tue Mar 20 16:23:33 2012, Martin Petriska, triger for measuring time between pulses in channels 
    Reply  Tue Mar 20 16:33:50 2012, Stefan Ritt, triger for measuring time between pulses in channels 
       Reply  Wed Mar 21 09:33:00 2012, Martin Petriska, triger for measuring time between pulses in channels 
          Reply  Wed Mar 21 09:39:33 2012, Stefan Ritt, triger for measuring time between pulses in channels 
             Reply  Wed Jun 20 10:40:21 2012, Ivan Petrov, triger for measuring time between pulses in channels 
                Reply  Wed Jun 20 12:45:05 2012, Stefan Ritt, triger for measuring time between pulses in channels 
                   Reply  Wed Jun 20 14:36:01 2012, Ivan Petrov, triger for measuring time between pulses in channels 
                      Reply  Wed Jun 20 14:44:38 2012, Stefan Ritt, triger for measuring time between pulses in channels 
                         Reply  Sat Jun 23 00:29:52 2012, Andrey Kuznetsov, triger for measuring time between pulses in channels 
                            Reply  Mon Jun 25 14:21:13 2012, Stefan Ritt, triger for measuring time between pulses in channels 
Message ID: 169     Entry time: Mon Jun 25 14:21:13 2012     In reply to: 168
Author: Stefan Ritt 
Subject: triger for measuring time between pulses in channels 

Andrey Kuznetsov wrote:

Stefan Ritt wrote:

On the evaluation board, yes. This board is not optimized for high readout rate. If you do your own electronics, like GBit Ethernet, you could be much faster. 

 What is the readout rate via GBit Ethernet that you have achieved?

Where is the bottleneck in ethernet?

What is the proposed scheme by which the GBit Ethernet will be implemented, will the DRS4 Eval Board have to wait for the computer to respond before sending the data (wouldn't this make the readout much slower?), or will the DRS4 Eval Board keep sending the data to the computer?

With GBit Ethernet you get close to 100 MB/sec, which is the maximal line speed. The protocol to be implemented will achieve that rate. What one usually does is to send events in large blocks upon request from the PC. The trick is to do the request in a clever way, like using a high water mark on the receiving event buffer. So as long as the PC can digest the data quickly enough, the board just keeps sending, which means no overhead.

 

ELOG V3.1.5-fe60aaf