Does this mean anything to the average user, or is this a very specific use case?
this post was submitted on 19 Sep 2024
0 points (NaN% liked)
Linux
6835 readers
164 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
Probably some use cases for "regular" users. Someone mentioned music production, though that's probably more professional than hobby.
To my understanding, you mostly need real time performance for specialty cases where timing is absolutely critical. So I guess if you were building custom drones or custom control boards for drones, you could use real time Linux for that now since the timing could be guaranteed.
So what about 3D printing? Currently, input shaping uses an accelerometer to calculate resonances and uses that data to adjust movement and reduce flaws in the printing process. For anyone with knowledge of both fields, would this allow a built-in or add-on accelerometer to be used in real time to compensate for momentum and resonances even further?
What’s preventing that from working now? If it’s indeterminate latency, then yeah, absolutely. Theoretically this will give you the ability to have a very deterministic loop around the accelerometer data, but 3d printers don’t move all that fast to begin with so having unbounded latency might not matter. The determinism we’re talking about here is on the order of tens of microseconds or less.
3D printers can move very fast. They typically don't because it causes all kinds of deformations in the print. Mostly the issues are in acceleration, decelaration, cornering, and controlling the heat snd flow of melting filament.
I don't know whether or not the accelerometer thing can be done in real time, or if there would be any benefit.
Check out the 2-minute Benchy for an example of how fast a 3D printer can get. This is a test print that typically should take about 45 minutes to an hour at very basic settings.
But also note the quality of the end product. It looks pretty awful. If we could print accurately at even remotely similar speeds, it would be fantastic.
“Very fast” is relative. 1200mm/s is very fast for 3D printing, no argument. But it’s 1.2mm/millisecond, and we’re talking about time scales in the microsecond range. I suspect you’re going to run into materials issues far before real time performance becomes a limiting factor in print speed and quality.
This is super interesting. I’ll admit I wasn’t even aware of this effort. Even real-time usage of Windows relies on a parallel kernel.
This sounds like it’ll create a lot of cool opportunities and reduce friction.
But the RT patches have been available for 20 years... not sure why the fact that it is mainlined would suddenly expand its popularity? It might be easier to get started sure, but people doing RT were already going to such troubles anyway.
It’s like saying GPS was available for decades before, why would putting it in everyone’s phone expand its popularity.
For myself, I’m hoping the nerds and hackers that otherwise found it not worth the effort will start creating tools to manage real time better and start building them into the applications they write. That way you don’t need to pay an arm and a leg to RedHawk for the privilege of dynamically isolating CPUs or have to reboot the computer to modify kernel arguments a la RedHat MRG.
I don't think that comparison is fair because I explicitly said that people who wanted RT are already going out of their way to get things done. The average desktop user (putting GPS in every phone) won't benefit from it (or RT) and it could likely make their experience even worse.
People who wanted GPS were also already using it by buying TomToms or other GPS devices…
The average desktop user already benefits from the changes the RT folks have slowly been getting into the baseline.
People who want RT are not everyday people though.
How does an average desktop user benefit from any RT changes?
The most obvious answer is gaming. Hard 60/144Hz deadlines is RT. But there are lots of changes that got into the kernel from the RT group, starting with getting rid of the BKL, which helped everyone.