4 ms·
The term 'real-time' is used _very_ loosely here. In industrial settings, in order to claim realtime-properties, you need to make guarantees about the runtime b
by jpfr 12y ago
The term 'real-time' is used _very_ loosely here.
In industrial settings, in order to claim realtime-properties, you need to make guarantees about the runtime behavior of server, client and the network infrastructure in between.
IP-based Ethernet -> not realtime capable (without extensions)
Python (garbage collected language) -> not realtime capable
You can at most claim to achieve soft-realtime.
As in "sub-500ms but only most of the time".. o_O
- rpdillon 12y agoDifferent contexts. For weapon systems and industrial systems, real-time operating systems are needed to guarantee true real-time behavior. That usage makes no sense in the context of internet messaging for the reasons you describe. For human-to-human messaging, I think they're referring to a property more akin to synchronous (versus asynchronous) messaging, i.e. chat versus email. I speculate that the matrix team thinks this is an acceptable overloading because, as a practical matter, the two concepts have nothing to do with one another.
- ara4n 12y agorpdillon is totally right - the term is overloaded. We're using "realtime" exclusively here to mean synchronous human communication - like the RT in WebRTC. In other words, IM or VoIP - anything where you expect to get a response from the other user inmediately rather than waiting asynchronously. This of course clashes with the RTOS style use of the word, and we aren't claiming that Matrix has any hard realtime timing guarantees at all, other than the soft realtime behaviour media stacks like WebRTC give you by means of high priority threads. In retrospect it's a confusing term; we should probably avoid using it :) disclaimer: use of the word realtime in the Matrix.org blurb is all my fault...