Issue with RTAI on different PC Hardware

Dear RTAI Users,

I have been using RTAI for quite a long time (RTAI 4.0 on Linux 3.8.13 with Debian 7.5) now and it worked perfectly for my research platform.
My application uses RTAI Shared Memory and is built along the interrupt service routine of my self-designed PCI card. Interrupt frequency was working stable at 16 kHz with my Core2Duo E4500 based PC System with 2GB RAM.

Application is High Performance Control and the software is structured in two parts:
- Kernel Module: performs communication with PCI Card and Control Functions as well as providing real time data in a shared memory to a user space application
- User Space Application: Displaying Measurement data and Manipulation of Controller Parameters in a GUI

I switched the PC Hardware to an Intel i3-2120 with 4GB RAM and a Gigabyte Mainboard. My latencies are much higher now. So I'd like to get an idea, if this is a question of the CPU or Mainboard architecture or do I have to change my kernel configuration or switch RTAI version or Linux Kernel as I really got stuck with this issue. Which information do you need for better understanding of this issue as I only changed the PC? Do you need absolute values from latency test or from my application?

My Kernel Options are as follows:
I deactivated sound and USB. I activated the interrupt pipeline and chose a preemptible kernel as well as the high Memory support. I deactivated all ACPI stuff that didn't make my kernel not boot. I also chose Core 2/Newer Xeon processor type and deactivated CPU frequency scaling. How can I generate a detailed list?

My primary objective is to make only minimal changes, as it took quite a long time to get so far and I don't have the resources to work it all over again.

What I tried/thought of so far as a solution:
My application allows me to measure interrupt latency via rt_get_cpu_time_ns(). Usually the value is totally ok, but sometimes it gets really high and forces my system to fail and freeze, like some user space application is blocking the CPU for too long. From my understanding of RTAI this shouldn't be possible as my RTAI task always has the highest priority. So I thought of that ACPI stuff, but deactivating every option in that section was already done. Also my software is really simple and takes only a few microseconds to evaluate. PCI Communication is implemented with DMA support (PCI Card gets master on the PCI bus and performs transactions).
PCI Card uses a non-shared IRQ. I checked that with $lspci and $ cat /proc/interrupts.
Maybe that DMA stuff doesn't work so good. Can this make a difference on two different PCs?

Usually I have a lot of debugging options as I can probe my PCI Card with an oscilloscope and so on. But when the system freezes, I get stuck. So if this option can be helpful, I can provide measurements.

I thank you for your time and consideration in advance.

Best regards from Hamburg, Germany,

Onno Martens


---------------------------
Onno Martens / R&D
fon.: +49 40 514 806 29
www.trinamic.com<http://www.trinamic.com/>

_______________________________________________
Rtai mailing list
[email protected]
https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai