| The Time distribution system [message #1246] |
Wed, 08 December 2004 10:37  |
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  |
|
|
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 |
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 |
|
|
| 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
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
