Experimental Physics and Industrial Control System
On 1/6/23 06:48, Érico Nogueira Rolim via Tech-talk wrote:
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.
The relevance of _SC_CLK_TCK on Linux these days is as eg. the multiplier for clock_t values
as returned by times() https://man7.org/linux/man-pages/man2/times.2.html
The association with the OS tick timer resolution depends on how the Linux kernel is configured.
These days tick-less (aka NO_HZ) is common. Then _SC_CLK_TCK has no relation to timer resolution.
I can't speak to how this relates to HZ_PERIODIC configurations as might be selected with RTLinux.
So the "Scan rate '%s' is not achievable" warning can be ignored. Almost...
There is a long standing oddity in the timer queue code where quantum/2 is subtracted from all
user provided delays. This can result in a negative number, which is treated as 0 delay.
No one seems to recall why this is done. imo. it is a bug. Unfortunately it has been there
so long that some folks have come to depend on it. eg. on vxWorks it otherwise isn't possible
to delay for only one tick.
https://github.com/epics-base/epics-base/blob/4b63882f283664bbe1ca152d44c5007ab23f55ce/modules/libcom/src/timer/timer.cpp#L68
From my testing, omitting the -quantum()/2 has no ill effects on Linux.
https://github.com/epics-base/epics-base/issues/106#issuecomment-1260232765
Notes:
In Linux kernel configuration, look for the "Timers subsystem" section.
eg. from a Debian 5.10 kernel configuration.
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
# end of Timers subsystem
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
For those wondering, on Linux the value returned for _SC_CLK_TCK actually comes from the
kernel via the magic "auxiliary vector" (cf. "AT_CLKTCK").
http://articles.manugarg.com/aboutelfauxiliaryvectors.html
$ /usr/bin/getconf CLK_TCK
100
$ LD_SHOW_AUXV=1 /bin/true | grep AT_CLKTCK
AT_CLKTCK: 100
- Replies:
- Re: Scan rate '.01 second' not achievable Michael Davidsaver via Tech-talk
- References:
- Scan rate '.01 second' not achievable Barrett (US), Patrick E via Tech-talk
- Re: Scan rate '.01 second' not achievable Érico Nogueira Rolim via Tech-talk
- Navigate by Date:
- Prev:
Re: Scan rate '.01 second' not achievable Hu, Yong via Tech-talk
- Next:
Re: Scan rate '.01 second' not achievable Michael Davidsaver via Tech-talk
- 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
- Navigate by Thread:
- Prev:
Re: Scan rate '.01 second' not achievable Hu, Yong via Tech-talk
- Next:
Re: Scan rate '.01 second' not achievable Michael Davidsaver via Tech-talk
- 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