GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » FutureDAQ » FutureDAQ - Time Distribution » The Time distribution system
The Time distribution system [message #1246] Wed, 08 December 2004 10:37 Go to next message
Igor Konorov is currently offline  Igor Konorov
Messages: 7
Registered: April 2004
Location: TU Muenchen
occasional visitor
From: *e18.physik.tu-muenchen.de
Dear colleagues,
here is a short description of the time distribution system
whic we are going to develope within FutureDAQ. Please make your comments and suggestions.
Regards. Igor.


Igor Konorov
Technical University of Munich
Physic Department E18
mail: igor.konorov@ph.tum.de
tel: +49-89-28912574
Fax: +49-89-28912570
Re: The Time distribution system [message #1440 is a reply to message #1246] Thu, 03 March 2005 20:43 Go to previous messageGo to next message
Walter F.J. Müller is currently offline  Walter F.J. Müller
Messages: 229
Registered: December 2003
Location: GSI, CBM
first-grade participant

From: lxg0311.gsi.de
The essential function of a time distribution system is to distribute a low jitter clock and an absolute time information. The capability to cause system wide state transitions with clock cycle precise latency allows to implement the absolute time synchronization. All this just requires an unidirectional broadcast type communication.

I'm not convinced by the proposal to add a back channel on top of a passive optical splitter network. The downlink bandwidth available in this approach is very limited, certainly less than any simple ethernet based DCS network, and very likely simply not adequate for efficient control of a larger subsystem.

There are good reasons to run data, time, and control over the same physical link on the very last hop (or 2 hops) to the FEE, mostly if this is already done on an optical link.

However, merging the DCS with the time distribution functionality on one network at the system level is for me not an appealing idea. The first level concentrators or read-out controllers seem to me the right point to connect to the time distribution on one side and a control network (very likely an ethernet) on the other side. Also, it is essential to have a processor at each endpoint of the control network, and it is very convenient to have enough resources to run a full OS. A nice example is the ALICE DCS board.

In summary, I strongly favour to have at the system level two independant networks and interfaces, one for time distribution, and one for control.


W.F.J.Müller, GSI, CBM, Tel: 2766
Re: The Time distribution system [message #1442 is a reply to message #1440] Fri, 04 March 2005 19:07 Go to previous messageGo to next message
Igor Konorov is currently offline  Igor Konorov
Messages: 7
Registered: April 2004
Location: TU Muenchen
occasional visitor
From: *e18.physik.tu-muenchen.de
Dear Walter,
it is very good that you replied and I hope we can discuss
some parts of the functionality. I do not insist on this extra function but we are still 5 years away from the real experiment and it is too early to exclude some functions of the system.
I know your personal opinion about that but I prefer to look at the arguments without adjectives just with open mind.

Arguments against:
1. the limited bandwidth

Expected TDS bandwidth is 2GBaud downlink and 1-10 MBaud/destination uplink. Many transactions can be done in broadcast mode and allow to use the link more efficient. Loading of firmware is a very good example.

One TDS subsystem will serve from few hundred up to one thousand destinations. The splitting of the TDS to subsystems is done detector wise which means number of different types of FE electronics is limited to even smaller number.

What are the functions of DCS ?

- loading firmware
- setting parameters(pedestals, thresholds, coefficients)
- collecting slow parameters T,V,I,P
- monitoring , alarm , switching OFF power
- testing FEE

The TDS provides only data link between FEs and a host computer. And from my point view it has enough bandwidth for all DCS data transfer mentioned here. If you have examples we can calculate
latencies and speed.

2. no CPU and no OS
It is correct, local monitoring is out of TDS functionality and in this case this function has to be included in the FEs or data concentrators with all required resources . As I said the TDS provides the optical data link only.
The Alice DCS card includes the TTC receiver and I believe if the TTC provided bidirectional interface it would be used instead of Ethernet.


Arguments in favour:
1. existing optical network
2. electrical decoupling
3. expected to be cheap with a possibility to include spare transmitters/fibers without additional cost

Igor.



Igor Konorov
Technical University of Munich
Physic Department E18
mail: igor.konorov@ph.tum.de
tel: +49-89-28912574
Fax: +49-89-28912570
Re: The Time distribution system [message #1444 is a reply to message #1442] Sun, 06 March 2005 15:31 Go to previous message
Walter F.J. Müller is currently offline  Walter F.J. Müller
Messages: 229
Registered: December 2003
Location: GSI, CBM
first-grade participant

From: *dip0.t-ipconnect.de
Igor Konorov wrote on Fri, 04 March 2005 19:07

... The Alice DCS card includes the TTC receiver and I believe if the TTC provided bidirectional interface it would be used instead of Ethernet.


I doubt that, but the DCS designers better speculate on this.

The key point of the DSC approach in ALICE is to have a CPU with an OS on the board, providing connectivity through TCP/IP and an environment to use a wide variety of tools building on this API.

Even though conceivable, it will probably requires a substantial effort to emulate a normal TCP/IP connection behaviour between the PC's running the control tasks and each endnode through the time distribution network.

I think the ability to have a bi-direction data channel on the time distribution network is of limited value without local inteligence (that is CPU and OS) and a standard communication API (that is TCP/IP) at the endnode.


W.F.J.Müller, GSI, CBM, Tel: 2766
Previous Topic: Is SADC data always time ordered ?
Next Topic: Usage of a campus wide frequency and time standard
Goto Forum:
  


Current Time: Thu Mar 28 15:32:54 CET 2024

Total time taken to generate the page: 0.00552 seconds