We are using EPICS 3.15.9.
From: Érico Nogueira Rolim <erico.rolim at lnls.br>
Sent: Friday, January 06, 2023 9:48 AM
To: Barrett (US), Patrick E <patrick.e.barrett at boeing.com>; tech-talk at aps.anl.gov
Subject: [EXTERNAL] Re: Scan rate '.01 second' not achievable
|
EXT email: be mindful of links/attachments.
|
|
On 06/01/2023 11:18, Barrett (US), Patrick E via Tech-talk wrote:
Hello,
We have added a scan rate of “.01 second” to our scan menu to have records processed at 100 Hz (10 ms), but we are getting the “Scan rate is not achievable” message. Is this due to the clock rate not being able to match 10ms? What does
the system set the scan rate to when it receives a message like this? We are running on Linux Oracle 8 OS. I would think a 10ms rate would be achievable.
Thank you,
Patrick Barrett
Stage Controller Software Engineer
The Boeing Company
Hi! Apologies for the double email, Patrick, I had initially responded only to you instead of to the list.
What version of EPICS are you using? I'm looking at EPICS 7, and from what I can see, it uses the following heuristic:
number = ppsl->period / quantum;
if ((ppsl->period < 2 * quantum) ||
(number / floor(number) > 1.1)) {
errlogPrintf("initPeriodic: Scan rate '%s' is not achievable.\n",
choice);
}
where quantum is determined by epicsThreadSleepQuantum().
On Linux, that function uses essentially '1.0 / sysconf ( _SC_CLK_TCK )'. The sysconf value is usually 100 (Hz), and it would explain why EPICS thinks it won't achieve the desired scan rate. I don't think a modern kernel will actually be limited by its tick
rate, so I don't know how accurate that heuristic is.
Either way, the 'period' value isn't touched after this verification, so I think the IOC will still attempt to use it. You could try running a simple counter in your SCAN and checking with camonitor if the 100Hz rate is actually achieved.
I think scanppl() might have trouble detecting overruns with a period of 0.01, though:
if (period > 0.0 &&
(fabs(period - ppsl->period) > 0.05))
continue;
By the way, epicsThreadSleepQuantum() can return 0.0 if the sysconf errors out, which I believe would result in a SIGFPE in initPeriodic() when dividing by quantum.
Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes
de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.
Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before
copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.