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: Question about two minor issues with IOCs |
From: | "Wlodek, Jakub via Tech-talk" <[email protected]> |
To: | Mark Rivers <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Thu, 16 Jan 2020 18:33:18 +0000 |
Hi Mark,
I ran the callbackQueueShow command, and it does seem that the callbacks overflow by a little bit:
epics> callbackQueueShow
PRIORITY HIGH-WATER MARK ITEMS IN Q Q SIZE % USED Q OVERFLOWS
cbLow 2000 0 2000 0.0 64
cbMedium 0 0 2000 0.0 0
cbHigh 0 0 2000 0.0 0
Meaning that the additional plugins are most likely the cause of this error message.
I can add the
callbackSetQueueSize(5000),
and the messages go away. Is there a reason we shouldn't slightly increase the
queue size in base to avoid this? Even around 2500 for example should solve this issue.
Jakub
From: Mark Rivers <[email protected]>
Sent: Thursday, January 16, 2020 1:18 PM To: Wlodek, Jakub <[email protected]> Cc: [email protected] <[email protected]> Subject: RE: Question about two minor issues with IOCs Ø In my case, I see at least a few printings of that error on every IOC boot, Ø though this may be because I have several additional plugins loading Ø PVs at startup, which means that I have more PVs than the example IOCs, however, Ø I had the same amount of plugins loading without this error on earlier releases.
I just typed the callbackQueueShow command on my simDetector IOC. I see the following:\
epics> callbackQueueShow PRIORITY HIGH-WATER MARK ITEMS IN Q Q SIZE % USED Q OVERFLOWS cbLow 1875 0 2000 0.0 0 cbMedium 0 0 2000 0.0 0 cbHigh 0 0 2000 0.0 0
Note that I did not overflow the queue, but it was close, 1875/2000. I started the IOC 4 times and that high-water mark varied from 1580 to 1930. So sometimes it will probably be over 2000.
What do you see?
You can probably eliminate the overflows by adding the following command to your startup script before iocInit()
callbackSetQueueSize(5000)
Mark
From: Wlodek, Jakub <[email protected]>
Hi Mark,
I am currently running the following versions of all modules: ADCore - R3-8 base - R7.0.3.1 asyn - R4-37
I have also seen this buffer full error with ADCore R3-7 IOCs, though I don't remember seeing it on any earlier versions, and I don't remember which base/asyn those were running.
In my case, I see at least a few printings of that error on every IOC boot, though this may be because I have several additional plugins loading PVs at startup, which means that I have more PVs than the example IOCs, however, I had the same amount of plugins loading without this error on earlier releases.
The other error also happens every IOC boot, but that one I haven't seen until recently, although it is possible it simply went unnoticed by me in earlier versions.
Jakub From: Mark Rivers <[email protected]>
Hi Jakub,
I have been seeing both of those messages on my areaDetector IOCs as well.
Ø Error (511,511) PV: 13SIM1::TIMEZONE devStringinEnvVar (init_record) Illegal INP parm field
That message happens every time the IOC boots for me. I have been assuming is a problem with devIocStats, and have been meaning to track it down.
Ø callbackRequest: cbLow ring buffer full
That message only very occasionally happens for me at the end of iocInit. I believe it happens when the number and rate of driver callbacks for PVs are too large, so that the queue in EPICS base overflows. We could probably eliminate them by increasing the size of that queue. But before doing that I want to know why they just started happening, and I did not see them before.
I am running base 7.0.3.1 and the master branch of asyn. The question is whether it was a change in either of those that caused the messages to start happening.
Note that this error can actually be serious, because it means that some records will not have their correct values, because the callback events were missed.
Do you see those cbLow messages every time you boot? What version of base, asyn and ADCore are you using?
Mark
From: Tech-talk <[email protected]>
On Behalf Of Wlodek, Jakub via Tech-talk
Hi all,
I have been working on setting up some new USB cameras at a beamline recently, and I noticed two errors showing up in the IOC shell, though the IOCs for the cameras actually work fine after startup. I wanted to ask if anyone knows why these show up, and how to resolve them. To make sure it wasn't specific to the driver I had written, I compiled ADSimDetector against the same base, asyn etc, and I still saw them showing up:
The first seems to be an issue with autosave, as this shows up right after reboot_restore starts: ---------------------------------------------------------------------------- reboot_restore: entry for file 'auto_settings.sav' reboot_restore: Found filename 'auto_settings.sav' in restoreFileList. *** restoring from './autosave/auto_settings.sav' at initHookState 6 (before record/device init) *** reboot_restore: done with file 'auto_settings.sav'
Error (511,511) PV: 13SIM1::TIMEZONE devStringinEnvVar (init_record) Illegal INP parm field
The second issue happens after the auto_settings.req file is loaded: ------------------------------------------------------------------------------ create_monitor_set("auto_settings.req", 30, "P=13SIM1:") callbackRequest: cbLow ring buffer full callbackRequest: cbLow ring buffer full callbackRequest: cbLow ring buffer full
And is buffer full message is repeated ~30 times.
After all of these messages, I get a message that all the PVs are connected, and the IOC runs with no issues, which is puzzling to me. If anyone could give me some advice on the source and solution to these that would be great.
Regards, Jakub Wlodek |