1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 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 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: devSup driver development differences between base 3.14 and 3.15 |
From: | Abdalla Ahmad via Tech-talk <[email protected]> |
To: | Mark Rivers <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Thu, 30 May 2019 10:19:14 +0000 |
Hello Mark Valgrind reported some invalid read/writes caused by an extra call to “snmp_free_pdu” which then appeared to be added by mistake. I removed it and the valgrind errors output reduced significantly. So I ran the
IOC without valgrind to test its memory consumption, in almost 4 hours memory increased from 0.5% to 21% and that’s on an 8GB RAM PC. I would try base 3.14 to confirm but I’ll need to wait for a shutdown. I’ll get back as soon as I try it. Best Regards, Abdalla. From: Mark Rivers <[email protected]> Hi Abdalla, I don’t recall seeing any problems with the asyn device support when moving from 3.14 to 3.15 or 7.0. So I don’t think there are general issues you need to worry about. The first thing is to diagnose the problem better.
-
When the CPU goes to 100%, run “top” and see what process is using the CPU -
In “top” press “H” and you will see what threads are using the most CPU If there is a memory leak you can run the IOC application using “valgrind”. That is good at telling you where there are definite and probably memory leaks. If you are interested in eventually moving the device support to asyn, here is the page for asynPortDriver.
https://epics.anl.gov/modules/soft/asyn/R4-35/asynPortDriver.html
It contains this link to an introductory talk on writing a driver, starting with a simple version and getting progressively more complex:
https://subversion.xray.aps.anl.gov/synApps/measComp/trunk/documentation/measCompTutorial.pdf
With asyn you typically don’t need to write any device support, because it comes with standard device support for most EPICS records. You only need to write a driver. If you describe your device and device support I may be able to point you to an existing driver that most closely matches what you need to write. Mark From:
[email protected] <[email protected]>
On Behalf Of Abdalla Ahmad via Tech-talk Hi When we had EPICS base 3.14.12.3 and .6 we had a driver developed using EPICS devSup model and it was working fine. Now with EPICS base 3.15.6 the driver is running fine for some period of time until, for unknown reason, the server gets
100% CPU usage. After restarting the server I noticed that (through htop) the IOC’s memory usage is actually increasing although not in a high rate. We noticed the same behavior with another driver we developed. The first one was using a standard socket to
communicate while the second one is using SNMP v1. The devSup structure is defined in the device support as: struct devsup { long number; DEVSUPFUN report; DEVSUPFUN init; DEVSUPFUN init_record; DEVSUPFUN get_ioint_info; DEVSUPFUN io; DEVSUPFUN misc; } aiDevice = { 6, NULL, Init, initRecord, NULL ioRecord, NULL }; And drvet structure is defined in the driver support as: static drvet drvDevice = { 2, NULL, Init }; Here is how everything works in the driver: 1.
The drvet init function initializes communication to the configured devices and fills up array of structures each for a single device. 2.
The devSup init record parses the INP field, gets the device name and uses it to get the device from the previous array storing it in the record’s DPVT. 3.
The devSup io record function reads the DPVT and creates a POSIX thread.
4.
This thread is detached and reads the parsed INP field and calls the corresponding function from the driver support. 5.
All driver support functions communicate with the corresponding device, fetch the value and stores it in the record’s VAL pointer. 6.
After that, dbScanLock is called followed by a call to the record’s RECSUPFUN process function pointer, then dbScanUnlock is called. Right now I am investigating the driver’s code for any possible bugs, but I am sure the problem is that we are doing something wrong which was done right with base 3.14.12.3. Where could be the problem? Let me know if further info Is needed. We are aware of the benefits of asyn-based drivers but we did not have time to do something from scratch. It would be very helpful if there are good material on developing asyn-based drivers. Best Regards, Abdalla Ahmad Control Engineer SESAME Allan, Jordan. Tel: (+962-5) 3511348 , ext. 265 Fax: (+962-5) 3511423 Mob: (+962-7)88183296 |