Multi-system real-time system performance evaluation method based on rk3568

Abstract

The invention relates to a multi-system real-time system performance evaluation method based on rk3568, multiple systems comprise an RTOS, a Linux and an NPU, the evaluation method calculates task execution delay through the RTOS and transmits the task execution delay to the Linux, evaluates real-time performance by using a cyclictest tool of the Linux, calculates a prediction model through the NPU to obtain a real-time optimization strategy of dynamic balance, and returns a result to the RTOS. And the task priority is guided to be adjusted. According to the method, a closed-loop process from real-time evaluation to dynamic adjustment is realized, the whole process of task execution delay acquisition, real-time performance calculation, optimization strategy prediction and return application is covered, and the timeliness and effectiveness of real-time performance dynamic optimization are ensured.

Description

Technical Field

[0001] The invention relates to the technical field of real-time system performance evaluation methods, and in particular to a multi-system real-time system performance evaluation method based on rk3568. Background Art

[0002] In areas such as high-performance computing and communication networks that require extremely high system real-time performance, especially in the industrial control industry, where system latency is extremely high, fluctuations in system latency may lead to serious performance degradation and even cause security risks. Therefore, it is crucial to accurately evaluate and optimize the real-time performance of the system.

[0003] Real-time operating systems (RTOS) have been widely used in industrial control, embedded systems and other fields. Their core task is to ensure that key tasks in the system are completed within strict time constraints. However, with the increase in system complexity and task types, how to dynamically adjust task priorities to balance real-time requirements and system resource utilization has become an important issue.

[0004] Existing real-time evaluation methods are usually limited to static analysis and are difficult to cope with dynamically changing system loads. On the other hand, the development of prediction models and artificial intelligence technology has provided new ideas for real-time optimization, especially through hardware accelerators (such as neural network processing units, NPUs), which can achieve rapid prediction and dynamic adjustment of real-time strategies. Summary of the invention

[0005] The purpose of the present invention is to provide a multi-system real-time system performance evaluation method based on rk3568 to solve the problems raised in the above background technology.

[0006] To achieve the above object, the present invention provides the following technical solution: a multi-system real-time system performance evaluation method based on rk3568, wherein the multi-system includes RTOS, Linux and NPU, and the real-time system performance evaluation method comprises the following steps:

[0007] Step 1: Task delay acquisition: In RTOS, during the execution of real-time tasks, the system records the key time points of the tasks, calculates the task delay, and stores the records in the data buffer;

[0008] Step 2: Data transfer to Linux: RTOS transfers the collected delay data to the system running Linux in real time through shared memory;

[0009] Step 3: Real-time performance calculation: After receiving the delay data, the Linux system uses the cyclictest tool to evaluate the real-time performance of the data, calculate key performance indicators, and generate a detailed real-time performance report based on task priority and runtime environment;

[0010] Step 4: NPU prediction model calculation: Input the real-time performance report into the pre-trained prediction model and use the high-performance computing capabilities of the NPU to quickly calculate the optimization strategy;

[0011] Step 5: Optimization strategy is sent back to RTOS: Linux sends the generated optimization strategy back to RTOS through the high-speed communication interface; RTOS adjusts the priority, scheduling strategy or resource allocation of tasks according to the received optimization strategy to dynamically adapt to the real-time requirements of the system;

[0012] Step 6: Loop dynamic optimization: The system repeats the above steps in a periodic manner to form a closed-loop optimization process, which continuously improves the real-time performance of the system under a dynamically changing load environment.

[0013] Preferably, the mission critical time points in step 1 include:

[0014] The time when the task enters the ready queue: records the time point T_ready when the task changes from the blocked state or the dormant state to the ready state;

[0015] The time when the task starts executing: records the time point T_start when the task is scheduled by the kernel to run on the CPU;

[0016] The time when the task is completed or the CPU is released actively: T_end;

[0017] Preferably, the step 1 also includes a delay calculation method for calculating task delay, and the delay calculation method includes the following sub-steps:

[0018] Sub-step 11: Calculate the scheduling delay:

[0019] Scheduling delay = Tstart - Tready\text{Scheduling delay} = T_{start} - T_{ready}Scheduling delay = Tstart - Tready;

