| 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: Scan rate '.01 second' not achievable |
| From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
| To: | Andrew Johnson <anj at anl.gov>, Ricardo Cardenes <ricardo.cardenes at noirlab.edu>, Érico Nogueira Rolim <erico.rolim at lnls.br> |
| Cc: | "Barrett \(US\), Patrick E" <patrick.e.barrett at boeing.com>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Sun, 8 Jan 2023 19:46:15 -0800 |
On 1/6/23 09:24, Andrew Johnson via Tech-talk wrote:
$ ./modules/libcom/test/O.darwin-aarch64/epicsThreadPerform
...
*The epicsThreadSleepQuantum() call returns 0.010000 sec.** **This doesnt match the quantum estimate of 0.009273 sec within 1%.* It takes 0.011298 micro sec to call epicsThreadGetIdSelf () epicsThreadPrivateGet() takes 0.005903 microsecondsIn EPICS Base-3.15 the path to use is ./src/libCom/test/O.linux-x86_64/epicsThreadPerform but the output is identical. I don't particularly like the "doesn't match the quantum estimate ... within n%" language in the output, but those of you with a statistical background might recognize an attempt to be mathematically correct. Thus on a Mac the value returned by epicsThreadSleepQuantum() is reasonably accurate, while on a fairly recent and fast Linux box the "minimum slumber interval" may be up to about 2 orders of magnitude smaller.
fyi. on my laptop (intel core i5) with a debian stable kernel (CONFIG_NO_HZ_IDLE)
$ ./modules/libcom/test/O.linux-x86_64/epicsThreadPerform ...The epicsThreadSleepQuantum() call returns 0.010000 sec. This doesnt match the quantum estimate of 0.000165 sec within 10%.
epicsThreadSleepQuantum() is indeed off by two orders of magnitude.