3 ms·

"more preemptive" ok but how does this bound latencies and timing jitter from event to handling? E.g. I need to run a task at exactly every 100us, or within 10

by bfrog 4y ago

"more preemptive" ok but how does this bound latencies and timing jitter from event to handling? E.g. I need to run a task at exactly every 100us, or within 10us of a gpio event, or ... You get the idea. Linux RT is, in my mind, abusing a term to market itself better. There's absolutely zero guarantees of not having your process indefinitely delayed. It's less likely, but zero guarantees and no possibility of doing any sort of worst case determination. That's not "Real Time" that's just better scheduling.

PYTHONDJANGO 4y ago
You need to add some sources to your words so people can take you seriously. If you just write something it does not qualify as "truth" just because it is written by you, you know? They even invented a feature that can be used in every web browser today - it is called "URL" and is used to help you give users a quick method to read the "source of truth" that your words are based on. Just use it and your words will have more power - it is like magic! https://en.wikipedia.org/wiki/URL https://en.wikipedia.org/wiki/URL
- bfrog 4y ago
  https://en.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.wikipedia.org/wiki/Real-time_computing#Criteria_f... https://en.wikipedia.org/wiki/Scheduling_analysis_real-time_systems#Testing_and_verification https://en.wikipedia.org/wiki/Scheduling_analysis_real-time_...
- patrick451 4y ago
  If you don't know the definition of a real time system, look it up. Asking for sources on this is just lazy.
elcritch 4y ago
> "more preemptive" ok but how does this bound latencies and timing jitter from event to handling? Linux RT is basically just the preempt_rt patches. In the normal linux kernel side, many (all?) kthreads can't be interrupted. This prevents the kernel from handling the interrupts from io in a bound time since it has to wait for a kthread to yield. The preempt_rt patches enable preempting kthreads. > E.g. I need to run a task at exactly every 100us, or within 10us of a gpio event, or ... Allowing preempting kthreads enables the kernel scheduler to run more deterministically and not be blocked by kthreads doing things. This allows the kernel to ensure a gpio task gets serviced by a given deadline. There's still spinlocks and critical sections which can block preemption, but they're minimized. Linux rt provides a "execute my thread by a deadline option". > It's less likely, but zero guarantees and no possibility of doing any sort of worst case determination. That's not "Real Time" that's just better scheduling. Hate to tell you, but thats every RTOS. The only one I know of that has a provable bounded scheduler is SeL4. IMHO, thats cool. But FreeRTOS, Zephyr? Nope same thing the Linux preempt_rt patches do. Now its smaller and easier to ensure the system isn't overloaded, less kthreads to review for critical sections, etc.

by bfrog 4y ago

PYTHONDJANGO 4y ago

You need to add some sources to your words so people can take you seriously. If you just write something it does not qualify as "truth" just because it is written by you, you know? They even invented a feature that can be used in every web browser today - it is called "URL" and is used to help you give users a quick method to read the "source of truth" that your words are based on. Just use it and your words will have more power - it is like magic! https://en.wikipedia.org/wiki/URL https://en.wikipedia.org/wiki/URL

bfrog 4y ago
https://en.wikipedia.org/wiki/Real-time_computing#Criteria_for_real-time_computing https://en.wikipedia.org/wiki/Real-time_computing#Criteria_f... https://en.wikipedia.org/wiki/Scheduling_analysis_real-time_systems#Testing_and_verification https://en.wikipedia.org/wiki/Scheduling_analysis_real-time_...
patrick451 4y ago
If you don't know the definition of a real time system, look it up. Asking for sources on this is just lazy.

elcritch 4y ago

> "more preemptive" ok but how does this bound latencies and timing jitter from event to handling? Linux RT is basically just the preempt_rt patches. In the normal linux kernel side, many (all?) kthreads can't be interrupted. This prevents the kernel from handling the interrupts from io in a bound time since it has to wait for a kthread to yield. The preempt_rt patches enable preempting kthreads. > E.g. I need to run a task at exactly every 100us, or within 10us of a gpio event, or ... Allowing preempting kthreads enables the kernel scheduler to run more deterministically and not be blocked by kthreads doing things. This allows the kernel to ensure a gpio task gets serviced by a given deadline. There's still spinlocks and critical sections which can block preemption, but they're minimized. Linux rt provides a "execute my thread by a deadline option". > It's less likely, but zero guarantees and no possibility of doing any sort of worst case determination. That's not "Real Time" that's just better scheduling. Hate to tell you, but thats every RTOS. The only one I know of that has a provable bounded scheduler is SeL4. IMHO, thats cool. But FreeRTOS, Zephyr? Nope same thing the Linux preempt_rt patches do. Now its smaller and easier to ensure the system isn't overloaded, less kthreads to review for critical sections, etc.