Rk3568-based multi-system real-time system performance evaluation method

Abstract

The present application relates to a kind of rk3568-based multi-system real-time system performance evaluation method, the multi-system includes RTOS, Linux and NPU, the evaluation method is passed to Linux by RTOS calculation task execution delay, utilizes the cyclictest tool of Linux to evaluate real-time performance, then it is calculated by NPU prediction model, obtains the real-time optimization strategy of dynamic balance, and the result is returned to RTOS, guides its adjustment task priority.The present application realizes closed-loop process from real-time evaluation to dynamic adjustment, covers the whole process of task execution delay acquisition, real-time performance calculation, optimization strategy prediction and back application, ensures the timeliness and effectiveness of real-time performance dynamic optimization.

Description

Technical Field

[0001] The present 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, where system real-time performance is extremely demanding, and in particular the industrial control industry, where system latency is extremely high, fluctuations in system latency can lead to severe performance degradation and even security risks. Therefore, accurately evaluating and optimizing the system's real-time performance is crucial.

[0003] Real-time operating systems (RTOS) are widely used in industrial control, embedded systems, and other fields. Their core mission is to ensure that critical tasks in the system are completed within strict time constraints. However, with the increasing complexity and variety of tasks, dynamically adjusting task priorities to balance real-time requirements and system resource utilization has become a critical issue.

[0004] Existing real-time performance evaluation methods are typically limited to static analysis and are unable to cope with dynamically changing system loads. On the other hand, the development of predictive models and artificial intelligence technologies has provided new ideas for real-time performance optimization. In particular, hardware accelerators (such as neural processing units (NPUs)) can enable rapid prediction and dynamic adjustment of real-time performance 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 a real-time task, the system records the key time points of the task, 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 priorities 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 via a high-speed communication interface. RTOS adjusts the task priority, scheduling strategy, or resource allocation based on the received optimization strategy, dynamically adapting to the real-time requirements of the system.

[0012] Step 6: Loop dynamic optimization: The system repeats steps 1 to 5 periodically to form a closed-loop optimization process, continuously improving the system's real-time performance 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 dormant state to the ready state;

[0015] Task start time: 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 is recorded as T_end.

[0017] Preferably, step 1 further 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 = T_start - T_ready;

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

[0021] Actual execution time = T_end - T_start;

[0022] Sub-step 13: Calculate execution time deviation: Assuming that the expected execution time of the task is T_expected, then: execution time deviation = T_expected - actual execution time.

[0023] Preferably, in step 2, the data format of data transmission 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 the 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: Counting task jitter data;

[0029] Sub-step 34: Output the jitter statistics 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 transmits 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 dynamic balanced real-time optimization strategy. The result is returned to RTOS to guide it to adjust the task priority, thus 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 by the present invention;

[0033] Figure 2 Flowchart of the present invention. DETAILED DESCRIPTION

[0034] In order to clearly and completely describe the objectives and technical solutions of the present invention and make the advantages more clearly understood, the embodiments of the present invention are further described in detail below 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, not all of them, and are only used to explain the embodiments of the present invention, not to limit the embodiments of the present invention. All other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0035] See also Figures 1 to 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] Perform real-time system performance evaluation on the above tasks. The real-time system performance evaluation 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 0.001s after the system is started.

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

[0045] Task execution end time (T_end): Task A completed execution in 0.003s.

[0046] Calculate 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]

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

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

[0056] Transport Protocol:

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

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

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

[0060] Cyclictest analysis:

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

[0062] Task A:

[0063] Maximum jitter: max_jitter = 3ms;

[0064] Minimum jitter: min_jitter = 1ms;

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

[0066] Count times: count = 3;

[0067] Average jitter: average_jitter = total_jitter / count = 6ms / 3 = 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: 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 for 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] Calculates the scheduling jitter of a thread using the current and previous timestamps.

[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: records the maximum value of each jitter value;

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

[0097] Average Jitter: Calculates the average value by accumulating the sum of the 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] Statistics 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 delay, execution time deviation, task priority, system load, task queue length, etc.

[0119] Model output:

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

[0121] Task A's priority is increased, and scheduling resources are increased by 20%;

[0122] Task B maintains the status quo;

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

[0124] Step 5: Optimize the strategy and send it back to RTOS:

[0125] Linux passes the optimization strategy back to the RTOS:

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

[0127] Task B: Maintaining priorities;

[0128] Task C: Priority decreased by 10%.

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

[0130] Step 6: Loop through 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 takes effect in the next cycle, thereby reducing the delay. As the system load changes, the model dynamically adjusts the execution resources of low-priority tasks to ensure the real-time performance of high-priority tasks.

[0133] While 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 these embodiments without departing from the principles and spirit of the invention, and that the scope of the 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 collection: In RTOS, during the execution of a real-time task, the system first records the key time points of the task, which include: the time when the task enters the ready queue: the time when the task changes from the blocked or dormant state to the ready state (T_ready); the time when the task starts execution: the time when the task is scheduled by the kernel to run on the CPU (T_start); the time when the task ends execution: the time when the task is completed or the CPU is actively released (T_end); Then, the scheduling delay, actual execution time and execution time deviation are calculated based on the critical time points of the task; Finally, the task critical time point and the scheduling delay, actual execution time and execution time deviation calculated based on the task critical time point are stored in the data buffer along with the task ID and priority; Step 2: The RTOS passes the data stored in the data buffer in step 1 to the system running Linux through shared memory; Step 3: Real-time performance calculation: After receiving the data in the data buffer, the Linux system uses the cyclictest tool to perform real-time performance evaluation on the data, calculate key performance indicators, and generate a real-time performance report based on task priorities 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 via a high-speed communication interface. RTOS adjusts the task priority, scheduling strategy, or resource allocation based on the received optimization strategy, dynamically adapting to the real-time requirements of the system. Step 6: Loop dynamic optimization: The system repeats steps 1 to 5 periodically to form a closed-loop optimization process, continuously improving the system's real-time performance 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 step 1 also includes a calculation method for calculating the scheduling delay, actual execution time and execution time deviation based on the key time points of the task, and the calculation method includes the following sub-steps: Sub-step 11: Calculate the scheduling delay: Scheduling delay = T_start - T_ready; Sub-step 12: Calculate the actual execution time: Actual execution time = T_end - T_start; Sub-step 13: Calculate execution time deviation: Assuming that the expected execution time of the task is T_expected, then: execution time deviation = T_expected - actual execution time.

3. A multi-system real-time system performance evaluation method based on rk3568 according to claim 1, characterized in that: Step 3 also includes an evaluation method for performing real-time performance evaluation on data using the cyclictest tool, and the 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: Counting task jitter data; Sub-step 34: Output the jitter statistics of the task.

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

Images