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)

#11

Post by com2kid » Wed, Feb 13, 2019, 1:02 AM 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…

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

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

#12

Post by oralty » Wed, Feb 13, 2019, 1:33 AM UTC

com2kid wrote: post #11

oralty wrote: post #6

Earlier quoted context omitted.

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…

> 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 task…

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.

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

#13

Post by StillBored » Wed, Feb 13, 2019, 1:37 AM UTC

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

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

#14

Post by zepearl » Wed, Feb 13, 2019, 1:40 AM UTC

gizmo686 wrote: post #10

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…

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…

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' attention (therefore my program will have to be suspended), no? (If yes then I have problems understanding the threshold...).

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

#15

Post by alfalfasprout » Wed, Feb 13, 2019, 1:53 AM UTC

zepearl wrote: post #14

gizmo686 wrote: post #10

Earlier quoted context omitted.

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…

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 dynamic memory allocation can have non-realtime behavior.

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

#16

Post by zepearl » Wed, Feb 13, 2019, 1:55 AM UTC

adrianratnapala wrote: post #9

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…

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 f…

Thx >>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

Then, for the realtime program to run correctly, it would involve as well an understanding of all other processes/programs that are running at potentially the same time (e.g. "competitors" and "collaborators") and/or with the same or higher priorities, etc.., right?

Therefore, candidate summarized definition:

realtime (HW?/)OSs allow you to execute SW which will run with no interruption, as long as no other SW having the same or higher level of priority interferes?

Does it sound right?

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

#17

Post by com2kid » Wed, Feb 13, 2019, 1:58 AM UTC

oralty wrote: post #12

com2kid wrote: post #11

Earlier quoted context omitted.

> 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 task…

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 u…

It served a similar purpose, if no one else scheduled anything anytime soon.

The schedule task function in this particular embedded OS actually didn't guarantee it'd call you at the specified timeout, the contract was that it'd invoke the callback no sooner than the specified timeout!

Timer coalescing and all that.

Irritated the heck out of the traditional embedded engineers when they first got introduced to it though. "I know this operation will take this many microseconds, can't I just sleep until it is done and the results are waiting for me?"

Not allowed! Plenty of old school engineers are used to just spinning the CPU while waiting for something to happen!

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

#18

Post by zepearl » Wed, Feb 13, 2019, 2:02 AM UTC

marcosdumay wrote: post #8

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…

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

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

#19

Post by FigBug » Wed, Feb 13, 2019, 2:12 AM UTC

zepearl wrote: post #16

adrianratnapala wrote: post #9

Earlier quoted context omitted.

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 f…

Thx >>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 Then, for the realtime program to run correctly, it would involve as well an understanding of all other processes/programs that are running at potentially the same time (e.g. "competitors" and "collaborators") and/or with the same or higher priorities, etc.., right? Therefore, candidate summariz…

Yes, you need to understand all the other processes, but in most cases, there are no other processes. You are writing everything the system is doing. It's up to you to determine what is running in each thread and set it's priority appropriately so that each thread has enough time to run. Real time OSes give you complete control. What you do with that control is up to you based on your needs.

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

#20

Post by zepearl » Wed, Feb 13, 2019, 2:12 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…

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

I guess that context switches would have to happen if e.g. 2 realtime programs, with the same priority etc..., would run concurrently on the same CPU - or would "the running program" (the one that managed to start first) be allowed by the OS(/HW?) to take total ownership of the CPU until it finishes running?