6 ms·

Physical engineering aside, the operating system used is also quite interesting https://cntechpost.com/2021/06/22/chinas-tianwen-1-probe-powered-by-operating-sy

by eunos 5y ago

Physical engineering aside, the operating system used is also quite interesting https://cntechpost.com/2021/06/22/chinas-tianwen-1-probe-powered-by-operating-system-developed-by-local-team/ https://cntechpost.com/2021/06/22/chinas-tianwen-1-probe-pow... real-time response accurate to 8 milliseconds range. I am not that familiar with embedded software, but does that value really difficult to achieve?

crazypython 5y ago
Most games have real-time response around the 8-16 millisecond range.
- edrxty 5y ago
  Games are real time in the sense that their response window is 1/[desired frame rate] of-a-second. As far as hard realtime systems go, they're some of the slowest.
  - sitzkrieg 5y ago
    would you say that about games that are designed to run at 125+ fps?
    - danielheath 5y ago
      I mean, that’s only twice as fast. Industrial real-time needs far, far shorter response times.
      - crazypython 5y ago
        Games are only firm real-time, but the developers deserve respect for the response time. 1000/125 = respond in 8ms. Many games run at 144FPS (monitor resolution), or every 7ms.
        Danieru 5y ago
        Technically few games have single frame response times. The default UE4 configuration is 4 frames of latency. With tuning it can be brought down to 1 frame of latency. Unity, is uh, Unity.
    - snovv_crash 5y ago
      Yes, things like drone controllers run at 500Hz+ and have much higher cost of failure if a single "frame" runs overtime.
- jml7c5 5y ago
  Yes, but nothing explodes or breaks if they miss that budget. A single missed frame isn't ideal, but it's not considered a system failure.
danhor 5y ago
Seriously depends on what you do. Iq you're doing really low-level stuff, you could probably get in the microsecond range quite easily (for trivial stuff). But 8 milliseconds doesn't sound that impressive to me.
edrxty 5y ago
IIRC you can get into the tens of microseconds with an x86 box running a heavy linux graphic desktop with real time patches. Single digits with core pinning on a light headless system. Bear in mind that real time performance and throughput are perpetually at odds with each other. Long story short, scheduling things such that everything happens in a tight time window means you need to leave gaps in the timeline. This tradeoff is variable so you can loosen requirements for running something like a rover where there isn't really all that much need for tight realtime control, it's not trying to achieve micron positioning as it drives around. That means you can use a more efficient CPU and lower your idle current which is probably the real constraint here.
- deleted 5y ago
  [deleted]
magicsmoke 5y ago
Looks like Kylin OS uses the Linux kernel. While not impossible to use in a real-time application (SpaceX Falcon 9 uses it) there's definitely work involved in stripping it down enough to work as an RTOS. NASA Perseverance uses VxWorks instead, which was designed from the beginning as an RTOS. VxWorks is also proprietary and looks like it's US export restricted. 8 ms isn't hard to hit. 8 ms with 100% reliability is.
- edrxty 5y ago
  What? 8ms is incredibly slow for realtime systems. A difficult target for a control system would be three orders of magnitude lower than that on a full size OS like linux. VxWorks is being partly phased out too, last I heard wind river was pushing people towards their own linux based offering. Speaking from experience it's absolutely miserable to develop on because of the licensing model and reliance on the Eclipse IDE. If you need a low level system FreeRTOS/CMSIS is a far better option and if you want linux compatibility (frequently just the convenience of ssh and rsync) just use real time linux.
  - nine_k 5y ago
    I suppose what is slow directly depends on the hardware. On a 10 MHz CPU, 8 ms = 80k clocks, which is not necessarily easy to hit consistently, because of critical sections and scheduling overhead. On a 2 GHz CPU, 8 ms can as well be the normal slice of the scheduler. I suppose the CPU on this machine may be severely underclocked because of the power requirements.
    - edrxty 5y ago
      My question isn't really in response to the specifications of the rover but rather the inaccuracy of the above statements.