[0020] Sub-step 12: Calculate the actual execution time:

[0021] Actual execution time = Tend - Tstart\text{Actual execution time} = T_{end} - T_{start}Actual execution time = Tend - Tstart;

[0022] Sub-step 13: Calculate execution time deviation: Assuming that the expected execution time of the task is TexpectedT_{expected}Texpected, then: Execution time deviation = Texpected-actual execution time\text{Execution time deviation} = T_{expected}-\text{actual execution time}Execution time deviation = Texpected-actual execution time.

[0023] Preferably, in step 2, the data transferred between the RTOS and Linux systems includes task ID, priority, T_ready, T_start, T_end, scheduling delay, actual execution time, and execution time deviation.

[0024] Preferably, a linear regression prediction model is used.

[0025] Preferably, the method further comprises a cyclictest evaluation method for evaluating the real-time performance of data using a cyclictest tool, wherein the cyclictest evaluation method comprises the following sub-steps:

[0026] Sub-step 31: Initialize shared memory, RTOS and Linux communicate through shared memory;

[0027] Sub-step 32: In the main program of cyclictest, replace the jitter calculation logic;

[0028] Sub-step 33: collecting jitter data of the task;

[0029] Sub-step 34: Output the jitter statistics result of the task.

[0030] Compared with the prior art, the present invention has the following beneficial effects:

[0031] The present invention calculates the task execution delay through RTOS and passes it to Linux, uses Linux's cyclictest tool to evaluate the real-time performance, and then calculates the prediction model through NPU to obtain a dynamically balanced real-time optimization strategy, and returns the result to RTOS to guide it to adjust the task priority, thereby realizing a closed-loop process from real-time evaluation to dynamic adjustment, covering the entire process of task execution delay collection, real-time performance calculation, optimization strategy prediction and feedback application, ensuring the timeliness and effectiveness of dynamic optimization of real-time performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 A multi-system block diagram provided for the present invention;

[0033] Figure 2 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0034] In order to make the purpose and technical solution of the present invention clearly and completely described, and the advantages more clearly understood, the embodiments of the present invention are further described in detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are part of the embodiments of the present invention, rather than all of the embodiments, and are only used to explain the embodiments of the present invention, and are not used to limit the embodiments of the present invention. All other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0035] See also Figure 1 to Figure 2 :Take the following task as an example, and describe the evaluation of the multi-system real-time system performance evaluation method based on rk3568: The task involves:

[0036] Task A (high priority): collects sensor data, with an expected execution time of 1ms;

[0037] Task B (medium priority): performs robot motion control, with an expected execution time of 5ms;

[0038] Task C (low priority): records system logs, with an expected execution time of 10ms;

[0039] The real-time performance of the tasks is crucial, especially the sensor data collection of Task A. If the delay is too high, the system control may fail.

[0040] The real-time system performance evaluation of the above tasks includes the following steps:

[0041] Step 1: Task delay acquisition (RTOS part)

[0042] When task A is in progress, the system records the following time points:

[0043] The time when a task enters the ready queue (T_ready): For example, task A changes from the blocked state to the ready state at 0.001s after the system is started.

[0044] Task start time (T_start): Task A is scheduled to run on the CPU with a time of 0.002s.

[0045] Time when task execution ends (T_end): Task A completes execution in 0.003s.

[0046] Calculate the delay data:

[0047] Scheduling delay = T_start - T_ready = 0.002s - 0.001s = 1ms;

[0048] Actual execution time = T_end-T_start = 0.003s-0.002s = 1ms;

[0049] Execution time deviation = T_expected - actual execution time = 1ms - 1ms = 0ms;

[0050] Recording and transmission:

[0051] The RTOS stores the following data of Task A into the buffer:

[0052]

[0053] When the buffer is full or the scheduling cycle is completed, the RTOS transfers the data to the Linux system through shared memory.

[0054] Step 2: Data is transferred to Linux;

[0055] Transport Protocol:

[0056] Data transfer is achieved through shared memory to ensure minimal latency. The format of the transmitted data is:

[0057] Task ID Priority T_ready T_start T_end Scheduling Delay Actual execution time Execution time deviation

