Experimental Physics and Industrial Control System
Subject: |
RE: Timestamp (drvTS) progress |
From: |
"Thompson, David H." <[email protected]> |
To: |
Korhonen Timo <[email protected]>, [email protected], [email protected], "Chernousko, Y (Yuri)" <[email protected]>, Jeff Hill <[email protected]> |
Cc: |
Kalantari Babak <[email protected]>, [email protected], "Williams Jr, Ernest L." <[email protected]> |
Date: |
Tue, 09 Mar 2004 13:59:13 -0500 |
I am glad to hear this.
I had to go part way down this path with the SNS timing system since it
has suffered with noise causing scan tasks to fail due to an assert that
checks for negative local seconds from epoch. I bridge data link
outages by counting 16.667 ms (1/60 Hz) at each event link cycle start.
If the timing system is unavailable the driver reverts to polling NTP
every minute or so. Most our time stamps are "time of last cycle
start" so the resolution is not an issue. I didn't want to spend too
much time writing an NTP client, or duplicating the one in drvTS, all of
which is in static functions. Between NTP polls I use the raw vxWorks
tick counter to calculate the elapsed time from the last poll. If drvTS
could run NTP when a hardware event system is present, with an NTP like
PLL, then if the timing system has problems the failover could be made
seamless. The hardware event driver should either fetch time from the
NTP driver or return an error if it knows that its time is invalid.
It sure would be nice to be able to configure the IOC to have a stable
NTP time available as a fallback if needed.
I would be sort of cautious about trying to sync vxWorks time. Maybe
someone knows better than I, but I would think that jumping the tick
counter would cause waiting watchdogs and IPC calls blocked with
timeouts to misbehave. If you limit it to +/- 1 tick you might get away
with it most of the time but I can think of applications from my
robotics days where that could be a problem. My approach to using the
tick counter is to use it in conjunction with an offset provided by NTP
to calculate the epics time stamp. The old driver that I inherited
here did this and caused system freezes when the timing cables were
unplugged.
-----Original Message-----
From: Korhonen Timo [mailto:[email protected]]
Sent: Tuesday, March 09, 2004 12:13 PM
To: [email protected]; [email protected]; Thompson, David H.; Chernousko, Y
(Yuri); Jeff Hill
Cc: Kalantari Babak; [email protected]
Subject: Timestamp (drvTS) progress
Hello all,
I do not remember who all were interested in this topic in the
beginning, but please feel free to forward this and also let
me know who should also be involved.
More than two years ago in San Jose we had a time stamp meeting where I
listed a number of problem points in the drvTS code. I also promised
to start working on them. Finally last autumn we (myself and Babak
Kalantari who actually has done most of the work) finally were able
to get started with this work. Since that we have already got quite
far (although many things still need to be done.)
The improvements so far include:
-monitoring of the event receiver status and the link health, fault
statistics
-automatic switching to soft timing if there are problems with
the EVR
-synchronization of the local (vxWorks) clock with the "hard" time
continually (this way we can switch from hard to soft time without
jumps)
-Channel Access interface to be able to monitor the status and to switch
between soft/hard timestamp modes
-several problems with startup were corrected (if the communication with
the master timing does not work, etc.)
-and so on...
Now the system is really robust (well, at least in lab...) The switching
happens smoothly (we tested it by pulling the plug - and could not see
any jumps in timestamps, within the available resolution.) We plan to
take this new stuff in operation at SLS in one of the next shutdowns.
The work so far has been done starting from the existing drvTS version.
Actually, we would like to rewrite the whole thing at some point and
make a better link to (S)NTP, etc., but to be sure that we understand
the issues we decided first to rework drvTS.
This might be something of interest for the next collaboration meeting.
I would be happy if you have some comments even before that.
best regards,
Timo
--
Timo Korhonen PSI (Paul Scherrer Institut)
CH-5232 Villigen PSI
tel + 41- 56 3103262 fax + 41 - 56 310 3383
e-mail: [email protected]
- Replies:
- RE: Timestamp (drvTS) progress Jeff Hill
- Navigate by Date:
- Prev:
RE: Timestamp (drvTS) progress Jeff Hill
- Next:
RE: Timestamp (drvTS) progress Jeff Hill
- Index:
2002
2003
<2004>
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Timestamp (drvTS) progress Marty Kraimer
- Next:
RE: Timestamp (drvTS) progress Jeff Hill
- Index:
2002
2003
<2004>
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024