the usefulness of a result degrades after its deadline, thereby degrading the system’s quality of service.
Uhhhh. Okay. By that criteria Windows 95 was a soft real time system and so was 3BSD and so is Linux. Wikipedia is not a great source, but the next couple of Google hits aren’t much better. For example http://users.ece.cmu.edu/~koopman/des_s99/real_time/ says
In a soft real-time system, a degraded operation in a rarely occurring peak load can be tolerated.
That’s not a contract, that’s a fancy way of saying nothing. What are examples of real soft real-time guarantees/contracts offered by real operating systems? I’m looking for answers of the form:
In (OS-name) if programmer does (what-programmer-needs-to-do) then the operating system guarantees (what-the-system-guarantees).
Asked By : Wandering Logic
Answered By : Gilles
What does soft realtime mean? Cynics will say “basically nothing”. (…) Many telecomms systems have less strict requirements [than hard realtime], for instance they might require a statistical guarantee along the lines of “a database lookup takes less than 20ms in 97% of cases”. Soft realtime systems, such as Erlang, let you make that sort of guarantee.
And this does provide a useful definition. Soft real-time indicates a design which is optimized towards each individual task taking no more than a certain amount of time, rather than towards optimizing the total time spent to perform all tasks. For example, a soft real-time system would aim to complete 99.9% of the requests in 10ms and process 100 requests per second, where a non-real-time might aim to proceed 200 requests per second but allow the occasional request to block for 50ms or more. A hard real-time would guarantee one request every 15ms no matter what. Soft real-time is used for applications where a missed deadline means a degradation of service, but is not performance-critical. Multimedia and telephony are some typical use cases. Each audio or video frame must be rendered it time, or else it has to be skipped; but skipping a frame is not the end of the world. The designers of Erlang had similar objectives on reliability in other matters: they observed that it was better for a telephone exchange to very occasionally drop a call, but to be absolutely sure that the exchange as a whole would keep working come what may, than to ever risk catastrophic failure in trying to maintain connections at all cost. In contrast, something like controlling a motor requires that the software never misses a deadline. This has costs: the overall performance is typically slower, and only relatively simple behaviors can be achieved. On the other side of the spectrum, a number crunching application typically cares only about overall performance — what matters is how fast the 1000×1000 matrices are multiplied, not how fast each column is calculated.
Best Answer from StackOverflow
Question Source : http://cs.stackexchange.com/questions/29864