0

I'm currently working building and implementing robot control system using cellular system(4G or 5G).I am thinking of using RTOS in order to reduce processing time in server.

The server receive request from the robot and response to it. Through the experiments, I found the following.

  • end-to-end delay: 30~50ms(edge)/70~90ms(cloud)
  • Processing time: 10~15ms
  • data flow:
robot -----> base station -----> edge server
      <-----              <-----
                 or
robot -----> base station -----> cloud server
      <-----              <----
  • experimental setup
    • CPU Intel Core i9
    • OS linux vanilla kernel

Now, I am thinking of installing preempt-rt kernel on cloud/edge servers.

Are the end-to-end delay and the processing time reduced more than 10ms by installing RTOS on the servers?

Murchadh
  • 1
  • 1
  • 1
    Generally, preempt-rt trades kernel responsiveness with throughput. So delay may decrease but process time might be increased. – Louis Go Dec 06 '20 at 04:58
  • Do other RTOS also increase process time ? – Murchadh Dec 06 '20 at 06:28
  • That is the main concept of rtos. Trade throughput with responsiveness. Though tunning realtime priority might help to retain operation time for certain process. – Louis Go Dec 07 '20 at 07:28
  • 2
    Your communication delay may dominate over your scheduler delay, at least if you make relatively suitable schedular settings. The place for an RTOS would be in the robot, not on the server, and you want to keep the time critical things local as networks (especially mobile ones) are at times rather slow. – Chris Stratton Dec 09 '20 at 06:30
  • @Murchadh That was a comment, not an answer. However what Chris Stratton said. You have little control over the latency or availability of the communications link, so real-time capability in the "server" offers little advantage. – Clifford Dec 10 '20 at 16:58

1 Answers1

1

I'm currently working building and implementing robot control system using cellular system(4G or 5G).I am thinking of using RTOS in order to reduce processing time in server.

An RTOS is not about "reducing processing time", it is supports fast and deterministic response to events. That is, response to real-world external events can be effected with well defined minimum and maximum response times. I say "supports" because there are plenty of way the unwary can mess up the scheduling and IPC and make a system behave poorly in this respect.

Reducing processing time is rather a matter of processing speed and processing load. i.e. how fast your processor is and what you are asking it to process. To that extent, selection of efficient algorithms and data structures and compiler optimisation are more effective approaches that using an RTOS.

The server receive request from the robot and response to it. Through the experiments, I found the following.

Ok, now it is not clear to me where you are proposing to use the RTOS. On the Robot or on the server? If on the server, to get deterministic real-time response end-to-end, the communication channel also has to be real-time capable - i.e. guarantee maximum response time. Can it do that?

Now, I am thinking of installing preempt-rt kernel on cloud/edge servers.

preempt-rt does not truly make Linux and RTOS, though it may be adequate and appropriate in this application. It has the benefit of providing all the hardware, I/O and networking support for a COTS PC architecture board which most (but by no means all) true RTOS lack, and which you might have to provide by third-party components - that's a big ask of something as complex and PC.

If it works with plain Linux and you need to guarantee specific response times, then it is appropriate. You you are just trying to make the code run faster, this is not the way. A priority based pre-emptive scheduler allows you to ensure specific code runs when it demands it rather then when the kernel gets around to scheduling it. It prevents delay in processing rather then speeds processing.

Are the end-to-end delay and the processing time reduced more than 10ms by installing RTOS on the servers?

The software running on the server cannot change the latency of the communication network. As noted above what you achieve is minimum delay in processing, not faster processing. In this case minimising that delay offers little advantage without latency guarantees in the communication which you are unlikely to get - measuring "typical" response times is no guarantee.

robot -----> base station -----> edge server
      <-----              <-----
                 or 
robot -----> base station -----> cloud server
      <-----              <----

Unless every component - robot, communications link, base-station and server - are real-time capable, then system as a whole will not be real-time capable.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • Now, I grasped what you described above. Then, why is response time deterministic on RTOS (especially on preempt-rt kernel). Best regards. – Murchadh Dec 12 '20 at 12:57
  • @Murchadh Different question best perhaps to post as a new question. But in brief, in a priority based preemptive scheduler the highest priority task that is ready to run runs. A typical desktop OS operates on a time slice, and higher priority tasks simply get a greater share of available time slices, but when a task runs is when it that task's turn, and the time to that turn is non deterministic, depending on when it last ran and how many other tasks are running and demanding a slice. – Clifford Dec 12 '20 at 13:41