90 likes | 107 Views
drvTS progress (at SLS). Timo Korhonen, Babak Kalantari PSI. Outline. drvTS modifications done at PSI Plans to proceed. Modifications to drvTS.
E N D
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…?)