[0058] Step 3: Real-time performance calculation (Linux part)

[0059] Cyclictest analysis:

[0060] After Linux receives the RTOS data, it uses the cyclictest tool to evaluate the overall real-time performance of the system, and Linux generates a detailed report;

[0061] Task A:

[0062] Maximum jitter: max_jitter = 3ms;

[0063] Minimum jitter: min_jitter = 1ms;

[0064] Total jitter value: total_jitter = 2ms + 3ms + 1ms = 6ms;

[0065] Count times: count = 3;

[0066] Average jitter: average_jitter = total_jitter / count = 6ms / 3

[0067] =2ms;

[0068] Task B:

[0069] Maximum jitter: max_jitter = 5ms;

[0070] Minimum jitter: min_jitter = 2ms;

[0071] Total jitter value: total_jitter = 4ms + 2ms + 5ms = 11ms;

[0072] Count times: count = 3;

[0073] Average jitter: average_jitter = total_jitter / count = 11ms / 3≈3.67ms;

[0074] Task statistics results: Task A: - Maximum jitter: 3ms - Minimum jitter: 1ms - Average jitter: 2ms Task B: - Maximum jitter: 5ms - Minimum jitter: 2ms - Average jitter: 3.67ms The specific analysis method of the above cyclictest analysis is as follows:

[0075] 1. Initialize shared memory:

[0076] RTOS and Linux communicate via shared memory.

[0077] Use shared memory mapping on the Linux side to load the jitter delay data recorded by RTOS into the memory space of cyclictest.

[0078] RTOS Operation:

[0079] Define a shared memory area to store the real-time jitter delay value of each task.

[0080] The jitter delay value of each task occupies a fixed memory address range and is distinguished by task ID.

[0081] Linux operation:

[0082] In the main program of cyclictest, access the RTOS data through shared memory and read the jitter delay of the task.

[0083] Replace the jitter calculation logic:

[0084] In the main program of cyclictest, replace the original delay difference calculation logic,

[0085] Original logic:

[0086] Calculate the scheduling jitter of a thread using the current timestamp and the previous timestamp.

[0087] The formula is: diff = calcdiff_ns (now, prev);

[0088] New logic:

[0089] Read the actual jitter delay returned by RTOS from shared memory instead of diff.

[0090] Use the task ID to map to a specific address in the shared memory.

[0091] The new formula is: diff = shared_memory[task_id];

[0092] 3. Statistical task jitter data:

[0093] Maintain jitter statistics for each task, including maximum jitter, minimum jitter, total jitter, and jitter count.

[0094] Statistics content:

[0095] Maximum jitter: record the maximum value of each jitter value;

[0096] Minimum jitter: record the minimum value of each jitter value;

[0097] Average Jitter: The average value is calculated by summing up the accumulated jitter values.

[0098] 4. Output the jitter statistics of the task:

[0099] At the end of the program, the statistical results are output by task.

[0100] Output:

[0101] Task ID

[0102] Maximum jitter

[0103] Minimum jitter

[0104] Average jitter

[0105] Calculation formula:

[0106] Average jitter = total jitter value / statistical times;

[0107] When the number of statistics is zero, the average jitter is set to zero.

[0108] 5. Example logic description

[0109] Task data structure:

[0110] The data structure of each task stores the following information:

[0111] Maximum jitter: max_jitter

[0112] Minimum jitter: min_jitter

[0113] Total accumulated jitter value: total_jitter

[0114] Statistic count: count.

[0115] Step 4: NPU prediction model calculation:

[0116] Input data:

[0117] The performance report is fed into a trained linear regression model. The prediction model considers the following features:

[0118] Scheduling delays, execution time deviations, task priorities, system load, task queue lengths, etc.

[0119] Model output:

[0120] The predictive model generates optimization strategies by analyzing conflicts and delay trends between tasks, such as:

[0121] The priority of Task A is increased, and the scheduling resources are increased by 20%;

[0122] Task B maintains the status quo;

[0123] Task C is downgraded in scheduling priority and its resource allocation is reduced by 10%.

[0124] Step 5: Optimization strategy is sent back to RTOS:

[0125] Linux passes optimization strategies back to RTOS:

