Real-Time Kernels in forum distros

[Clarity]

This is a low-priority item: BUT can be considered important.

The Real-Time component of the Linus kernel was designed in the Unix world and embraced in the Linux world when used in laboratories, then LAN-routers, years ago. This also was also used, later, by those in music for all the same benefits that 'real-time' needs; primarily its low-latency behavior requirements for specific applications or subsystems and is used for isolating system resources when specific subsystems or apps is active and in use.

It was NOT designed with a General system in mind; rather it was instituted as a added component for use within a General system.

In recent years, several developers have been creating "Real-time" kernels. And they work.

Over the past months using several forum distros versions that have the Real-time kernels within are present.

BUT, there is one annoying affect that I don't find helpful and is particularly concerning if the problem is due to the real-time kernel.

The EASIEST way to see the problem is when using ROX in 2 separate Windows where a user can drag a set of files for copy to Window #2; then while the copy operation is active try and do anything within either of the active folders while the copy operation is continuing. WHAT YOU'LL NOTICE: Trying to do anything within either will NOT be allowed by the system until AFTER the initial copy operation is over. I found the same with a recent forum which has Thunar instead of ROX.

I have tested this in copy in mainstream distros, MAC, and MS without the same behavior; with them I can return to Window #1 or Window #2 and do operations without needing to wait for the large copy operation to complete.

As this is easily repeated, my question to development:

• Is this a result of the use of the "Real-time" kernel or is it a result of something done in the system time-slicing scheduling built into forum OSes?

Curious to why this behavior exist.

[ozsouth]

@Clarity - Theoretically, real-time (& preempt = low-latency) kernels could hold out a low-priority prcocess for a noticeable time. Is useful for some setups/applications. I prefer Voluntary Preemption, which has regular points at which preemption is available. This has long been the Puppy default & would not cause the issue you describe.

[Clarity]

Thanks @ozsouth

Three's another way to see something similar to the use of filemanagers copying issue, it should also be noted where this is a genuine problem: copy operations to a USB stick.

When the copy operation ON-SCREEN completes, the file-managers show the added files as completely copied to the USB. If one is unaware of this problem, the user pulls the USB not knowing that the system has not completed delivery. This results in either incomplete files OR USB corruption depending on forum distro or USB manufacturer,

Yes, I KNOW to check via a sync command or waiting a long time for completion. But we all make mistakes no matter new/seasoned forum user.

This, I dont think the issue is a file-system issue, rather I'm thinking it is kernel or something in the Linux I/O subsystem giving the file-manager an 'all is complete' signal code. This subsystem feature was called "Lazy-write" in the past. And for USB sticks and SDcards, these slow devices could be significant buffered without a physical write for a rather long period of time.

I am not sure if there is a way to synchronize filesystem managers with I/O subsystem for these slow devices.

Also, I am not sure if this behavior is in any way controlled via kernel parms

[amethyst]

That behaviour of real-time kernels (if it is because of the specific kernel) will be really annoying for me...

[Flash]

As for copying, I've noticed that, when I copy a large file in the standard (non real-time) versions of Puppy I've used, then click on the x to unmount the drive I copied to, the drive does not immediately unmount. This suggests to me that the copy operation is proceeding in the background. Eventually the drive unmounts without me having to do anything more, presumably after the copy operation and all of the associated housekeeping and paperwork have completed.

So I don't know that the behavior you describe for real-time kernels is a bug. Perhaps real-time kernels don't allow backgrounding of some operations.

[wiak]

Two different matters being discussed here though, at least.

One is to do with scheduling of the cpu. A real time kernel by definition will be prioritizing the task it is working on without readily being scheduled to switch to another process. That would explain why you can't do some other operation in either Rox window because the scheduler is keeping the cpu locked on the copy task it is doing.

The second matter you are discussing is not about the cpu per se, but rather about when the copy will be seen as completed from the file manager point of view. That view isn't about writing to the raw device, but rather to buffer/cache in RAM. That copy into RAM is completed well before everything trickles from there out to the raw device. The filemanager, you could say, knows nothing about the raw device. As soon as the whole data is finished moving from source to RAM temp storage, the filemanager is ready to get back to other business, but nothing can be done until scheduler let's cpu back to filremanager processes. That is what I think the situation is anyway.

In Linux, as Flash indicated, you must issue a umount and wait till that completes. Though MSwindows does have a 'safe' eject procedure it doesn't seem to rely on that. Since windows users know nothing about umount I suspect some special event complete signals are involved to give appropriate wait delay prior to copy being indicated as being complete.

[Clarity]

Yes, @Flash that's one characteristics I refer; namely "Lazy Write" I/O subsystem technology. It was intended to give desktop control back to the user as soon as possible while the 'rea' I/O continued work in the shadows. This was developed and used by different OS vendors in the 1990s when icon driven desktops (not terminal consoles...'desktops') began flourishing.

AT THIS TIME
I am retracting this thread! The results are inconsistent as I traverse several forum distros. And, I need further time to help development with enough accurate information for pursuit.

HELP REQUEST
Can a user 'know' if a forum distro is booted, running with a REAL-TIME kernel? This will largely help in my testing these conditions. This would allow me to rule out that kernel feature as the culprit.

[rockedge]

Try in a terminal : uname -a and in the result string will be RT for full real time. Otherwise it can indicate SMP PREEMPT which is voluntary preemption. DYNAMIC means the kernel can have the real time capability modified from the kernel; command line in the boot stanza. So probably a full real time kernel will report SMP PREEMPT DYNAMIC RT or SMP PREEMPT RT.