carlsborg 5y ago
In some "hard real time" systems failure to meet the deadline is treated as system failure. Vs "soft real time" where its a transient error. So the goal is bounded response time/latency/jitter at the 100th percentile.
smoldesu 5y ago
It's only impressive in the sense that they have to use really shitty computers to achieve that number. Playing around with Rust on a reasonably powerful x86 box, you'll have no problem writing programs with a response time in microseconds, but they aren't using the same computers you and I do (or Rust for that matter). Word on the street is that most space tech is based on PowerPC, since you can buy decently powerful radiation-hardened RISC chips without breaking the bank (only $300,000 or so).
- edrxty 5y ago
  This commenter is correct. Things like radiation tolerance and power draw are much bigger concerns. I've seen a number of projects using RT systems entirely because they were based on earlier systems that were RT and therefore the engineers just used the same kernel despite having no RT requirements. PowerPC is popular because there are a couple companies out there that are taking these parts and running them through radiation beams to certify them for spaceflight (essentially profiling their failure modes so devs can account for them). ARM isn't popular yet as they tend to make it difficult to license designs for lower volume silicon but RISC-V in particular is gaining traction here very rapidly.
justicezyx 5y ago
https://en.wikipedia.org/wiki/Kylin_(operating_system) https://en.wikipedia.org/wiki/Kylin_(operating_system) If my impression is correct, this is based on Linux kernel. Since other comments appearing not mentioning that, just add here in case someone mistaken it with a custom embedded OS. (Although I know little about embedded OS either).
grawprog 5y ago
Siemens Siamatics PLC controllers can achieve real time response in the 250μs range.
Black101 5y ago
> I am not that familiar with embedded software, but does that value really difficult to achieve? HFTs are in the nanosecond range... so probably not that hard. Also, my ping to remote servers is often 5ms...
slmjkdbtl 5y ago
thank god they didn't put a browser engine in that thing
femto 5y ago
Less than 1us is relatively straightforward on an embedded system. My application was simulcast for a software defined radio. It was running on a TMS320 DSP (192MHz) with DSP/BIOS as the operating system. Timing was driven by a GPS 1PPS pulse connected to an interrupt pin. The absolute response time was around 100ns and repeatability was of the order of 10 nanoseconds (dominated by the drift between the 1PPS and the processor's clock).
LargoLasskhyfv 5y ago
If based on anything described here https://en.wikipedia.org/wiki/Kylin_(operating_system) https://en.wikipedia.org/wiki/Kylin_(operating_system) I'm unimpressed, the same way I'm unimpressed by Space-X using Linux. OTOH, who really cares if it flies, works, whatever without crashing?

by eunos 5y ago

crazypython 5y ago

Most games have real-time response around the 8-16 millisecond range.

edrxty 5y ago
Games are real time in the sense that their response window is 1/[desired frame rate] of-a-second. As far as hard realtime systems go, they're some of the slowest.
- sitzkrieg 5y ago
  would you say that about games that are designed to run at 125+ fps?
  - danielheath 5y ago
    I mean, that’s only twice as fast. Industrial real-time needs far, far shorter response times.
    - crazypython 5y ago
      Games are only firm real-time, but the developers deserve respect for the response time. 1000/125 = respond in 8ms. Many games run at 144FPS (monitor resolution), or every 7ms.
      - Danieru 5y ago
        Technically few games have single frame response times. The default UE4 configuration is 4 frames of latency. With tuning it can be brought down to 1 frame of latency. Unity, is uh, Unity.
  - snovv_crash 5y ago
    Yes, things like drone controllers run at 500Hz+ and have much higher cost of failure if a single "frame" runs overtime.
jml7c5 5y ago
Yes, but nothing explodes or breaks if they miss that budget. A single missed frame isn't ideal, but it's not considered a system failure.

danhor 5y ago

Seriously depends on what you do. Iq you're doing really low-level stuff, you could probably get in the microsecond range quite easily (for trivial stuff). But 8 milliseconds doesn't sound that impressive to me.

edrxty 5y ago

IIRC you can get into the tens of microseconds with an x86 box running a heavy linux graphic desktop with real time patches. Single digits with core pinning on a light headless system. Bear in mind that real time performance and throughput are perpetually at odds with each other. Long story short, scheduling things such that everything happens in a tight time window means you need to leave gaps in the timeline. This tradeoff is variable so you can loosen requirements for running something like a rover where there isn't really all that much need for tight realtime control, it's not trying to achieve micron positioning as it drives around. That means you can use a more efficient CPU and lower your idle current which is probably the real constraint here.

deleted 5y ago
[deleted]

magicsmoke 5y ago

Looks like Kylin OS uses the Linux kernel. While not impossible to use in a real-time application (SpaceX Falcon 9 uses it) there's definitely work involved in stripping it down enough to work as an RTOS. NASA Perseverance uses VxWorks instead, which was designed from the beginning as an RTOS. VxWorks is also proprietary and looks like it's US export restricted. 8 ms isn't hard to hit. 8 ms with 100% reliability is.

edrxty 5y ago
What? 8ms is incredibly slow for realtime systems. A difficult target for a control system would be three orders of magnitude lower than that on a full size OS like linux. VxWorks is being partly phased out too, last I heard wind river was pushing people towards their own linux based offering. Speaking from experience it's absolutely miserable to develop on because of the licensing model and reliance on the Eclipse IDE. If you need a low level system FreeRTOS/CMSIS is a far better option and if you want linux compatibility (frequently just the convenience of ssh and rsync) just use real time linux.
- nine_k 5y ago
  I suppose what is slow directly depends on the hardware. On a 10 MHz CPU, 8 ms = 80k clocks, which is not necessarily easy to hit consistently, because of critical sections and scheduling overhead. On a 2 GHz CPU, 8 ms can as well be the normal slice of the scheduler. I suppose the CPU on this machine may be severely underclocked because of the power requirements.
  - edrxty 5y ago
    My question isn't really in response to the specifications of the rover but rather the inaccuracy of the above statements.

carlsborg 5y ago

In some "hard real time" systems failure to meet the deadline is treated as system failure. Vs "soft real time" where its a transient error. So the goal is bounded response time/latency/jitter at the 100th percentile.

smoldesu 5y ago

It's only impressive in the sense that they have to use really shitty computers to achieve that number. Playing around with Rust on a reasonably powerful x86 box, you'll have no problem writing programs with a response time in microseconds, but they aren't using the same computers you and I do (or Rust for that matter). Word on the street is that most space tech is based on PowerPC, since you can buy decently powerful radiation-hardened RISC chips without breaking the bank (only $300,000 or so).

edrxty 5y ago
This commenter is correct. Things like radiation tolerance and power draw are much bigger concerns. I've seen a number of projects using RT systems entirely because they were based on earlier systems that were RT and therefore the engineers just used the same kernel despite having no RT requirements. PowerPC is popular because there are a couple companies out there that are taking these parts and running them through radiation beams to certify them for spaceflight (essentially profiling their failure modes so devs can account for them). ARM isn't popular yet as they tend to make it difficult to license designs for lower volume silicon but RISC-V in particular is gaining traction here very rapidly.

justicezyx 5y ago

https://en.wikipedia.org/wiki/Kylin_(operating_system) https://en.wikipedia.org/wiki/Kylin_(operating_system) If my impression is correct, this is based on Linux kernel. Since other comments appearing not mentioning that, just add here in case someone mistaken it with a custom embedded OS. (Although I know little about embedded OS either).

grawprog 5y ago

Siemens Siamatics PLC controllers can achieve real time response in the 250μs range.

Black101 5y ago

> I am not that familiar with embedded software, but does that value really difficult to achieve? HFTs are in the nanosecond range... so probably not that hard. Also, my ping to remote servers is often 5ms...

slmjkdbtl 5y ago

thank god they didn't put a browser engine in that thing

femto 5y ago

Less than 1us is relatively straightforward on an embedded system. My application was simulcast for a software defined radio. It was running on a TMS320 DSP (192MHz) with DSP/BIOS as the operating system. Timing was driven by a GPS 1PPS pulse connected to an interrupt pin. The absolute response time was around 100ns and repeatability was of the order of 10 nanoseconds (dominated by the drift between the 1PPS and the processor's clock).

LargoLasskhyfv 5y ago

If based on anything described here https://en.wikipedia.org/wiki/Kylin_(operating_system) https://en.wikipedia.org/wiki/Kylin_(operating_system) I'm unimpressed, the same way I'm unimpressed by Space-X using Linux. OTOH, who really cares if it flies, works, whatever without crashing?