64 bit machines

_jC wrote:

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
.

I hate to be the one to burst your bubble but your general level of satisfaction today is not coming from you using 64 bit as opposed to 32. You've been a victim of a vicious set of circumstances that has falsely lead you to believe that, but it isn't so. Consider for a moment the time when you switched. Back then you were increasing your computing skills enough to take the plunge so to speak. I will also go out on a limb and say that over time you've improved your hardware situation somewhat as well. Those other factors are far more likely to have positively impacted you than what switching to 64 bits has done.

But your mind in order to come up with an explanation dredges up a definite moment, the switch to 64 bits, then attributes everything to it. What you've done is you've fallen into a common logic trap called drawing parallels where none exist. All religion, and much myth and legend was similarly born. So take heart, as what you've done is a pretty common thing for folks to do.

pfred1 wrote:

I hate to be the one to burst your bubble ...Those other factors are far more likely to have positively impacted you than what switching to 64 bits has done.

But your mind in order to come up with an explanation dredges up a definite moment, the switch to 64 bits, then attributes everything to it. What you've done is you've fallen into a common logic trap called drawing parallels where none exist. All religion, and much myth and legend was similarly born. So take heart, as what you've done is a pretty common thing for folks to do.

Thinking back I'm suprised that it is over 10 years ago now that I was lead test engineer on a rather large and thruput critical online transaction processing system. In this capacity I ran regressions of 64bit vs 32bit systems. I can say without hesitation that if a platform supports a mature 64bit implementation it will outpreform and outscale that same platform's 32bit implementation for all testcases except for spinlock().

But I do also undertand linuxCNC's desire to support the minimum covering subset of architectures.

Cheers
.

_jC wrote:

pfred1 wrote:

Thinking back I'm suprised that it is over 10 years ago now that I was lead test engineer on a rather large and thruput critical online transaction processing system. In this capacity I ran regressions of 64bit vs 32bit systems. I can say without hesitation that if a platform supports a mature 64bit implementation it will outpreform and outscale that same platform's 32bit implementation for all testcases except for spinlock().

But I do also undertand linuxCNC's desire to support the minimum covering subset of architectures.

Cheers
.

The next time I find myself running a rather large and throughput critical online transaction processing system I'll try to bear what you say in mind. I mostly use Linux for a desktop OS though. Which while seemingly odd today is what Linux was originally designed by Linus to be.

Many things do not scale in a linear fashion. The example you cite could be one of these cases too. I would be surprised if it wasn't. So making the leap from it performs better in that narrow area to it performs better everywhere is not one I'd be comfortable making. You are obviously much more daring than I am. In point of fact from tests I've seen 64 bit is not outside the margin of statistical error from untuned 32 bit code for standard desktop applications. So while I do not doubt what you say, I do question the conclusions you've drawn. This based on more germane evidence I've seen to the contrary.

Considering the LinuxCNC team, and what they have to work with it isn't much of a stretch to imagine their resources are pressed just doing what they already are. A fine job all the lads are doing too. Andy, and Chris etc. etc. If you're not on the list you should speak up more on IRC

Debian sid x86_64 2.6.38.8 linuxCNC 2.5.1 build notes.

This is as much a record for myself as anyone else. Maybe someone finds it usefull.

Because while its a straight forward process that is also opaque, here is how one goes about building .debs for LinuxCNC on a 64-bit Debian sid platform against the actual current RTAI release, circa August 2012.

RTAI 3.9 is current since 18 July 2012

mail.rtai.org/pipermail/rtai/2012-July/025059.html

---<quote>---
masarati at aero.polimi.it masarati at aero.polimi.it
Wed Jul 18 18:50:21 CEST 2012

Previous message: [Rtai] Ctrl+C blocked in Soft Realtime Process
Next message: [Rtai] RTAI 3.9 released
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear RTAI enthusiasts,

3.9 has been released.

<www.rtai.org/RTAI/rtai-3.9.tar.bz2>

It supports Linux up to 2.6.38.8, with bug fixes and significant
enhancements; see the ChangeLog for details.

Enjoy!

Sincerely, p.
---</quote>---


As the posting says, it supports kernel 2.6.38.8, so download that too.

Compilation of RTAI is straight forward, and documented multiply elsewheres except for a couple of gotchas.

First patch and compile the new kernel with your conservative previous .config settings making sure that CONFIG_SPARSE_IRQ=y isset. Its configuration selection is hiding under
General Setup -->
IRQ subsystem -->
[*] Support sparse irq numbering

Then reboot into your patched RTAI kernel to build the RTAI modules. Just take the Vanilla options to RTAI.

The SMI kernel module will not be built. To fix that see: www.linuxcnc.org/index.php/english/compo...mit=6&start=12#22842

---<quote>---
The problem is that rtai_smi.ko is in the 'i386' target set of the makefiles, which will or course be ignored for either x86 or x86_64 platforms.

