Menu
▾
▴
RE: Quality of delivery of subscribe-publisher system using pvaccess
|
From: <jam...@di...> - 2011-11-01 11:18:51
|
Me neither. Paul, if you can point me at the code embedded in GDA I can extract a minimal test case. > -----Original Message----- > From: Marty Kraimer [mailto:mrk...@co...] > Sent: 01 November 2011 10:53 > To: White, Greg > Cc: Gibbons, Paul (DLSLtd,RAL,DIA); epi...@li... > Subject: Re: Quality of delivery of subscribe-publisher system using pvaccess > > On 10/31/2011 11:36 AM, White, Greg wrote: > > Hi, could someone bring us up to date on the status of this thread? Does > Marty have a clarifying example from Paul? > > > > I have not heard anything from Paul. > > Marty > > Cheers > > Greg > > > > On 19 Oct 2011, at 21:23, Marty Kraimer wrote: > > > >> On 10/19/2011 02:08 PM, Dalesio, Leo wrote: > >>> CAV3 and PVAccess operate the same way? > >>> Can waveforms be queued in PVAccess? > >>> > >>> > >>> > >> If the actual data source is a V3 record then the answer may be yes. > >> The problem is that that db_post_event is belongs to caV3. > >> Thus for monitors V3Channel (the pvAccess server for V3 records) must > handle monitors that are given to it by caV3. > >> But when does caV3 call eventCallback? > >> I do not know but will look further when I have a better idea what is > happening. > >> > >> Paul, > >> > >> Let me make what you are doing. > >> > >> I assume that you are using the V3Channel to get data from a V3 waveform > record. > >> That is you started with pvAccessCPP/example/example.zip. > >> > >> Also when you receive MonitorElement it provides an overRun BitSet. > >> Is any bit set? > >> > >> > >> Marty > >>> -----Original Message----- > >>> From: Pau...@di... [mailto:Pau...@di...] > >>> Sent: Wed 10/19/2011 1:53 PM > >>> To: mrk...@co...; epi...@li... > >>> Subject: RE: Quality of delivery of subscribe-publisher system using > pvaccess > >>> > >>> Hi Marty, > >>> > >>> > >>> Quoting your reply for clarity: > >>> "caV3 does have a queue for numeric scalars + timeStamp + status + > severity. > >>> For all other data types, e.g. string and waveForm db_post_event just > notifies the ca server that new data is available. > >>> When the server finally wakes up it gets the latest value from the record. > >>> > >>> If monitors are generated faster than the ca server can accept them they > are lost. > >>> " > >>> > >>> Thanks, this confirms what I am seeing. > >>> It seems to indicate that I cannot use PVAccess for a general > subscribe/publisher implementation for PVData structures. > >>> > >>> > >>> > >>> Paul > >>> ___________________________________________________________ > >>> Paul Gibbons, > pau...@di...<mailto:pau...@di...> Tel: +44 1235 > 778512 Data Acquisition Team Leader, http://www.diamond.ac.uk/ Diamond Light > Source, Chilton, Didcot, Oxon, OX11 0DE, U.K. > >>> > >>> From: Marty Kraimer [mailto:mrk...@co...] > >>> Sent: 19 October 2011 18:16 > >>> To: epi...@li... > >>> Subject: Re: Quality of delivery of subscribe-publisher system using > pvaccess > >>> > >>> On 10/19/2011 01:04 PM, > Pau...@di...<mailto:Pau...@di...> wrote: > >>> Hi Bob, > >>> > >>> I had previously included a buffer for the reason you describe. > >>> > >>> Let me describe the situation in more detail. During a continuous scan a > large number of scan points (order 1000) are to sent from the server to all > listeners in as fast a time as possible (1second). Currently scan points are > buffered both Corba system and then the client. The result is that the memory > usage of the server and client goes up considerable as the queue of messages > builds up, but all messages do get through in sequence. However when the scan > points are sent via a PV in the server, and monitored by the client, I find > that not all points are delivered. Currently the data I send via caput is a > ByteArray with the first byte being incremented by 1 between caputs; the byte > array is being allocated afresh for each caput. On the client I simply report > when the first byte of a sequence of messages is not in itself in sequence. > Most of the time the number is seen to increase by 1 but then it will miss out > 2 or 3. The size of the gap is not seen for small byte arrays (1-10K) sent at > 10ms intervals but is seen with larger sizes (100k). > >>> > >>> For now I just want to understand why the data I read in the monitor event > is not the data sent in the caput method. Is this not expected behaviour when > monitoring a waveform? > >>> > >>> > >>> caV3 does have a queue for numeric scalars + timeStamp + status + > severity. > >>> For all other data types, e.g. string and waveForm db_post_event just > notifies the ca server that new data is available. > >>> When the server finally wakes up it gets the latest value from the record. > >>> > >>> If monitors are generated faster than the ca server can accept them they > are lost. > >>> > >>> Marty > >>> > >>> Apart from this odd behaviour I have successful managed to replace all > Corba notification in GDA with PVAccess/PVData; but so far the data is simply > a serialized Java object which may be of interest to those using Java in the > GDA client but not for anyone else. > >>> > >>> Thanks > >>> > >>> Paul > >>> > >>> ___________________________________________________________ > >>> Paul Gibbons, > pau...@di...<mailto:pau...@di...> Tel: +44 1235 > 778512 Data Acquisition Team Leader, http://www.diamond.ac.uk/ Diamond Light > Source, Chilton, Didcot, Oxon, OX11 0DE, U.K. > >>> > >>> From: Dalesio, Leo [mailto:da...@bn...] > >>> Sent: 19 October 2011 09:41 > >>> To: Gibbons, Paul (DLSLtd,RAL,DIA); epics-pvdata- > de...@li...<mailto:epi...@li...> > >>> Subject: RE: Quality of delivery of subscribe-publisher system using > pvaccess > >>> > >>> > >>> Is there a buffer between the application and the PVClient? > >>> For PVClients that we develop, there is always a cache of data coming back > over the network to disconnect the performance of the application from the > notifications coming back. A table with an update flag is typically put there. > For GUIs, this is a good model. > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Pau...@di...<mailto:Pau...@di...> > [mailto:Pau...@di...] > >>> Sent: Tue 10/18/2011 5:41 AM > >>> To: epi...@li...<mailto:epics-pvdata- > de...@li...> > >>> Subject: Quality of delivery of subscribe-publisher system using pvaccess > >>> > >>> Hi, > >>> > >>> I am trying to replace Corba notification with PVAccess monitors. > >>> The following sequence works fine: > >>> > >>> > >>> 1. Server - create PV > >>> > >>> 2. Client - add monitor to PV > >>> > >>> 3. Server use put to change value of pv > >>> > >>> 4. Client - receives monitor event and extracts new value > >>> > >>> However if step 3 involves many puts to the pv in quick succession the > client does receive every value for the pv - there are gaps. Can anything be > done to improve delivery if the client is slow for a moment. > >>> Thanks > >>> > >>> Paul > >>> > >>> ___________________________________________________________ > >>> Paul Gibbons, > pau...@di...<mailto:pau...@di...><mailto:paul.gibb > on...@di...> Tel: +44 1235 778512 Data Acquisition Team Leader, > http://www.diamond.ac.uk/ Diamond Light Source, Chilton, Didcot, Oxon, OX11 > 0DE, U.K. > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> 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 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> 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 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -------------------------------------------------------------------------- > ---- > >>> > >>> All the data continuously generated in your IT infrastructure contains a > >>> > >>> definitive record of customers, application performance, security > >>> > >>> threats, fraudulent activity and more. Splunk takes this data and makes > >>> > >>> sense of it. Business sense. IT sense. Common sense. > >>> > >>> http://p.sf.net/sfu/splunk-d2d-oct > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> 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 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> --------------------------------------------------------------------------- > --- > >> The demand for IT networking professionals continues to grow, and the > >> demand for specialized networking skills is growing even more rapidly. > >> Take a complimentary Learning@Ciosco Self-Assessment and learn > >> about Cisco certifications, training, and career opportunities. > >> http://p.sf.net/sfu/cisco-dev2dev > > > > > > ------------------------------------------------------------------------------ > RSA® Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 -- 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 |