6 ms·

CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)

120 points by TN1ck 8y ago

ChuckMcM 8y ago
Something that anyone who writes embedded code should be acutely aware of! Clocks -> threads -> processes -> schedulers -> storage -> interrupts -> networks. An OS curriculum in a nutshell.
- sgillen 8y ago
  Do you have any good/favorite textbooks (or other resources) to learn those from?
jepler 8y ago
If your interest is in waking at a certain time, you should use APIs like `clock_nanosleep(..., TIMER_ABSTIME)` (POSIX.1-2001) which let you say at what time you would prefer to be awakened, instead of APIs which just say for how long you would like to sleep. (looks like the C++ spelling is std::this_thread::sleep_until)
- ianhowson 8y ago
  ... and you'll be woken up at some point after the time you requested, at which point you'll be referred back to the article to find out why.
ananonymoususer 8y ago
"For the purposes of this discussion I’m going to assume a generic version of sleep() that accepts a parameter representing time in milliseconds. The concepts scale up or down with the scale of the parameter." Nice write-up, but no version of sleep() accepts a parameter representing time in milliseconds. Many embedded platforms have no sleep() function. Most recently, I had to implement it (and usleep) on MSP-430.
- oralty 8y ago
  Oh dear, you sound quite confused. https://linux.die.net/man/3/usleep https://linux.die.net/man/3/usleep https://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/n... Which is POSIX, which is supported by a number of OSes, such as QNX, Linux, BSDs, and countless others. https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-sleep https://docs.microsoft.com/en-us/windows/desktop/api/synchap... http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf See page 43 on "Standard Profile" https://www.ee.ryerson.ca/~courses/ee8205/Data-Sheets/Tornado-VxWorks/vxworks/ref/taskLib.html#taskDelay https://www.ee.ryerson.ca/~courses/ee8205/Data-Sheets/Tornad... MSP-430 is not an OS, it is a microcontroller, so your comment makes absolutely no sense. Ironically one of the most popular open source MSP-430 OSes is FreeRTOS.. which of course has vTaskDelay. Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods? Not saying none exist, but, it's probably easier to name the exceptions.
  - com2kid 8y ago
    > Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods? ooh! I worked on one. Cooperative multithreading, you could schedule a task (callback function) to be called in 'n' hundreds of microseconds. There was a scheduler that would drop the entire CPU to a super low power state if no tasks were scheduled to happen anytime soon (and set a HW timer to wake the CPU when more tasks were going to come due), but there was no "user land" API to sleep the entire system. Sleeping the entire system when battery life is important (better to do as much work during each CPU wake cycle as possible, then drop back down to super low sleep for extended periods of time), and when other code needs to run, is rather rude, so we didn't allow it.
    - oralty 8y ago
      Nothing in the generic spec for a "sleep" function specifies you can't drop to a low power state if there is nothing to do. To varying degrees that is how sleep functions work on general purpose OSes. The CPU doesn't just spin for extended periods of time when there is nothing to do (it may spin for short waits). A "schedule a task to be called in 'n' hundreds of microseconds" is effectively a "sleep" function, the use of an explicit callback (PC) vs implicitly saving the PC of the thread is a mere implementation detail.
zepearl 8y ago
Reading the article made me think again about realtime software/hardware/OS, which I absolutely never understood. One one hand Wikipedia says "Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines"." ( https://en.wikipedia.org/wiki/Real-time_computing https://en.wikipedia.org/wiki/Real-time_computing ) On the other hand when I read Wikipedia's article "Real-time operating system" ( https://en.wikipedia.org/wiki/Real-time_operating_system https://en.wikipedia.org/wiki/Real-time_operating_system ) my overall understanding is that there is no feature allowing a program/thread/function to enforce e.g. "I have to be executed within 3 milliseconds" nor that that would anyway be enforced by the OS at any cost (scheduler will prioritize higher-priority tasks). Am I missing something? Or maybe the statement "Real-time programs must guarantee response within specified time constraints" must be taken literally and the program/thread/function must be written in a way that when some timer expires (and a "terminate"-event is sent to it), it will stop doing whatever it's doing (and it will potentially send back some kind of (partial) result)? As you can see, this theme confuses me :) [EDIT: thank you guys! :) ]
- marcosdumay 8y ago
  Real time OSes have an all or nothing response to real time tasks. They either take it to run on the specified time, or they fail with some error. The OSes also take into their hands to enforce that the tasks will finish at the time they asked for. What means that they either terminate by themselves, or the OS will terminate them, again with some explicit error.
  - zepearl 8y ago
    Thx but well, this kind of goes frontally against the other 2 answers I got (I understood that nothing ever gets explicitly terminated by the OS and I felt happy with that approach as it kind of made sense to me, but some now strong doubts are coming back again...).
    - gizmo686 8y ago
      Realtime doesn't mean error free. A realtime OS might provide some form of a watchdog feature where it can detect when a program fails to meet its deadline. Think of it like a segfault in a traditional system. If everyone did their job correctly, it would never come up, but people make mistakes and it is better to detect them and fail in a controlled manner than it is not notice and fail in unpredictable ways.
StillBored 8y ago
I must have missed any mention of tickless schedulers which seem to dominate modern systems because its more efficient both in power costs (allowing the cpu to go into deeper sleeps) and generally for performance/throughput tasks in a system with low CPU contention (because the scheduler never runs).

