EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Timestamp (drvTS) progress
From: Korhonen Timo <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'Thompson, David H.'" <[email protected]>, [email protected], [email protected], "'Chernousko, Y \(Yuri\)'" <[email protected]>, "'Kalantari Babak'" <[email protected]>, [email protected], "'Williams Jr, Ernest L.'" <[email protected]>
Date: Wed, 10 Mar 2004 10:23:40 +0100
Hi all,

thank you for the comments. Our idea also is to hook to NTP and to have smoothly (monotonously) advancing time. We are trying to do this stepwise to understand the points well before advancing. The comment
on the watchdogs was good.

I made some experiments already a while ago by taking a piece
of NTP code (PLL part) and hooking it to the master timer code in
drvTS. It (sort of) functioned, but then some minor details
held me back from proceeding with this. Also back then, NTP was not
available in vxWorks but now it is (SNTP.)

We try to put together a summary of what we have done so far. I am not
sure if an ioc core meeting is scheduled for the next meeting, but
maybe we could find some time to discuss these issues there.

regards,

Timo

Jeff Hill wrote:
I agree that a PLL would be used to produce a smoothly advancing time
estimate for the epicsTime feed, and that the vxWorks tick counter should
not be changed. On vxWorks, the two inputs to the PLL would be the register
that counts off the vxWorks tick (there is an unpublished interface for this
that is used by windview) and a periodic time sync event from the network
(or alternatively from a real time clock).

Jeff


-----Original Message-----
From: Thompson, David H. [mailto:[email protected]]
Sent: Tuesday, March 09, 2004 11:59 AM
To: Korhonen Timo; [email protected]; [email protected]; Chernousko, Y
(Yuri); Jeff Hill
Cc: Kalantari Babak; [email protected]; Williams Jr, Ernest L.
Subject: RE: Timestamp (drvTS) progress

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]

h


--
Timo Korhonen  PSI (Paul Scherrer Institut)
               CH-5232 Villigen PSI
               tel + 41- 56 3103262  fax + 41 - 56 310 3383
e-mail:	       [email protected]


References:
RE: Timestamp (drvTS) progress Jeff Hill

Navigate by Date:
Prev: RE: Bug in MVME167 BSP? Mark Rivers
Next: Re: Timestamp (drvTS) progress Marty Kraimer
Index: 2002  2003  <20042005  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 Jeff Hill
Next: Re: Bug in MVME167 BSP? Andrew Johnson
Index: 2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024