EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: monitors received out of order
From: "Jeff Hill" <[email protected]>
To: <[email protected]>, <[email protected]>
Date: Tue, 2 Nov 2010 10:19:02 -0600
> I am not sure what to do about it now, but I definitely have a frequent
> requirement to get a coherent set of data from a server. Up till now, I
> have monitored everything and then taken a snapshot whenever I got a
> monitor from the last item in a processing chain (which I have ensured
> always updates whenever the chain processes). This has seemed to work
> with VxWorks servers. I would like to still be able to achieve the same
> effect.
> How else can I do this?

Several client side programs have been written which wait for a complete 
set of CA subscription update data with sufficiently correlated timestamps 
providing a callback whenever a complete set, or after a timeout an 
incomplete set with flagged vacancies, arrives.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Jeff Hill
> Sent: Tuesday, November 02, 2010 9:36 AM
> To: [email protected]; [email protected]
> Subject: RE: monitors received out of order
> 
> > I find Jeff's response ambiguous, and maybe that's the problem. Jeff
> says
> > there is a per client event queue. Tim seems to imply it is per-
> > subscription. Ralf seems to imply the truth is somewhere in between, and
> > since it is more specific it has the ring of truth about it.
> 
> It depends on which server it is. The rsrv server (and current IOC
> behavior)
> is how Ralph describes, but PCAS and the new server are slightly better at
> preserving event ordering, but will still discard intermediate events if
> the
> producer is faster than the consumer.
> 
> Jeff
> ______________________________________________________
> Jeffrey O. Hill           Email        [email protected]
> LANL MS H820              Voice        505 665 1831
> Los Alamos NM 87545 USA   FAX          505 665 5107
> 
> Message content: TSPA
> 
> With sufficient thrust, pigs fly just fine. However, this is
> not necessarily a good idea. It is hard to be sure where they
> are going to land, and it could be dangerous sitting under them
> as they fly overhead. -- RFC 1925
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:tech-talk-
> [email protected]]
> > On Behalf Of [email protected]
> > Sent: Tuesday, November 02, 2010 3:27 AM
> > To: [email protected]
> > Subject: RE: monitors received out of order
> >
> > Hi All,
> >
> > I read Tim's initial post with interest because I am sure that I was
> told
> > at an early EPICS training course (probably in 1992 or 93) that monitors
> > posted to a given client within a given lockset were guaranteed to be
> > received in order (and, conversely, ca_puts from a client were delivered
> > in order). I have since used this for a lot of systems that need to
> > collect a coherent block of information. I have not known it to fail,
> but
> > I haven't looked for the 1 in a million problem, just the 1 in 100 or
> so.
> > Now this old wives tale is clearly being challenged.
> >
> > I find Jeff's response ambiguous, and maybe that's the problem. Jeff
> says
> > there is a per client event queue. Tim seems to imply it is per-
> > subscription. Ralf seems to imply the truth is somewhere in between, and
> > since it is more specific it has the ring of truth about it.
> >
> > Was my memory ever true? I have a suspicion that by the tone of his
> > message Tim may have been labouring under the same misapprehension. It
> may
> > have changed, for example, when we lifted the fixed (read 16k) CA limit.
> I
> > would agree with Tim in that in my experience it is true most of the
> time
> > - especially on vxWorks, and since I have mostly used it to get
> > synchronised hard real-time data from a server to a client, vxWorks is
> > where I have used it.
> >
> > I am not sure what to do about it now, but I definitely have a frequent
> > requirement to get a coherent set of data from a server. Up till now, I
> > have monitored everything and then taken a snapshot whenever I got a
> > monitor from the last item in a processing chain (which I have ensured
> > always updates whenever the chain processes). This has seemed to work
> with
> > VxWorks servers. I would like to still be able to achieve the same
> effect.
> > How else can I do this?
> >
> > Cheers,
> >
> > Nick Rees
> > Principal Software Engineer           Phone: +44 (0)1235-778430
> > Diamond Light Source                  Fax:   +44 (0)1235-446713
> >
> >
> > -----Original Message-----
> > From: [email protected] [mailto:tech-talk-
> [email protected]]
> > On Behalf Of Jeff Hill
> > Sent: 01 November 2010 21:42
> > To: 'Tim Mooney'; 'EPICS tech-talk'
> > Subject: RE: monitors received out of order
> >
> > Hi Tim,
> >
> > The Channel Access publish and subscribe system is a classic
> > consumer/producer situation. The producer is of course record
> > processing and the consumer is the Channel Access client side
> > application. In basic queuing theory, it is known that no
> > matter how big the finite buffer capacity between the producer
> > and the consumer, all of it will be consumed if the production
> > rate is even a marginal amount faster than the consumption rate.
> > Furthermore, to prevent one client from disrupting subscription
> > updates sent to another client, each client attaching to an IOC
> > is serviced out of a per-client dedicated event queue connecting
> > the higher priority database processing threads with the lower
> > priority per-client server threads. So to avoid consuming all
> > available memory this event queue is finite length, and if full
> > capacity is reached the last event on the queue for a particular
> > subscription is replaced; this has the net impact of causing an
> > intermediate subscription update to be discarded.
> >
> > So one can easily see, given the above design with intermediate
> > events being discarded when the producer out-paces the consumer,
> > that events will sometimes be delivered out of order when comparing
> > different channel subscriptions, but that events will never be
> > delivered out of order within a single channel subscription.
> >
> > HTH
> >
> > Jeff
> > ______________________________________________________
> > Jeffrey O. Hill           Email        [email protected]
> > LANL MS H820              Voice        505 665 1831
> > Los Alamos NM 87545 USA   FAX          505 665 5107
> >
> > Message content: TSPA
> >
> > With sufficient thrust, pigs fly just fine. However, this is
> > not necessarily a good idea. It is hard to be sure where they
> > are going to land, and it could be dangerous sitting under them
> > as they fly overhead. -- RFC 1925
> >
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:tech-talk-
> > [email protected]]
> > > On Behalf Of Tim Mooney
> > > Sent: Monday, November 01, 2010 3:10 PM
> > > To: EPICS tech-talk
> > > Subject: monitors received out of order
> > >
> > > Dear folks,
> > >
> > > I have two records, and a separate task monitoring a field that both
> > > records
> > > post, all in the same IOC.  Most of the time, my task receives
> monitors
> > in
> > > the
> > > order in which they were posted.  But sometimes, the task receives a
> > > monitor
> > > from record B before it receives a previously posted monitor from
> record
> > > A.
> > > (I know for sure which record is posting first, because record A posts
> > > before
> > > causing record B to process.  Also, I've modified the record to set
> its
> > > time
> > > stamp immediately before posting, and I get another time stamp on
> entry
> > to
> > > the monitor routine.  The time ordering of those stamps does not
> agree.)
> > > I've seen this on solaris and Linux, but not on vxWorks.
> > >
> > > I have code that misbehaves when this happens, so I started digging
> > around
> > > and have convinced myself that I should not be relying on the time
> > > ordering of
> > > monitors received from different records (even when those records are
> > > running
> > > in the same task).  I now think I can rely on posts from a single
> record
> > > arriving in
> > > time order, but not posts from different records.  I think this
> because
> > > events from
> > > different record go into different queues, and there doesn't seem to
> be
> > > any code
> > > in the vicinity that seems worried about time ordering across event
> > > queues.
> > >
> > > Am I right about this?
> > >
> > > --
> > > Tim Mooney ([email protected]) (630)252-5417
> > > Software Services Group, Advanced Photon Source, Argonne National Lab.
> >
> >
> >
> > --
> > This e-mail and any attachments may contain confidential, copyright and
> or
> > privileged material, and are for the use of the intended addressee only.
> > If you are not the intended addressee or an authorised recipient of the
> > addressee please notify us of receipt by returning the e-mail and do not
> > use, copy, retain, distribute or disclose the information in or attached
> > to the e-mail.
> > Any opinions expressed within this e-mail are those of the individual
> and
> > not necessarily of Diamond Light Source Ltd.
> > Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> > attachments are free from viruses and we cannot accept liability for any
> > damage which you may sustain as a result of software viruses which may
> be
> > transmitted in or with the message.
> > Diamond Light Source Limited (company no. 4375679). Registered in
> England
> > and Wales with its registered office at Diamond House, Harwell Science
> and
> > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
> >
> >
> >
> 




References:
monitors received out of order Tim Mooney
RE: monitors received out of order Jeff Hill
RE: monitors received out of order nick.rees
RE: monitors received out of order Jeff Hill

Navigate by Date:
Prev: Re: monitors received out of order Kate Feng
Next: Re: monitors received out of order Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: monitors received out of order Kate Feng
Next: Re: monitors received out of order Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Nov 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·