PREEMPT_RT patch and Arch

b.line · 2009-05-11 05:58:13

Hello All,
I'm wondering if anyone has toyed around with the PREEMPT_RT patch using the Arch concept to simplify the processes to accommodate non-critical motion control across wireless or local area networks as a server for applications such as security cameras, thresholds, landscape automation, environmental controls, etc. There are also several commercial applications that might be reasonably run through the hybrid RT capabilities of a adapted timer and a preempted Linux kernel with an ultra-lean Arch config.
I'm a newbie and interested in finding out what I don't know before I throw a bunch of time at a flawed concept. I've been linux lurking for quite a while hoping to find a really lean operating system and overhead that retains the dual characteristics of general motion control and networking. These could be used in any number of closed loop commutation and synchronization schemes to afford relatively accurate positioning at long distances and communicate the result.
Obviously this could be accomplished with enough money to buy gear and canned (black box) applications but the cost of repetitive installation pales even the bravest entrepreneur. So, the search continues.
Is there any inherent reason that Arch and the RT patched kernel won't work together? Most of the pengutronic stuff I've been reading is a little dated. Admittedly, I may have just outed my lengthy lurk in a spasm of sheer excitement that this may be the one. But I thought I might just simply ask before I work my way to another dead end.
Anyone?

LeoSolaris · 2009-05-11 14:46:29

Let me say up front... personally I have no idea. You could always simply try it and see if it works!

That said, my reason for posting is to say, you might get better traffic on this question in another part of the forum, since this has very little to do with differing architectures. Your best bet might actually be the Networking, Server, and Protection area since your basically talking about setting up a server designed to control security cameras, or the Kernel & Hardware Issues area, since you are asking specifically about a kernel patch.

I got curious and googled the patch you're talking about... I am fairly sure it should work for Arch, since it seems to be very distro agnostic.

I am curious about why you feel the rt patch would help with motion control over a network... it is aimed at working with microsecond timings, than longer term workloads. RT is only really useful (right now) for really short units of work in response to real time events. Basically, if you want to hit a bug's wing that was spotted on a camera with a high powered, very narrow focused laser, then an RT kernel might help you. An RT kernel is aimed at starting up responses really fast. Unless you are responding to something captured by the cameras, and less than a tenth of a millisecond is necessary to that response, a normal "real-fast" kernel might be a better idea.

http://www.rdrop.com/users/paulmck/real … 06.22a.pdf

There is a link to a white paper about the RT-Kernel and the Preempt_RT patch set. It's 9 PDF pages, but if you want to just skim it, the summery has a nice decision tree to help make the choice between real-time patch and the vanilla "real fast" kernel.

The RT-patchset might actually be more work than strictly needed for the concept you're working on.

It seems to me, and I am far from a Guru or an expert, that what you are hunting for is a motion capture application that can easily be network controlled and is open-source. You need a low overhead OS to give all of the system resources to the motion capturing program. Arch is good for low overhead, and there is the package zoneminder in the AUR (Also with the zmviewer-svn that adds a client capacity to the suite, meaning you can look at/control them from another computer).

You may want to look at Linux-From-Scratch to make an absolutely basic system on the hardware you wish to use for this enterprise. You can strip out all of the unneeded drivers from the kernel, locales, manpages, build tools, and all of the other cruft that is needed by the average install of any Linux OS meant to run on diverse groups of hardware.

By the way, the Linux-From-Scratch would allow you to custom compile and thoroughly test each update before sending them out as binaries to your customers, as well as allowing you to do complete upgrades rather than piecemeal updates to each program on the system as they come available. (Business like the set time table for releases because of the lower amount of downtime for the critical systems.)

Last edited by LeoSolaris (2009-05-11 14:49:41)

ugkbunb · 2009-05-11 16:13:34

kernel26-ice has an option to in the PKGBUILD to apply the PREEMPT_RT patch. i am posting right now from a preempted arch install

b.line · 2009-05-11 20:53:05

Thanks for the reply and links Leo.

As I said, I'm a newbie to Linux and I simply made a stab at the forum choice. I'll open a topic in the Kernel and Hardware Issues area since one of the parallel problems is matching the two economically.

I, too, got the impression it was "agnostic"...interesting term...but I thought I'd better check.

In essence, the clock cycles and encoder feedback (closed systems) are pretty important for accurate positioning and synchronizing of "tools" that travel to predetermined points...the error compounds very quickly. The reality of pinpoint positioning and millisecond response times is quite a bit further away at the end of the system than implied by the front end.

Thanks for the link.

Your assessment and description sound right...I didn't know how to say it so well..

I'll take a look at Linux-from-scratch too...thanks. You described what I had in mind from looking at the Arch documentation.

Is the difference simplifying the kernel instead of the shell? May not have said that right either. I'd like to reduce both to the bare necessity.

b.line

b.line · 2009-05-11 21:04:23

Hey ukgbunb!

That's what i was hoping to find!

I don't know about Kernel26-ice but I will soon. I have lots of questions but I need to get up to speed first. is K26-ice considered stable? Or what?

I'd love to know...did you choose to install the patch for a specific purpose or just to rev the motor a little differently. Did you strip it down before compiling?

Would you mind if I dropped you an e-mail when I can speak a little more intelligently on the subject?

