# Presentation: 082779

## drvTS progress (at SLS)

- Timo Korhonen, Babak Kalantari
-  PSI

## Outline

- drvTS modifications done at PSI
- Plans to proceed

## Modifications to drvTS

- To take the hardware-synchronized timestamps into operation, we have made several modifications to the timestamp driver code (drvTS) of the (3.13) base distribution
- Bugfixes
- Enhancements

## Modifications

- Failover: in the absence of timing events or a failure of the event distribution (disconnected cable, EVR failure, etc.) the client automatically switches to soft timing mode (before: time at client stopped.)
- Always keep both HW and sof timing running and synchronized
- Smooth transition with (practically) no jump in time
- Internal state available as EPICS channels
- Device support to provide access to the internal state
- Switching between modes, alarms, etc.

## Modifications

- Several issues related to startup fixed
- Configuration checked, validity of timing link checked (used to go into HW timing if an EVR was in but not properly configured)
- Soft timing had problems related to finding a NTP host
- Always tried to look for a master timing IOC, even if configured to listen to NTP (problem with development systems...)
- Issues with the ioc clock and vxWorks clock being out of sync
- Some applications looked at the vxWorks clock

## Status

- Modified drvTS in operation for about one year
- Robust (at least the HW timestamp part)
- Recently found an issue with the soft timing startup: if NTP server not found at the beginning, will remain in a loop forever (waiting for a master timing ioc to show up.)
- We think to have a fairly good understanding of the behaviour
- Although we did not realize the recent issue with resyncs at APS (Marty et.al.)

## How to proceed?

- Should the modifications to drvTS be distributed?
- Were mainly done for our internal purposes, to check our understanding of drvTS behavior
- Re-writing of the code has been planned and we are (finally!) putting together the specs
- Marty was in favor of waiting for the rewrite (but it might still be quite a while before it is finished)
- In the meantime, some people might benefit
- We have resources to work on this (Babak Kalantari)

## How to proceed?

- A specification for re-write is under preparation
- The idea has been to integrate NTP as a common software clock instead of the tick/watchdog method used in drvTS now
- Could improve resolution and accuracy of soft timing a lot
- Essentially, the HW timestamping (for APS/SLS/Diamond) type would remain as is
- Diamond has some new features that can be easily accommodated
- Plug-in possibility for other timing systems are foreseen
- A minimal set of features will be required

## Near-term plans

- Publish the spec for community review
- Put the spec on a website, with a discussion forum (comments can be added on-line)
- Good ideas and comments are welcome
- Gather modifications that have been done at various places
- “Magic” numbers to get timestamp from dev support (Dave Thompson)
- Resync behaviour
- More...
- Question: is this still interesting to the community?
- Is it worthwhile to attempt an unified solution or are the needs too diverse?
- The situation is a bit unclear at the moment (for a long time, we did not have resources to seriously work on this. Now we would, but has the train already left the station...?)