Comments by "Vitaly L" (@vitalyl1327) on "The Lunduke Journal" channel.

  1.  @baumstamp5989  latency = time from an event that must be processed to when a reaction to this even happens. I.e., execution time + all other delays (communication, waiting, etc.). It's latency that matters. Execution time is only a little part of the whole story.
    5
  2. Do not use soft RT for CNC! It is a hard RT problem.
    3
  3.  @joemgj  cost of aarch64 SBCs is insignificant, so why running a hard real-time load on a generic x86?
    2
  4.  @arlobubble3748  because it's getting the job done unreliably - you cannot guarantee a servo or stepper won't overshoot due to a latency spike.
    2
  5. Not with a r/o root fs, not with any updates added only via overlay fs.
    2
  6. no you cannot, guaranteed latencies are given by hard real-time, and PREEMPT_RT is a soft real-time which simply means lower, yet not guaranteed latencies.
    2
  7. "just write an interrupt handler", and then good luck debugging your priority inversion. An event (or interrupt)-driven real-time was never easy. Only bare metal polling real-time is easy to reason about.
    1
  8.  @fnunez  it is extremely hard to formally reason about interrupt handling. The right hard real-time is polling hard real-time. I worked in particle physics experiments, high-frequency trading (where an extra 50us latency spike could cost you millions), in industrial robotics. In all cases polling bare-metal was the most robust solution. Forget about interrupts, they were always a wrong idea.
    1
  9.  @fnunez  of course using an x86 for this kind of real-time processing makes no sense. It's more applicable to MCUs (e.g., ARM Cortex-R series), FPGAs with soft CPU cores running sequential load, or MPSoCs with both hard CPUs and FPGA fabric - the latter is my go to option for hard real-time for this reason exactly.
    1
  10. solution is not to use soft real-time for a hard real-time problem.
    1
  11.  @arlobubble3748  the difference between the soft real-time and hard real-time is that soft does not guarantee any kind of latency. It just tries to sort of keep it low. So, no tolerances can be guaranteed. Only hard real-time can ensure that you're staying within some pre-defined tolerance. Linux on x86 can have timing errors of any scale, PREEMPT_RT or not. One system I was debugging (PREEMPT_RT) had timing spikes of up to 0.5 seconds randomly. Turned out to be related to page faults handling in a process unrelated to the real-time ones (be cautious with `mmap`!). Had timing issues even with Xenomai.
    1
  12.  @arlobubble3748  on an x86 Linux PC with PREEMPT_RT this effective maximum is in *seconds*.
    1
  13.  @joemgj  You may also try NOHZ_FULL on the cores you're running your real-time load on, also a bit less jitter. I'm very cautious about real-time latency spikes because I do direct torque control (robotics, CNC), and even a few ms spike can be catastrophic. If your CNC runs on low speeds and with a position/velocity control, you can tolerate spikes better.
    1
  14. Another one confusing real-time with "fast".
    1
  15. Huh? I'm in the Open Source since the inception of this term, and I doubt I ever heard anything about "diversity" or "inclusion" anywhere on the scene.
    1
  16. How about *not updating*?
    1
  17. ​ @LtdJorge what if I told you that you can get a bare metal hard real-time on an unpatched Linux? Just use a combination of isolcpus and NOHZ_FULL.
    1
  18. The real conspiracy - making everyone believe this insanity got anything to do with anything "leftist". Can you imagine Marx or Lenin ranting about "thin blue line" or any "marginalized groups"?
    1
  19.  @rezah336  not always, there's also memory / system bus contention that can affect latency quite significantly. Not to mentioned shared L3 cache adding hard to calculate worst case memory latencies.
    1