Welcome to LinuxCNC.org

The latest patchset in rtai-magma is against 2.6.23 and is over four years old.

Is the future to use the -rt series now 'out-of-the-box' on recent kernels?

How does one proceed here. Has anyone benchmarked -rt vs. rtai?

thx
John
.

Hi

Looking at some of the comments on the IRC, it looks like one of the main developers sees no reason to use 64bit systems for Linuxcnc.

To a great extent I can understand that, I gave up using 64bit OS's on my hardware some years ago. I didn't find them any faster, quite the contrary often and development
always lagged behind 32 bit, especially for things like flash-player.
There are few programs which actually exploit the extended registers fully and I don't use anything that requires 64bit.

Regards rtai, there is certainly a contrast in the x86 and x86_64 in magma.
The latest x86 patch is 1 month old and covers 2.6.38, whereas as you say the x86_64 are 4 years old.
Certainly the 2.6.37.6-x86 patch works OK, I built a kernel using it recently.

The next Linuxcnc LTS release will have to use the 3.xx kernel I expect (it is already in 11.10) and I am not sure when magma patches will be available for that.

I am quite familiar with the magma realtime build but not RTLinux.
They seem to have started from the same point and diverged, but I don't know to what extent they are compatible and would be interested to hear if anyone has some relevant knowledge.

regards

ArcEye wrote:
Yeah, the vdso section of the makefile for 2.6.23 was broken against more modern gcc expectation. A lot has changed in MM too, circa 2.6.23 SLUB was introduced.

I can see 64 bit vendor lock-out attempts like Sun's old 'no 64 bit VM for non-sparc', but 32-bits by choice? Why?

Whoa, the make just broke again. Looks like I've got to downgrade binutils, and that'll take the whole compliation toolchain with it.

Wonderful.

ArcEye wrote:
This seems to be an rtai thinko of mine.

The 2.6.32(x86-magma) patch applies cleanly for an amd64 build. The kernel build tree semantics changed around 2.6.23+

So so far so good on the 3.8.1 build. That 2.6.37 build you mentioned, is that with 3.9test?

Rgds

It came from the latest CVS of magma, but yes it is byte length identical to the one in 3.9-test2

Runs perfectly on my quad core Intel test machine (82802JI chips) but can't get it to run on a sandy bridge machine even though 2.6.35 onwards are supposed to.

regards

Well alrighty then, magma cvs amd64 without isocpus

Dell optiplex gx620:
=
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 7
cpu MHz : 2792.882
cache size : 1024 KB
=
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 01)

Latency test has run overnight

---

max int max jitter
Servo thread 1020629 26149
Base Thread 53491 28629

Linux sixis 2.6.35.7-120508a-rtai #3 SMP PREEMPT Tue May 8 20:21:10 CEST 2012 x86_64 GNU/Linux

on Debian unstable, so thats a baseline I guess.

The elapsed time from first attempt to running rtai kernel was ~10 hrs == a pita. I'll give the latency test another go with isocpus, review the kernel logfiles and call it done.

Still, I wonder how this compares against Debian Wheezy Linux-Rt Compile LinuxCNC ?

== update ==

An order of magetude impovement is seen with isocpus

---

max-int max-jitter
Servo thread 997063 2593
Base Thread 27281 2661

And with
May 9 08:16:15 sixis kernel: RTAI: Intel chipset found, enabling SMI workaround.

I can still hear the fan speeding up while compiling.