Re: Issue with RTAI on different PC Hardware

Are you working within the X environment, or just using alphanumeric 
consols? Have you checked for possible SMI problems?
Paolo

On 01/10/2017 08:45 AM, Onno Martens wrote:
>
> 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

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