SDK - Analysis and new features in ctrlX OS CPU management

This How-to article presents a test case in which a dummy C++ application with multiple threads is run in ctrlX OS.

We will first compare the performance between running the application in ctrlX COREvirtual, ctrlX X3 and ctrlX X7. We invite the reader to further test with ctrlX CORE X5 when it becomes available.

Secondly, we present a new functionality available on ctrlX OS 2.6 which allows the user to choose how many CPU cores can be used by the application.

1. Context

Apps in ctrlX OS are classified as realtime (RT) and non-realtime (NRT). This classification could be misleading, so let's clarify it first.

RT apps are such that use the ctrlX Automation functionalities, e.g. the scheduler. In this group we find PLC or EtherCAT Master for example. NRT apps are all the others, e.g. any app that you can build with the conventional SDK, the one publicly available. However, it is important to understand that a NRT time can actually behave as a realtime system, for instance, ROS2 ecosystem apps are a realtime systems handled by the ROS scheduler, but, to the eyes of ctrlX classification, they lay inside the NRT group. 

In this How-To we analyse the performance of one of those NRT apps that could have been built with the official ctrlX SDK. 

2. Testbench program

The performance of the system is evaluated by running in isolation an app that executes in an infinity loop the functionality shown in the C++ snippet pasted next.

const int numThreads = 25; // Number of threads to create
std::mutex mtx; // Mutex for print tasks

// Start a timer 
auto start = std::chrono::high_resolution_clock::now();

// Create an empty vector to store the threads
std::vector<std::thread> threads; 

// Create threads and assign tasks
for (int i = 0; i < numThreads; ++i) {
    threads.push_back(std::thread(demandingTask, i + 1, std::ref(mtx)));
}

// Join threads with the main thread
 for (auto& t : threads) {
        t.join();
}

// Stop the timer 
auto end = std::chrono::high_resolution_clock::now();

As we see, it creates 25 threads and put a demandingTask in each of them, then wait to join them, the elapsed time is recorded. Once this is done, the process is started again, i.e. new 25 threads, wait for joining, etc.

The snippet just aims to show the tested functionality, but it is not the complete application. If you are interested in the full source code to build this test bench yourself, please leave us a message in the comment field below.

3. Device performance comparison

In this section we will compare the average execution time of the multithread loop presented above in the different platforms in which ctrlX OS can be run nowadays: ctrlX COREvirtual, ctrlX CORE X3 and ctrlX CORE X7. 

The devices are configured to allow the usage of 2 CPU cores for NRT apps, this is fixed in ctrlX OS 2.4 and previous. See next section for the new feature included from ctrlX OS 2.6 where this configuration can be changed.

In the next table we summarize the performance metrics.

As it can be seen, the performance of ctrlX COREvirtual and ctrlX CORE X7 is similar. It can be understood given the similarities between the processing units used. On the contrary, ctrlX CORE X3 shows a way worse performance, explained by the lower performance CPU mounted in this device.

4. CPU core selection in ctrlX OS 2.6

ctrlX OS 2.6 includes a new feature in which the user can select how many CPU cores are dedicated for RT functionalities. The configuration can be done by going to Setting > System Performance, and then click in the ¨gear¨ in the upper right corner. The following menu will pop up:

Here you can select how many cores are dedicated for RT, i.e. that your NRT application is allowed to use. By default, as explained before, core 2 and 3 are selected for RT. In this window you can also go to the Memory tab and block some RAM memory for RT applications, by default no memory is reserved.

***

In this section we compare the performance change in the system when the number of allowed cores is changed. All the cases correspond to ctrlX CORE virtual with ctrlX 2.6.2. The performance of ctrlX CORE virtual is highly dependent of the host system in which it is running since the resources are taken from it, for this reason the execution times presented here are just informative.

4.1. 2 core for NRT

We can see how the tasks are only scheduled in core 0 and 1. We have average 10 loops and the average execution time is 18.43 seconds.

4.2. 3 core for NRT

We can see how the tasks are only scheduled in core 0, 1 and 2. We have average 10 loops and the average execution time is 14.41 seconds.

4.3. 4 core for NRT

We can see how the tasks are scheduled in core 0, 1, 2 and 3. We have average 10 loops and the average execution time is 11.27 seconds.

4.4. 12 core desktop device

We can see how the tasks are scheduled in cores from 0 to 11. We have average 10 loops and the average execution time is 6.99 seconds.

4.5 Summary

5. Conclusions

We have seen in this How-To how ctrlX OS handles parallel computing as any other modern OS does, being able to successfully run multithreading applications and schedule the jobs in the CPU cores that we let the app to use, maximizing its use. 

We are looking forward to your applications running in ctrlX OS!