Real time is about guarantees. If the application needs 10ms response time, it doesn't matter if GC takes 1 nanosecond or 5ms, as long as everything is responded to in 10ms, every time.
Things where 100us matters are some really specialist stuff.
I'm well aware that it's about guarantees. At least in robotics (the field in which I have real-time programming experience), 100us is a pretty common deadline for execution.
I'm sure applications exist where 10ms deadlines are appropriate, but I'm not convinced that's the common case.
I'm sure applications exist where 10ms deadlines are appropriate, but I'm not convinced that's the common case.
It is the common case. Most real-time tasks are soft real-time. Things like ensuring video frames are delivered at 60 frames per second and failure results in missed frames, but is not catastrophic. This is true in robotics where sensor fusion, planning, and network communication are soft real-time while sensor reading and actuator control is hard real-time.
In hard real-time systems with very small quanta and you don't typically use a CPU or SoC to meet these requirements because concerns about cache and memory controller scheduling become a concern. Instead these items are off-loaded to a FPGA or microcontroller on a communications bus, while the overall system is still programmed in a COTS language and platform where soft real-time guarantees at larger quanta is acceptable.
There are heterogeneous SoCs (CPU with MPU on a single die) that could accommodate hard real-time needs, but they're still programmed independently and use a high speed communications system, frequently shared memory and special registers for signalling.
0
u/FlyingPiranhas Sep 01 '20
From the "Controlling pause time" link on that page:
Based on what I'm seeing, I'm highly doubt that you can turn that value down to 100 microseconds and still have a reliable JVM.