B: Research in this country is going down. Prior to World War II, the United States was rather poor in research; that’s why radar was invented in England and Germany. We learned the value of research in World War II. But today the quickest way to save your bottom line is to cut off research. In the automobile industry, for example, the average CEO’s tenure is just 4.7 years, so the money you spend on research won’t help while you are CEO. That’s why there is great pressure to do something that will sell now, but on a national basis this kind of ethic is very dangerous.
From a 2004 interview. One of the strange things about the computer business is how little innovation happens these days. This is, I think, related to the gross undervaluing of software in the market. One of the free software advocates once explained to me that you could make money on free software by establishing a “brand”. That’s a remarkable theory for an engineer to embrace and, I think, represents the victory of bankers and marketing experts.
[ 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”.