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  2010  2011  2012  2013  <20142015  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  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: PV Update performance
From: Ralph Lange <[email protected]>
To: EPICS Tech-Talk <[email protected]>
Date: Tue, 11 Nov 2014 13:05:07 +0100
Yet another aspect:

24k Channel Access updates (assuming double with timestamp) at 120Hz will produce a network load that is larger than the physical bandwith provided by one of the 1GB/s network adapters on the 6100. You will have to use bonding or a similar technique (bonding might not be supported on RTEMS), or put a 10GB/s mezzanine board onto your 6100 (as you have to avoid the VME backplane for that sort of load).

~Ralph


On 11/11/2014 10:46, [email protected] wrote:

Slight miscalculation in Nick’s analysis (3ms per update of 470 PVs is 6 us per PV per update), but the essential point remains.  I would guess that 6us for a single PV update including the associated network traffic is pretty reasonable.

 

To update 24,000 pvs at 120Hz is ... demanding.  That’s 350ns per PV per update.  Um.

 

Simply throwing EPICS at this challenge isn’t going to work.  I’d start with an end-to-end analysis of what you’re trying to achieve.  I imagine that these PVs are actually distributed across a network of machines, I think you’ll have to consider where the data is going to go, and how it’s going to be stored.

 

You may want to separate the data capture part of the problem from the control part.  I’m reluctant to say more without more insight into what you’re doing, but it does sound like EPICS isn’t the complete answer!

 

From: [email protected] [mailto:[email protected]]
Sent: 11 November 2014 09:16
To: [email protected]; [email protected]
Subject: RE: PV Update performance

 

Hi,

 

If there is only one core involved, and if you are really updating each PV every cycle, then currently each of your each of PV updates takes about  100 nsec (3msec/60/470), which is only 125 clock cycle times. I suspect you aren’t updating every one – in my experience a record update takes a few microseconds per core, depending on the architecture).

 

They key to this is the essence of your system design. If each of your 24000 PV’s have to be updated at 120 Hz, you can’t possibly do it on a single VME6100. You either have to ensure they only do any processing when they change by a significant amount, or you need more processing power – either via additional CPUs, or maybe a front-end FPGA. You can’t do the impossible.

 

Cheers,

 

Nick Rees

Principal Software Engineer           Phone: +44 (0)1235-778430

Diamond Light Source                  Fax:   +44 (0)1235-446713

 

From: 김영욱 [mailto:[email protected]]
Sent: 11 November 2014 07:15
To: tech-talk
Subject: PV Update performance

 

Hello all,

 

i'm working lately on an EPICS machine, where the number of PVs is 470 at the moment and they need to be updated regularly at 60Hz. The EPICS machine consists of the stuffs as:

 

. VME6100 (Mototorla VME CPU @1.25GHz)

. RTEMS

. EPICS (base-R3-14-12)

 

Currently all these updates for the 470 PVs is taken about 2-3.5 msec; which needs to be improved in a great manner for my 'real' project with about 23,980 PVs, to be updated regularly at 120Hz, after all.

 

Is here anyone who can give me some advice on this 'huge' improvement i need?

 

Best Regards

Young-Wuk KIM

 

 

-- 

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:
PV Update performance 김영욱
RE: PV Update performance nick.rees
RE: PV Update performance michael.abbott

Navigate by Date:
Prev: RE: PV Update performance Dalesio, Leo
Next: RE: Browser based EPICS GUI Dudley, David
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: PV Update performance michael.abbott
Next: RE: PV Update performance Dalesio, Leo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·