Compiling Mysql

[andnat]

Hy,

it is possible to have the missing components for compiling mysql?

Someone in the forum has already tried to install mysql server on the cRIO 9068?

Do you think there are alternate database that you can use already tested with cRIO9068?

[andnat]

Dear All,

we need to install MySQL Server Engine on cRIO-9068 in order to collect data from a plant. We want to work with MySQL because our LV source code is already written for work with it, in other words we want to change hardware non-NI platform in order to use NI-Platform (cRIO-9068). Our problem is that we need the missing component for compiling MySQL source code and would be great if someone NI-Developer could help us to understand if will be possibile to do this. After that, we want try to install into cRIO-9068 also PHP and Apache.

Our database will not be very large, anyway is it possible to expand the flash disk of cRIO?

Thanks in advance,

Andrea

[Sanjay_C.]

Hi Andrea,

Yes, it should be possible to install MySQL to the cRIO 9068 -- in a related effort, I have successfully put together a demo in which I installed PostgreSQL to the cRIO 9068 and logged data from LabVIEW to the Postgres DB.

Yes, it is also possible to install PHP and Apache. We may have to deal with the fact that Apache and the web server we already have on the cRIO will compete for port 80, but we can get to that subsequently.

You can use USB or network storage to expand the disk space that the cRIO has access to -- I don't belive there is a way to increase the size of the onboard flash itself.

Regarding the installation of MySQL, PHP, and Apache, I recommend that you first try downloading from the Angstrom repository (as you can likely avoid having to build these packages manaully as the binaries on the Angstrom repository have for the most part been compatible on the cRIO 9068). I believe that on the cRIO you have, you'll need to first uncomment the feeds to the repositories. To do this, you'll want to go to /etc/opkg/ -- there you will find four *.conf files. You'll want to edit each of these .conf files to uncomment out the feeds that we commented out (it's so that nobody accidentally downloads any packages -- we want users to be explicit about exploring with Linux RT. Feel free to experiment with packages/code/applications in the Linux ecosystem, but realize that we can't provide much support). Each of the *.conf files has text to explain how to uncomment etc.

Once you have the feeds properly uncommented, run "opkg update" to refresh the list of packages. Then you should be able to search and install MySQL, PHP, and Apache with opkg.

[Captain_Kirby]

Sanjay is correct that there is no way to change or expand the built-in storage. The cRIO-9068 has a total 1GB of onboard storage. You could exapnd this in many ways, mostly through the USB port (flash drive, attached USB, HD, SD card reader, etc.) But you could implement network attached storage by mounting a network drive as well. You would need to use the opkg to install SAMBA support for a network attached windows drive, or use NFS for a more Linux friendly and much more easily mountable networked attached storage solution (NFS support should be built-in as it is the native Linux method.)

[jarcTek]

Hi Sanjay,

Did you run into issues with postgreSQL and the max_stack_depth? I am getting an error that max_stack_depth cannot be set.

Which version of postgreSQL did you install?

Thanks!

[Sanjay_C.]

Hey jarcTek,

Yes, there is a limit on stack sizes to preserve real-time performance. I got around that particular issue by running the following command as the root/admin user: "ulimit -s unlimited". Note that I'm not sure what the consequence is for real-time performance; I can double check with developers to confirm that this is the best approach (and to also get insight into what may go wrong when you set the stack size to unlimited).

[jarcTek]

I was asking myself the same question about the real-time performance. If you could double check with the developers that would be great.

Did you consider SQLite at some point?

[Sanjay_C.]

Hi jarcTek,

I had a chance to hear back from the developers. Here were my questions to R&D with R&D responses inline:

What's the best way to address stack size for an application on Linux RT?

A: If the application is a LV RT app, it's simply changing the wrapper around where we launch lvrt (a script, can be edited through the console or webdav'd over, edited, and webdav'd back (being careful to maintain EOL correctness). If we are talking about a separate application, instead of the wrapper you would need to either wrap the application to raise the stack limit and then launch or edit the profile.d script that lowers the stack use at any shell login (including all binaries launched from the shell). In other words, it depends on where the application is.

With regards to this example, it depends on how the db is being accessed. If it is through a system exec VI launching an external binary, you could wrap the call to the binary in a script that adjusts the stack size for this particular spawned process. If the db is being accessed through a library invoked from a Call Library Node, things get trickier, requiring spawning a thread with pthread_attr_setstacksize() called to make the adjustment.

What is the stack size limit set to on NI Linux Real-Time?

A: 256 kB

What are the repercussions to running "ulimit -s unlimited" as root/admin (on determinism/jitter/performance)?

A: The issue is that running ulimit only affects processes launched from the shell that ulimit is run from. If you increase the stack size, each thread (8 total for the lvrt process) has an mlock'd stack that is prefaulted (and therefore the pages that back the stacks are stuck to the lvrt process forever) will have that much memory use that is indelibly tied to the lvrt process (we use mlockall to prevent pagefaults due to stack use through deep call stacks from affecting determinism). I'm really not sure what would happen if you tried to ulimit -s unlimited, but my guess would be that it would default to the 8M stack size pre-faulted (so 8x8 = 64 megs of just stack for the lvrt process) plus you would have the issue that, when you exceed stack size, it would cause a pagefault, impacting determinism in the range of 100's of microseconds. This assumes that it would let you do that at all with an mlockall'd process.

If the stack is adjusted for a separate process, there is no impact at all other than increased system use (depending on number of threads in that process, this can be an issue). If it is within the lvrt process, you would want to ensure that you are not spawning the thread while time critical code is executing, but once the thread is created, the thread's stack is prefaulted-in, so at that point you are only subject to the increased memory use.

[Australia_]

Hi,

Could anyone confirm that the NI 9068 supports NFS method officially ?

I do get the message that since this is a native Linux method and therefore it should.

Any information or help would be truly appreciated.

[tduffy]

@Australia_,

The mount command that ships with the cRIO-9068 appears to be 'full flavored' supporting the wide variety of different mounting methods that desktop linux users are familior with ( the mount command is just simlinked to busybox ).

mount -t nfs <server_ip>:/<remote_mount_point> <local_mount_point>

Where,

    <server_ip> is the IP address of the NFS server (ex. 10.1.0.100)

    <remote_mount_point> is the mount point on the server (ex. /share/tduffy)

    <local_mount_point> is the local folder you want to mount the remote share to (ex. /mnt/nfs/tduffy)

An example would be:

> cd /mnt

> mkdir nfs

> cd nfs

> mkdir tduffy

> mount -t nfs 10.1.0.100:/share/tduffy /mnt/nfs

> cd tduffy

> ls

Hope that helps!

-TD