[0126] Task A: The priority is adjusted to the highest;

[0127] Task B: Maintaining priorities;

[0128] Task C: Reduce priority by 10%.

[0129] The RTOS adjusts the task schedule according to the strategy and applies the new strategy in the next cycle.

[0130] Step 6: Loop to perform dynamic optimization:

[0131] The system repeats the above steps continuously to adapt to environmental changes in real time. For example:

[0132] When the scheduling delay of task A increases, the priority adjustment will take effect in the next cycle, thereby reducing the delay. As the system load changes, the model will dynamically adjust the execution resources of low-priority tasks to ensure the real-time performance of high-priority tasks.

[0133] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A multi-system real-time system performance evaluation method based on rk3568, wherein the multi-system includes RTOS, Linux and NPU, characterized in that: The real-time system performance evaluation method comprises the following steps: Step 1: Task delay acquisition: In RTOS, during the execution of real-time tasks, the system records the key time points of the tasks, calculates the task delay, and stores the records in the data buffer; Step 2: Data transfer to Linux: RTOS transfers the collected delay data to the system running Linux in real time through shared memory; Step 3: Real-time performance calculation: After receiving the delay data, the Linux system uses the cyclictest tool to evaluate the real-time performance of the data, calculate key performance indicators, and generate a detailed real-time performance report based on task priority and runtime environment; Step 4: NPU prediction model calculation: Input the real-time performance report into the pre-trained prediction model and use the high-performance computing capabilities of the NPU to quickly calculate the optimization strategy; Step 5: Optimization strategy is sent back to RTOS: Linux sends the generated optimization strategy back to RTOS through the high-speed communication interface; RTOS adjusts the priority, scheduling strategy or resource allocation of tasks according to the received optimization strategy to dynamically adapt to the real-time requirements of the system; Step 6: Loop dynamic optimization: The system repeats the above steps in a periodic manner to form a closed-loop optimization process, which continuously improves the real-time performance of the system under a dynamically changing load environment.

2. A multi-system real-time system performance evaluation method based on rk3568 according to claim 1, characterized in that: The key time points of the task in step 1 include: The time when the task enters the ready queue: records the time point T_ready when the task changes from the blocked state or the dormant state to the ready state; The time when the task starts executing: records the time point T_start when the task is scheduled by the kernel to run on the CPU; Time when task execution ends: records the time point T_end when the task is completed or the CPU is actively released.

3. A multi-system real-time system performance evaluation method based on rk3568 according to claim 2, characterized in that: The step 1 also includes a delay calculation method for calculating task delay, and the delay calculation method includes the following sub-steps: Sub-step 11: Calculate the scheduling delay: Scheduling delay = Tstart - Tready\text{Scheduling delay} = T_{start} - T_{ready}Scheduling delay = Tstart - Tready; Sub-step 12: Calculate the actual execution time: Actual execution time = Tend - Tstart\text{Actual execution time} = T_{end} - T_{start}Actual execution time = Tend - Tstart; Sub-step 13: Calculate execution time deviation: Assuming that the expected execution time of the task is TexpectedT_{expected}Texpected, then: Execution time deviation = Texpected-actual execution time\text{Execution time deviation} = T_{expected}-\text{actual execution time}Execution time deviation = Texpected-actual execution time.

4. A multi-system real-time system performance evaluation method based on rk3568 according to claim 1, characterized in that: In step 2, the data transmission between the RTOS and Linux systems includes data information of task ID, priority, T_ready, T_start, T_end, scheduling delay, actual execution time, and execution time deviation.

5. The multi-system real-time system performance evaluation method based on rk3568 according to claim 1 is characterized in that: The method further includes a cyclictest evaluation method for evaluating the real-time performance of data using a cyclictest tool, wherein the cyclictest evaluation method includes the following sub-steps: Sub-step 31: Initialize shared memory, RTOS and Linux communicate through shared memory; Sub-step 32: In the main program of cyclictest, replace the jitter calculation logic; Sub-step 33: collecting jitter data of the task; Sub-step 34: Output the jitter statistics result of the task.

6. A multi-system real-time system performance evaluation method based on rk3568 according to claim 1, characterized in that: The prediction model adopts a linear regression prediction model.

Images