The simplest workaround is to build as normal.

Download RTAI-(version) into (for example) /usr/src/rtai-3.9

cd /usr/src/rtai-3.9
make menuconfig ; make ; (sudo) make install

--- then ---

cd /usr/src/rtai-3.9/base/arch/i386/calibration
ln -s Makefile.kbuild Makefile
make; (sudo) make install

bada bing; bada boom; & the missing bits build and install themselves.
---</quote>---


Reboot into the new kernel again before building LinuxCNC.

Then follow this outline.

sixis@sixis:~/Downloads/git$ git clone git://git.linuxcnc.org/git/linuxcnc.git v2.5.1
Cloning into 'v2.5.1'...
remote: Counting objects: 110007, done.
remote: Compressing objects: 100% (24608/24608), done.
remote: Total 110007 (delta 87103), reused 107098 (delta 84458)
Receiving objects: 100% (110007/110007), 58.63 MiB | 235 KiB/s, done.
Resolving deltas: 100% (87103/87103), done.
Checking out files: 100% (3272/3272), done.
sixis@sixis:~/Downloads/git$ cp -rp v2.5.1/ ~/linuxcnc-v2.5.1
sixis@sixis:~/Downloads/git$ cd !$
cd ~/linuxcnc-v2.5.1


In the debian directory of the download the files configure, rules.in, and control.in need some small edits.

debian/configure
================
sixis@sixis:~/linuxcnc-v2.5.1/debian$ diff configure ../../Downloads/git/v2.5.1/debian/configure
60,61c60
< #MODULE_PATH=usr/realtime-$1/modules/linuxcnc
< MODULE_PATH=usr/realtime/modules/linuxcnc
---
> MODULE_PATH=usr/realtime-$1/modules/linuxcnc
63,64c62,63
< #KERNEL_DEPENDS=linux-image-$1,rtai-modules-$1
< #KERNEL_HEADERS=linux-headers-$1
---
> KERNEL_DEPENDS=linux-image-$1,rtai-modules-$1
> KERNEL_HEADERS=linux-headers-$1
111,114d109
< Debian-unstable)
< EXTRA_BUILD=dvipng
< TCLTK_VERSION=8.5
< ;;
166a162,163
> -e "s|@KERNEL_DEPENDS@|$KERNEL_DEPENDS|g" \
> -e "s|@KERNEL_HEADERS@|$KERNEL_HEADERS|g" \
178,179d174
< -e "s|@KERNEL_DEPENDS@|$KERNEL_DEPENDS|g" \
< -e "s|@KERNEL_HEADERS@|$KERNEL_HEADERS|g" \


debian/rules.in
===============
sixis@sixis:~/linuxcnc-v2.5.1/debian$ diff rules.in rules.in-orig
42c42
< cd src && ./configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --with-realtime=/usr/realtime --enable-build-documentation=pdf
---
> cd src && ./configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --with-realtime=/usr/realtime-$(kernel_versio
n) --enable-build-documentation=pdf
56c56
< cd src && ./configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --with-realtime=/usr/realtime
---
> cd src && ./configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --with-realtime=/usr/realtime-$(kernel_version)


debian/control.in
=================
sixis@sixis:~/linuxcnc-v2.5.1/debian$ diff control.in control.in-orig
6c6
< @EXTRA_BUILD@,
---
> @KERNEL_DEPENDS@, @KERNEL_HEADERS@, @EXTRA_BUILD@,




The purpose of the above edits to the remove the dependancy on the pre-built kernel and modules that we have just compilied in the previous steps. And also to adjust the paths to the default vanilla RTAI locations.

There remains an unsatisfied constraint having to do with asciitext, pdflatex, utf8 and document generation.

Even with the remaining dependancies withing the debian/control file and texlive-full installed I was suffering malformed xml-files due to utf8 problems.

---

Master_Getting_Started_es.tex:3794: Package utf8x Error: Character169appearedalone.
Master_Getting_Started_es.tex:3794: leading text: .Arrastré

A possible reason for transformation failure is invalid DocBook
(as reported by xmllint)

Error: pdflatex compilation failed

a2x: ERROR: "dblatex" -t pdf -p "/etc/asciidoc/dblatex/asciidoc-dblatex.xsl" -s "/etc/asciidoc/dblatex/asciidoc-dblatex.sty" -P doc
.publisher.show=0 -P latex.output.revhistory=0 -s ../docs/src/emc2.sty -P latex.hyperparam=colorlinks,linkcolor=blue,filecolor=blue
,urlcolor=blue,citecolor=blue -P latex.encoding=utf8 -V "/home/sixis/linuxcnc-v2.5.1/docs/src/Master_Getting_Started_es.xml" retur
ned non-zero exit status 1
rm: cannot remove `../docs/src/Master_Getting_Started_es.pdf': No such file or directory
make[1]: *** [../docs/src/Master_Getting_Started_es.pdf] Error 1
make[1]: Leaving directory `/home/sixis/linuxcnc-v2.5.1/src'
make: *** [build-stamp] Error 2