It's great to know someone else is trying this with Arch. I think the documentation somehow suggests this kind of potential, as a whole.

Thanks again,
HAB

LeoSolaris · 2009-05-12 16:53:39

Let's see... the differences between Arch and Linux-From-Scratch are actually pretty wide. Arch, while minimalist and simple (compared to other distros like Ubuntu, Red Hat, and Suse) in that it sets you up with basic dev kit (to compile programs) and a package manger. It has most of what the ordinary installs need (both server and desktop) It is pretty lean when you install Arch for the first time. Arch also has a dev team checking the packages and testing things to make sure they work before sending them to the repos.

LFS gives you a thick book and a link to the kernel source straight from www.kernel.org. That's it. It's designed so you can add only the tools that you want to make your own distro.

Both do have a pretty good communities behind them. Neither one has paid support that you can buy if something goes wrong. (Not necessarily a bad thing, depending on your tech level and your needs.)

As for the RT kernel... It may actually work out better for you to have an RT. All I can say is try it out! Time them both and see how they work. You can run more than one kernel. (Not at once, but on the same system! You can make separate entries on the Grub menu to boot the one you choose.)

There is also a package in the AUR that is set up to make you custom compile the kernel source and then installs it properly on Arch. The kernel has a nice ncurses screen that will let you walk though picking what you want. (I think it's ncurses, anyways)

Good luck!

b.line · 2009-05-12 18:04:56

Thanks again leosolaris,

I'm just beginning to train my attention to LFS.

As i appreciate it, there are a number of dependencies that are not necessarily intuitive when the kernel is redacted. This manifests in a variety of ways from inability to compile to a list of errors/bugs/messages. One writer used vivid terms when describing the difference between the 2.4 kernel and the 2.6 kernel at compile. I believe it would be foolish to believe a newbie could re-invent the wheel the Linux community or the Arch dev team has produced...so for me the question is whether the build fits as presented.

What got me going was not only the Arch community's quality effort prior to archiving in the repositories (as you mentioned) but the support focus on the underlying methods/processes. I have to have somewhere to begin if I aspire to tweak the build to my specific purpose. The fact that every Arch user is birthed through the same basic underlying processes nearly assures (in my estimation) a better assimilated fund of knowledge. <RIF>

I'm planning to try it out in the next few days.

Thanks for the ncurses tidbit, that could easily have been missed.

I sincerely appreciate your time and expertise.

ugkbunb · 2009-05-15 04:28:03

b.line wrote:

Hey ukgbunb!
That's what i was hoping to find!
I don't know about Kernel26-ice but I will soon. I have lots of questions but I need to get up to speed first. is K26-ice considered stable? Or what?
I'd love to know...did you choose to install the patch for a specific purpose or just to rev the motor a little differently. Did you strip it down before compiling?
Would you mind if I dropped you an e-mail when I can speak a little more intelligently on the subject?
It's great to know someone else is trying this with Arch. I think the documentation somehow suggests this kind of potential, as a whole.
Thanks again,
HAB

I originally used RT kernel to help solve problem I was having with pulseaudio... since then I have gone back and forth between it and the standard kernel... no real reason to have installed atm. It seemed stable to me... only hang-ups I got was from my nvidia-beta drivers... and the new release and seemed to fix it.

BTW- I am not the maintainer of the kernel26-ice project.... here is the orig thread http://bbs.archlinux.org/viewtopic.php?id=62641

nbvcxz · 2009-05-15 08:14:15

Some information about RT kernel you can find @ http://www.zen-sources.org . In fact some of old RT patch code is now in official kernel (eg. CFQ). In zen-sources you have separate branch with RT kernel, but you need to install it via git: http://www.zen-sources.org/content/gitb … ased-setup

b.line · 2009-05-15 14:56:34

@ugkbunb

I appreciate the followup. I read the "ice" link but did not run down the references...most of it over my head.

Right now I'm suffering from analysis paralysis. This stuff is so interesting and I have the luxury of a little extra time so I'm soaking up the possibilities.

Here pretty quick I'm gonna jump.

Thanx for your input.

b.line

b.line · 2009-05-15 15:02:51

@nbvcxz

Thanks for the leads...the hits keep rolling in.

I'm apparently looking for a hybrid and may end up having to compile it myself with a homemade patch or two.

All links investigated and appreciated.

Keep 'em coming

Thanks to all.

b.line

Arch Linux

#1 2009-05-11 05:58:13

PREEMPT_RT patch and Arch

#2 2009-05-11 14:46:29

Re: PREEMPT_RT patch and Arch

#3 2009-05-11 16:13:34

Re: PREEMPT_RT patch and Arch

#4 2009-05-11 20:53:05

Re: PREEMPT_RT patch and Arch

#5 2009-05-11 21:04:23

Re: PREEMPT_RT patch and Arch

#6 2009-05-12 16:53:39

Re: PREEMPT_RT patch and Arch

#7 2009-05-12 18:04:56

Re: PREEMPT_RT patch and Arch

#8 2009-05-15 04:28:03

Re: PREEMPT_RT patch and Arch

#9 2009-05-15 08:14:15

Re: PREEMPT_RT patch and Arch

#10 2009-05-15 14:56:34

Re: PREEMPT_RT patch and Arch

#11 2009-05-15 15:02:51

Re: PREEMPT_RT patch and Arch

Board footer