[detinho]

I'm probably wrong, but isn't real time not about how fast you can react but if you can react on a defined time constraint? Or is there a time threshold you can't consider real time any more like 1 day? Edit: just like you said, 10ms, 1s, etc.

[tdeck]

You're correct, the definition requires that operations be bounded, not necessarily "fast".

[bluGill]

The time depends on your problem. The real time is more about bad things happen if you don't respond on time. If you click on a webpage and your browser times out loading it is a real time failure, but the failure isn't bad enough that anyone thinks of browsers as real time because the failure isn't really harmful.

[fullstop]

Maximum tick time for RTOS are usually measured in tenths of seconds. The range is typically from microseconds to about 100ms.

edit: updated to reflect that I meant "upper bound"

edit2: completely reworded to be more clear.

[monocasa]

Time constraints on an RTOS are what you need them to be for the domain.

On the RTOS I was the lead for, some constraints were measured in 100s of ns.

Edit to address the edit: our upper bound in that case was single digit microseconds.

[fullstop]

My point was that once you pass the 100ms mark most would not consider it "real-time".

[monocasa]

Ah it reads backwards, that you're asserting no one actually deals with constraints tighter than 100 ms.

[fullstop]

We're coming from different directions. My upper bound was "after this point it won't be rtos", but I've reworded it entirely to be more clear.

[monocasa]

Upper bound is a specific term in real time also unfortunately.

Might I suggest wording such as "upper bound constraints exceeding 100ms aren't typically addressed with real time methods".