---

I found the easiest solution was just to throw the offending input files overboard.

sixis@sixis:~/linuxcnc-v2.5.1$ cat docs/src/empty-doc
empty doc
sixis@sixis:~/linuxcnc-v2.5.1$ find docs -name \*_??.txt -exec cp docs/src/empty-doc '{}' ';'


After that everything builds

sixis@sixis:~/linuxcnc-v2.5.1$ ./debian/configure -r
sixis@sixis:~/linuxcnc-v2.5.1$ fakeroot ./debian/rules binary
...<snip>...
dpkg-gencontrol: warning: package linuxcnc: unused substitution variable ${python:Versions}
dh_md5sums
dh_builddeb
dpkg-deb: building package `linuxcnc-dev' in `../linuxcnc-dev_2.5.0_amd64.deb'.
dpkg-deb: building package `linuxcnc' in `../linuxcnc_2.5.0_amd64.deb'.
dpkg-deb: building package `linuxcnc-doc-en' in `../linuxcnc-doc-en_2.5.0_all.deb'.
dpkg-deb: building package `linuxcnc-doc-fr' in `../linuxcnc-doc-fr_2.5.0_all.deb'.
dpkg-deb: building package `linuxcnc-doc-de' in `../linuxcnc-doc-de_2.5.0_all.deb'.
dpkg-deb: building package `linuxcnc-doc-es' in `../linuxcnc-doc-es_2.5.0_all.deb'.
dpkg-deb: building package `linuxcnc-doc-pl' in `../linuxcnc-doc-pl_2.5.0_all.deb'.
sixis@sixis:~/linuxcnc-v2.5.1$

That's it.

I sure would like to know how to fix the utf8 errors though.

The git maintainers might want to bump the version number in debian/changelog ;^)

Cheers
_jC
.

Change the NLS options in the kernel in order to fix utf8. Personally I'm not interested in supporting the whole world on my personal computer so I change it to iso8859-1 As far as I'm concerned utf8 support is pushed in Linux, and Debian-alike distributions so that they can have what is to me meaningless feature that Windows didn't (doesn't? I don't know I don't do Windows). The rest of the mess is caused by a distribution's locales setting. Supposedly there is a case clash between utf8 and UTF-8 but being as I don't fix it "properly" I can't elaborate on it further. My PC (Personal Computer) doesn't need to be PC (Politically Correct) neither do I for that matter. But that is where you should begin to look in order to fix uft8 stupidness.

$ man locale-gen

for more nonsense about all of this idiocy.

Now it is time to rock some S.O.D. over here



Because if everyone did this then we wouldn't have this problem! Danged foreigners with their crazy chicken scratch text! heh J/K NOT!

64 bit is another thing I don't need but that was a topic for another discussion. 3 of my computers think they're all 64 bit and stuff but I learned them! When the UNIX clock overflows I may have to change my mind on that but until then 32 bits is enough!

BigJohnT wrote:

I asked someone in the know and

changelog on master is the result of merges and is not carefully maintained. there have not been any merges into master since 2.5.1 was tagged. we will never make a release off master so this is not usually a problem

John

Where would someone in the know 'pull' from?

Thx
_jC
.

Are you trying to build from master or from 2.5.x or 2.5.1?

in your message I think i saw both 2.5.0 and 2.5.1 ....

i see you cloned the repo but did you pick a branch?
I am not sure what the default branch is...

not that I help you do what your doing... I've never compiled a kernel

I have in mind to follow the 'Stable' branch as described here:

buildbot.linuxcnc.org/

Which I had thought was 2.5.1. However as I cloned from the v2.5.1 tag, I was surprised to find that debian/changelog was still at 2.5.0, and I'm not familiar enough to know what the repository policies are.

Does that mean that the build bot following 2.5.1 applies a further patch set???

Anyway, my intention is to maintain a private up-to-date release of x86_64 packages for Debian unstable.

That means changing (and understanding) the build automation.

As documented above, its pretty easy to remove the kernel and RTAI dependancies from the LinuxCNC build. (Why are they in there anyway??? It just make the whole thing more fragile and less portable).

Also, in modulariziing the current monolithic build, I would like to break out the Documentation, but it is rather deeply entwined.

I've looked at the makefiles and wiki.linuxcnc.org/cgi-bin/wiki.pl?BeyondWikiToo , but have yet to devise a stand alone documentation builder, that I need to do to understand the utf8 problems that I've been having as documented above.

Ideally I'd like to know how to grab the current stable release sources, and the developement release patchset against them.

Thanks
_jC
.