Announcement

Collapse
No announcement yet.

Third Version Of Linux Atomic Console Support Posted

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Third Version Of Linux Atomic Console Support Posted

    Phoronix: Third Version Of Linux Atomic Console Support Posted

    Posted on Sunday was the third iteration of the patches working toward the threaded/atomic non-blocking console "NBCON" support that is known to be one of the last blockers to sort out before the remainder of the Linux real-time "RT" patches can be upstreamed...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I really hope it gets merged ASAP so rest of RT patchset can be merged too.

    Please make it happen. It's starting to look like a joke these days, after so many years.

    Comment


    • #3
      It's amazing how much low level improvements the RT project has brought into the kernel. And quite surprising that the "hacked together" nature of console implementation turned out to be the hardest part to get fixed up.

      Comment


      • #4
        Originally posted by timofonic View Post
        I really hope it gets merged ASAP so rest of RT patchset can be merged too.

        Please make it happen. It's starting to look like a joke these days, after so many years.
        Yes I hope it get merged but not ASAP, but only if the code is up to snuff. Since the patch seems to touch other code outside it's domain I hope it's quality and review of code is top notch!

        Comment


        • #5
          Originally posted by Rallos Zek View Post

          Yes I hope it get merged but not ASAP, but only if the code is up to snuff. Since the patch seems to touch other code outside it's domain I hope it's quality and review of code is top notch!
          It's been a while since they tried to merge it, so it's no longer ASAP.

          Comment


          • #6
            Originally posted by timofonic View Post
            I really hope it gets merged ASAP so rest of RT patchset can be merged too.

            Please make it happen. It's starting to look like a joke these days, after so many years.
            It's amazing that basically Linux is the only OS not supporting this in 2024. Even MS-DOS is hard real time. Many ordinary IQ 80 users have high precision CNC lathes and 3d plastic printers at home in their living room. During Covid they also started producing master quality music. Imagine doing picometer precision laser cutting at home and the kernel misses a deadline thanks to blocking VT output. So much for that DIY particle accelerator or fusion reactor.

            Also when you're producing music with 1536 kHz sampling rate and 128-bit floating point DSP, a femtosecond delay in the processing will be stored eternally in the master quality original vinyl. Music fans with 1 MHz sampling rate, 66 bit HiFi DAC setups will immediately notice these shortcomings. Then again, if you have to disable VT and console output to enable RT, your high end DAW might suddenly crash and you'd need console access to live patch the kernel drivers on the fly with a hex editor directly editing the RAM, during your visit to the international space station. But you can't. So sad.

            Comment


            • #7
              And here I thought we were still trying to just "get rid of" the console. well jokes aside, it will be nice to start seeing these patches get merged.

              Comment


              • #8
                Originally posted by caligula View Post

                It's amazing that basically Linux is the only OS not supporting this in 2024. Even MS-DOS is hard real time. Many ordinary IQ 80 users have high precision CNC lathes and 3d plastic printers at home in their living room. During Covid they also started producing master quality music. Imagine doing picometer precision laser cutting at home and the kernel misses a deadline thanks to blocking VT output. So much for that DIY particle accelerator or fusion reactor.

                Also when you're producing music with 1536 kHz sampling rate and 128-bit floating point DSP, a femtosecond delay in the processing will be stored eternally in the master quality original vinyl. Music fans with 1 MHz sampling rate, 66 bit HiFi DAC setups will immediately notice these shortcomings. Then again, if you have to disable VT and console output to enable RT, your high end DAW might suddenly crash and you'd need console access to live patch the kernel drivers on the fly with a hex editor directly editing the RAM, during your visit to the international space station. But you can't. So sad.

                I want some what you're smoking.

                DOS isn't multitasking, there's no way to record 1536kHz sample rate nor do 128-bit floating point, and if there was, it would be downsampled and dithered down anyway, so unless we're talking oversampling DACs which normally operate in the MHz range to do their Nyquist filtering using 1-bit audio, this obviously needs a dedicated device, so what's pushing the audio to it (say, a Linux non-RT system) doesn't matter.

                Nice try though.

                Comment


                • #9
                  Originally posted by flakmirror View Post
                  DOS isn't multitasking
                  RTOS does not imply multitasking. DOS only runs a single task and does it well. You can turn off interrupts if you need real time performance.

                  Comment


                  • #10
                    Linux RT patchset isn't about particle accelerators and femtosecond precision, but about avoiding hearably missing an audio deadline because of some 27ms scheduling latency peak, which is what mainline does today.

                    Comment

                    Working...
                    X