Re: Scan rate '.01 second' not achievable

[Ricardo Cardenes via Tech-talk <tech-talk at aps.anl.gov>]

Hi Érico,

On Fri, Jan 6, 2023 at 11:48 AM Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov> wrote:

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.

sysconf provides information about the system to the user. Last time I checked (but this was many years ago) the tick rate for Linux is configured at the kernel's build time: if sysconf(_SC_CLK_TCK) is returning 100, that means the kernel has been built with a 100 Hz tick rate, and that's about it. Years ago there was the option of building the kernel with higher rates (for more responsive systems), from top of my head I believe the alternative values were 350Hz (maybe 250? can't remember) and 1000Hz, plus an additional "NO_HZ" mode where you build a "tickless kernel" but this is of no use to us, I believe.

Googling a bit I see a "divider" kernel parameter so that a 1000Hz compiled value can be divided a boot time to the one we want to use (eg. divider=10 -> 100Hz), but I'm not sure if this is the case for Barret. At best the kernel might be built with a 1000Hz, with a "divider=10" by default in the boot options, and it would be just a matter of changing that. At worst default kernel is simply built configured to use 100Hz, and then a different pre-compiled one could be used (distros often include one with PREEMPT built in, maybe at 1000Hz), and failing everything else a custom kernel could be built.

Cheers,

Ricardo

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.