CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
1–10 of 37 posts
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#2Something that anyone who writes embedded code should be acutely aware of!
Clocks -> threads -> processes -> schedulers -> storage -> interrupts -> networks. An OS curriculum in a nutshell.
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#3If 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)
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#4If 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)
... 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.
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#5"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.
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#6"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.
Oh dear, you sound quite confused.
https://linux.die.net/man/3/usleep 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/synchap...
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/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.
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#7Reading 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 )
On the other hand when I read Wikipedia's article "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! :) ]
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#8Reading 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 ) On the other hand when I read Wikipedia's article "Real-time operating system" ( https://en.wikipedia.org/wiki…
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.
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#9Reading 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 ) On the other hand when I read Wikipedia's article "Real-time operating system" ( https://en.wikipedia.org/wiki…
OSes and applications that get called real-time vary a lot.
But yes, when it is meant rigorously, you can definitely schedule a thing to run on exactly at particular times, preempting whatever lower priority thing was running before.
In my last embedded project that meant we had thing that got called every 64 microseconds -- and it was our job to ensure it finished in time for the next tick and also left enough CPU for all the other threads.
Re: CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015)
#10Reading 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 ) On the other hand when I read Wikipedia's article "Real-time operating system" ( https://en.wikipedia.org/wiki…
Generally real-time systems are realtime at every level. The idea is that you don't have a situation where you need to send a terminate event, because the program would have already terminated.
The point of a realtime OS is not to make your programs run in real-time, but to make it possible for your programs to run in real-time. This is simply not possible on a general OS like Linux, because the kernel can always to do something else while your program is running.
Consider the software that drives the printhead in your printer. The timing here is critical. If a command gets sent too early or too late, the print will not come out right.
You probably don't want the OS to be what tells you to send a command every hundred millisecond. Getting this timing right is a core feature of your application, all you need from the OS is to not get in the way of your getting the timing right.
If you are in a state where you need to send a partial result then the program computing the result is likely not really realtime.