CPU Clocks and Clock Interrupts, and Their Effects on Schedulers (2015) • Hacker News Board

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

#31

Post by shaklee3 » Wed, Feb 13, 2019, 6:35 AM UTC

alfalfasprout wrote: post #15

zepearl wrote: post #14

Earlier quoted context omitted.

Thx >>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. So basically, if I program something and somehow set it to be "realtime" then I can be sure that it won't be suspended before it finishes whatever it is doing? Such a condition cannot be kept indefinitely - soon or later there will be activities that will need the OS' attentio…

This varies. On a multicore CPU it's possible that processes will actually be pinned to a core and those processes will have exclusive access to the CPU core (i.e nothing else will be scheduled on it). Real-time programs tend to avoid syscalls, etc. which cause a context switch so it is indeed possible to run a realtime program indefinitely without the OS stepping in. It's tricky though because even things like dynam…

At least in Linux, there are still os threads that will run on pinned, isolated CPUs. There's work being done to allow only the user thread to run, but last I checked it wasn't complete.

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

#32

Post by loeg » Wed, Feb 13, 2019, 7:27 AM UTC

zepearl wrote: post #7

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 ) On the other hand when I read Wikipedia's article "Real-time operating system" ( https://en.wikipedia.org/wiki…

> nor that that would anyway be enforced by the OS at any cost (scheduler will prioritize higher-priority tasks).

When sorted against ordinary time-sharing program priorities, any real-time task is a higher priority.

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

#33

Post by sgillen » Wed, Feb 13, 2019, 7:48 AM UTC

ChuckMcM wrote: post #2

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.

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

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

#34

Post by mdwrigh2 » Wed, Feb 13, 2019, 10:05 AM UTC

ertjaet wrote: post #30

kllrnohj wrote: post #27

Earlier quoted context omitted.

> The difficulty in doing so is that Android is very much not a realtime system, so trying to run the radio software as, say, a Linux kernel driver would be impossible. Not entirely true. Although Linux is not typically real-time you can achieve this by using SCHED_FIFO or SCHED_DEADLINE for a given process/thread. Android in fact does this for things like audio or display composition.

Setting a Linux process to a "realtime" priority (using SCHED_FIFO, etc.) will put above all non-RT /userspace/ processes. But doing that still means that the kernel can preempt you, if it decides to.

While the kernel theoretically has the ability to preempt you, it's not supposed to when using a realtime priority thread. Per the RH realtime guide[[1]:

""" SCHED_FIFO and SCHED_RR threads will run until one of the following events occurs:

- The thread goes to sleep or begins waiting for an event

- A higher-priority realtime thread becomes ready to run

If one of these events does not occur, the threads will run indefinitely on that processor, and lower-priority threads will not be given a chance to run. This can result in system service threads failing to run, and operations such as memory swapping and filesystem data flushing not occurring as expected. """

SCHED_DEADLINE, which is newer and not mentioned in the guide, can provide a bit stronger guarantees because it can fail if it thinks the requirements you set aren't actually obtainable based on other system load (including high priority kernel tasks that might need to run, etc).

[1]: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

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

#35

Post by pdkl95 » Wed, Feb 13, 2019, 10:20 AM UTC

zepearl wrote: post #7

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 ) On the other hand when I read Wikipedia's article "Real-time operating system" ( https://en.wikipedia.org/wiki…

A practical example I once had to solve:

I was writing the BIOS/flash-loader/debugger code for a Z80 clone[1] we made. The compiler send instruction packets over the RS-232 serial port at 115200 kBd (kbaud). Using 8N1, this is 12800 B/s which means we have a deadline to read the current byte out of the serial port register ever 78us or data will be lost as the new incoming byte on the serial port is written to the port's IO register.

This sounded like a lot of time, until I was informed some of the boards we sold ran at (iirc) 128kHz. After accounting for memory access time and the runtime of relevant instructions, it worked out that we had at most a budget of 60-70 instructions/byte, which wasn't anywhere close to enough to process the byte (including a simple checksum). Even using a normal ISR wasn't possible: the usual register push/pop would have a major portion of our instruction budget. I ended up dedicating a set of registers to receiving the bytes in realtime into as buffer, while processing the data non-realtime using the remaining registers.

Depending on how strict your deadlines are, "realtime" can mean accounting for every clock cycle the CPU is running. An OS (realtime or otherwise) is for people with softer deadlines and CPU time to spare.

[1] https://en.wikipedia.org/wiki/Rabbit_2000

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

#36

Post by marcosdumay » Wed, Feb 13, 2019, 11:05 AM UTC

zepearl wrote: post #18

marcosdumay wrote: post #8

Earlier quoted context omitted.

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.

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...).

Oh, I've read them now. There are some answers about something we used to call "soft real time". Those OSes (Linux was one, for a while, it's not anymore) will have some processes marked as real time, and change the scheduling so that they will execute right at the correct moments. The gotcha is that there can not be many real time processes, since the OS has no way to resolve a conflict between them.

What I described is called "hard real time". It is indeed a very different thing. Both kinds of OSes are in current use, on different niches.

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

#37

Post by ananonymoususer » Thu, Feb 14, 2019, 9:55 PM UTC

oralty wrote: post #6

ananonymoususer wrote: post #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.

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/~course…

I am not confused, but perhaps you did not understand my meaning. There is no version of "sleep()" that accepts an argument in anything other than seconds. Of course Microsoft has "Sleep()" which does, and of course "usleep()" and "nanosleep()" do. Is this unclear?