• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 156 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

66AK2H12: Real-time performance of RT-Linux

UNA
Mastermind 7980 points
Part Number: 66AK2H12

Hi,

I have a question about RT-Linux's real-time performance for 66AK2H12.
When I investigated the delay with the cyclictest tool using RT-Linux (Linux-3.10.72-rt77), I found that the maximum delay was about 10us.


Also, when we investigated the delay in the following environment,
The delay was over 30us.

(1) Measure the delay with the 10kHz MSI interrupt registered in a device driver for testing.
(2) Issue a signal from the MSI interrupt to the test device driver and measure the delay.
(3) Perform Ethernet communication in the background.

Since it is known that the cyclictest causes a delay of up to about 10us,
At the above points, I expect the following delays to occur.

At the time of (1), a delay of about 10 μs occurs.
There is a delay of about 10 μs in notifying the signal from the kernel space to the user space in (2).
The hardware queue interrupt of (3) causes a delay of about 10 μs.


Q1: Is it unavoidable that a delay of about 30 μs occurs when the device driver accepts interrupts and notifies the user application with a signal while Ethernet is running (Linked-up)?
Or can RT-Linux reduce the delay to a few usec?


Q2: Do you know RT-Linux available for Keystone devices, except for Processor SDK RT-Linux provided by TI? Commercial Linux is also fine.

Best Regards,
H.U

  • 0
    TI__Guru 50170 points

    Hi, H.U.,

    From what I understand how cyclictest works, it doesn't add or cause a delay, but measures time interval between the occurance of an event and the time when that event is "handled". You didn't mentioned for your SPI to ethernet test environment is measured with RT-Linux. If not, you should measure it under RT-Linux for the actual latency for RT-Linux. RT-Linux only means the behavior is deterministic. In some cases, I saw RT-Linux performance is worse than Linux when multiple context switch is involved. Process priority also affects its performance.My suggestion is that measure your latency under RT-Linux and see if the latency exceeds the threshold.

    I am not aware of any commercial Linux/RT-Linux for KS2.

    Rex

  • 0 in reply to Rex Chang
    Mastermind 7980 points

    Hi Rex,

    What exactly does [you should measure it under RT-Linux for the actual latency for RT-Linux] mean? If Processor SDK RT-Linux is used, all interrupts will be executed in RT-Linux kernel, isn't it?
    You say the RT-Linux behavior is deterministic, does this mean that the interrupt response time is fixed?


    Best Regards,
    H.U

  • 0 in reply to UNA
    TI__Guru 50170 points

    Hi, H.U,

    From your original post, it seems to me that you were calculating the delay than actually measuring it with cyclictest, and yes, you will need to run it under RT-Linux to measure the actual latency.

    Yes, a deterministic OS (RT-Linux) has predictable behavior vs unpredictable in Linux. The interrupt runs in higher priority than that in Linux. The interrupt in RT-Linux is handled under 15us as RT-Linux is implemented, The word of "fixed" is the statement referring to the interrupt response time is not a right word, but the interrupt inRT-Linux is predictable. In Linux, it is unpredictable and may be preempted by higher priority tasks.

    Thera are quite a few articles in internet explaining RT-Linux. Here is one you can start with:

    https://www.tldp.org/HOWTO/RTLinux-HOWTO-3.html

     

    Rex