64 bit machines

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:

...I gave up using 64bit OS's on my hardware some years ago...

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:

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.

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

That 2.6.37 build you mentioned, is that with 3.9test?

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.

I run 32 bits because i see no advantage to 64 bit for me. All it does is break some things I like to use. So I could turn it around and ask the same question of you. Why 64 bits?

pfred1 wrote:

Why 64 bits?

1) For amd64 arch the register sets are doubled, plus they are twice as wide, plus there are some auxilliary registers not seen on i586. And the cache lines are twice as wide, so more fits in the on processor instruction/data caches, 'cause the instructions aren't wider.

2) I like to keep my whole tool-chain 64-bits. Its just much faster.

3) 32-bits user space runs on 64-bit machines.

4)Whats apps are holding you back?

5) linuxcnc grip: there's no _amd64 repo so I can't apt-get source, and apt-get build-dep depends on a cooked kernel. Why?

Cheers
_jC
.

_jC wrote:

pfred1 wrote:

Why 64 bits?

1) For amd64 arch the register sets are doubled, plus they are twice as wide, plus there are some auxilliary registers not seen on i586. And the cache lines are twice as wide, so more fits in the on processor instruction/data caches, 'cause the instructions aren't wider.

2) I like to keep my whole tool-chain 64-bits. Its just much faster.

3) 32-bits user space runs on 64-bit machines.

4)Whats apps are holding you back?

5) linuxcnc grip: there's no _amd64 repo so I can't apt-get source, and apt-get build-dep depends on a cooked kernel. Why?

Cheers
_jC
.

My dual core i3 is a virtual 4 core in 32 bit Linux. I ran 64 bit on another machine (a core 2) but when I installed the 32 bit compat libs that system bombed, and I had to completely erase it and reload it. Fair to say 32 bit user space did not work well on it, or even work at all. Some mysterious process called sd(EXEC) just drove the system to its knees. It would have been a tough fix with a system load average of 23 and rising. Holding me back? Back from what? I'm pretty sure your subjectively faster tool chain is all in your head. If you've some verifiable proof I'd love to see it. Then again what you describe could be unique to AMD. I haven't run AMD since my old X2. The way you make it sound I guess I should be happy.

For historical reasons 'amd64' is the name given to x86 64-bit linux.

32-bit userspace is not required whatsoever, my system is 64 top-to-bottom.

But I do run 'draftsight', that pulls in the 32-bit compatibility stuff.

Sadly a 64-bit linuxCNC compliation is non-trivial, you pretty much have to build your own kernel and compile linuxCNC by hand.

My system is running on last May's Debian sid. The uptime was 6 weeks, and the max jitter of the base thread w/isocpu has been < 4500.

I am well satisfied that this is a robust system.

This past week I have taken the system down for integration, but I suppose I could post the kernel's .config if there is interest.

I am also well satisfied that 64 bits is just better, but I made that switch _years_ ago.

_jC
.