1. Do we need fine time in NA62? Fine time means greater accuracy than the system clock of 25 ns. YES Here are some reasons we need to match identified kaons in CEDAR with measured particles in GTK there will be often more than one kaon in our system within a 25 ns time slot and we should be able to match the observed pion with one of those two kaons identified by CEDAR and measured by GTK, so we need fine time also in other detectors From the NA62TD: The guiding principles for the construction of the NA62 detectors are, therefore: accurate kinematic reconstruction, precise particle timing, efficiency of the vetoes and excellent particle identification.

2. We need fine time in NA62 How shall we handle it? From NA62 TD: A common time scale is defined by a 32-bit timestamp word, with 25 ns LSB and covering the full duration of the interval between two consecutive SPS spills, plus an 8-bit fine time word, with 100ps LSB. While the timestamp will be defined in each system by the phase-coherent distributed clock, each sub- system will locally generate by multiplication a properly locked reference for the fine time. Note: 32bit of 25 ns ticks is roughly 107 seconds, enough to label 25 ns time slots within one spill. Note: rx chip by itself does not have 32 bit BC counter, the 32 bits should be provided by firmware

3. We need to match identified kaons in CEDAR with measured particles in GTK Problem in GTK: there is 750MHz of particles, that is on average 1 particle per 1 ns (very crude!) So time stamping should be much better than 1 ns in both CEDAR and GTK to match the reading of the two. Conclusion we need 100 ps time stamping in CEDAR and GTK And we need to learn how to synchronize those fine time stamps. CEDAR GTK matching

4. Stability is a key word. So investigation of stability of all the procedures mentioned above is essential to adopt it as a working scheme. What concerns the BC clock we assume that every subdetector sends info after SOB and after EOB, and comparing those two we check that BC offsets are stable during one spill. What concerns the fine time, we are not aware of any similar procedure. If we manage somehow to find correct synchronizing offsets between various nodes (for example by some offline statistical analysis), we should also check for stability somehow, maybe for each spill, maybe for each run.

5. TDCB and fine time Fine time stamp is assigned by the TDCB for each event, but there seems to be no way to read the TDCB "fine time counter" by some outer command independent of the event. This makes synchronization difficult. One can always use sparse beam and obtain fine time stamps for the same particle in every node. One can perhaps do some off-line statistical analysis also for the dense beam. But there will be certain asymmetry in the level of care for the BC clock synchronization stability and the fine time synchronization stability. So before ordering a massive production of TDCB's we perhaps should give a second thought whether we really do not need access to its internal "fine time clock" form outside.