[ see revised version ]
(edited August 18 2007 to add back link and formatting)
“Soft real-time” is a perfect example of the “soft design” I was complaining about in the previous post. There are perfectly good ways of characterizing quality of service assurances. For example, you could say that the average = x and there are no outliers more than n standard deviations from the mean. Or you could state that over any interval of time t seconds there will be at most n delays of more than E milliseconds or so on. But soft real-time is usually characterized by a lot of handwaving. Doug Jenson has a semi-precise definition:
The general case of a deadline (which is a soft deadline) has utility measured in terms of lateness (completion time minus deadline), tardiness (positive lateness), or earliness (negative lateness). Larger positive values of lateness or tardiness represent lower utility, and consequently larger positive values of earliness represent greater utility.
That is, he says a soft real-time system will have a function
0 =< Utility(Deadline, Error) =< 1
where, for my purposes Error > 0 for a late computation and Error < 0 for an early computation. But, but, and but, you never see the utility functions in discussions of so-called “soft real-time” systems because very few quality of service (QOS) systems have a nice linear function. If you are playing videos, then there will be a big difference between requirements for editing (which may permit no frames later than 100 microseconds) and consumer viewing which will be a moving target but may allow up to 1 frame more than 1 millisecond late over a second but no more than 1 frame more than 20 milliseconds late over 10 seconds or something like that. Why don’t we see these kind of measures for soft real-time systems? Because, in practice, in order to make any QOS assurances, you need to be able to make hard assurances. If one frame is 1.5 milliseconds late, you have to guarantee that the next frame won’t be late by more than 100 microseconds and so on. So, in practice, “soft real-time” means doesn’t really work, but I haven’t measured it.
Soft-real-time is not the same as QOS. QOS is defined against some specification. Soft-real-time has no more technical meaning than “fast”.