Transcript drvTs upgrade review

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…?)