120 points by TN1ck 8y ago

Something that anyone who writes embedded code should be acutely aware of! Clocks -> threads -> processes -> schedulers -> storage -> interrupts -> networks. An OS curriculum in a nutshell.

sgillen 8y ago
Do you have any good/favorite textbooks (or other resources) to learn those from?

jepler 8y ago

If your interest is in waking at a certain time, you should use APIs like `clock_nanosleep(..., TIMER_ABSTIME)` (POSIX.1-2001) which let you say at what time you would prefer to be awakened, instead of APIs which just say for how long you would like to sleep. (looks like the C++ spelling is std::this_thread::sleep_until)

ianhowson 8y ago
... and you'll be woken up at some point after the time you requested, at which point you'll be referred back to the article to find out why.

ananonymoususer 8y ago

"For the purposes of this discussion I’m going to assume a generic version of sleep() that accepts a parameter representing time in milliseconds. The concepts scale up or down with the scale of the parameter." Nice write-up, but no version of sleep() accepts a parameter representing time in milliseconds. Many embedded platforms have no sleep() function. Most recently, I had to implement it (and usleep) on MSP-430.

oralty 8y ago
Oh dear, you sound quite confused. https://linux.die.net/man/3/usleep https://linux.die.net/man/3/usleep https://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/n... Which is POSIX, which is supported by a number of OSes, such as QNX, Linux, BSDs, and countless others. https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-sleep https://docs.microsoft.com/en-us/windows/desktop/api/synchap... http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.pdf See page 43 on "Standard Profile" https://www.ee.ryerson.ca/~courses/ee8205/Data-Sheets/Tornado-VxWorks/vxworks/ref/taskLib.html#taskDelay https://www.ee.ryerson.ca/~courses/ee8205/Data-Sheets/Tornad... MSP-430 is not an OS, it is a microcontroller, so your comment makes absolutely no sense. Ironically one of the most popular open source MSP-430 OSes is FreeRTOS.. which of course has vTaskDelay. Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods? Not saying none exist, but, it's probably easier to name the exceptions.
- com2kid 8y ago
  > Like name an OS (RTOS or otherwise) that does not have an API to sleep for millisecond periods? ooh! I worked on one. Cooperative multithreading, you could schedule a task (callback function) to be called in 'n' hundreds of microseconds. There was a scheduler that would drop the entire CPU to a super low power state if no tasks were scheduled to happen anytime soon (and set a HW timer to wake the CPU when more tasks were going to come due), but there was no "user land" API to sleep the entire system. Sleeping the entire system when battery life is important (better to do as much work during each CPU wake cycle as possible, then drop back down to super low sleep for extended periods of time), and when other code needs to run, is rather rude, so we didn't allow it.
  - oralty 8y ago
    Nothing in the generic spec for a "sleep" function specifies you can't drop to a low power state if there is nothing to do. To varying degrees that is how sleep functions work on general purpose OSes. The CPU doesn't just spin for extended periods of time when there is nothing to do (it may spin for short waits). A "schedule a task to be called in 'n' hundreds of microseconds" is effectively a "sleep" function, the use of an explicit callback (PC) vs implicitly saving the PC of the thread is a mere implementation detail.

zepearl 8y ago

Reading the article made me think again about realtime software/hardware/OS, which I absolutely never understood. One one hand Wikipedia says "Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines"." ( https://en.wikipedia.org/wiki/Real-time_computing https://en.wikipedia.org/wiki/Real-time_computing ) On the other hand when I read Wikipedia's article "Real-time operating system" ( https://en.wikipedia.org/wiki/Real-time_operating_system https://en.wikipedia.org/wiki/Real-time_operating_system ) my overall understanding is that there is no feature allowing a program/thread/function to enforce e.g. "I have to be executed within 3 milliseconds" nor that that would anyway be enforced by the OS at any cost (scheduler will prioritize higher-priority tasks). Am I missing something? Or maybe the statement "Real-time programs must guarantee response within specified time constraints" must be taken literally and the program/thread/function must be written in a way that when some timer expires (and a "terminate"-event is sent to it), it will stop doing whatever it's doing (and it will potentially send back some kind of (partial) result)? As you can see, this theme confuses me :) [EDIT: thank you guys! :) ]

marcosdumay 8y ago
Real time OSes have an all or nothing response to real time tasks. They either take it to run on the specified time, or they fail with some error. The OSes also take into their hands to enforce that the tasks will finish at the time they asked for. What means that they either terminate by themselves, or the OS will terminate them, again with some explicit error.
- zepearl 8y ago
  Thx but well, this kind of goes frontally against the other 2 answers I got (I understood that nothing ever gets explicitly terminated by the OS and I felt happy with that approach as it kind of made sense to me, but some now strong doubts are coming back again...).
  - gizmo686 8y ago
    Realtime doesn't mean error free. A realtime OS might provide some form of a watchdog feature where it can detect when a program fails to meet its deadline. Think of it like a segfault in a traditional system. If everyone did their job correctly, it would never come up, but people make mistakes and it is better to detect them and fail in a controlled manner than it is not notice and fail in unpredictable ways.

StillBored 8y ago

I must have missed any mention of tickless schedulers which seem to dominate modern systems because its more efficient both in power costs (allowing the cpu to go into deeper sleeps) and generally for performance/throughput tasks in a system with low CPU contention (because the scheduler never runs).