Hi Stefan,
On 1/3/2011 6:01 AM, Stefan Reuther wrote:
>> If you treat hard deadlines as MUST be met (else the system
>> is considered broken/failed), then anything with asynchronous
>> inputs is a likely candidate for "can't be solved" -- because
>> you can't guarantee that another input won't come along
>> before you have finished dealing with the first... "running out
>> of REAL time". Clearly, that isn't the case in the real
>> world so, either these aren't "hard" deadlines *or* they
>> are being missed and the world isn't coming to an end! :>
>
> Of course this is the case in the real world, too.
>
> User inputs have debouncing, so you can be sure the user will not hit
> that switch more than three times in a second. Networks have bitrates,
Sure, but you don't know that he isn't going to hit
"Full Speed Forward" and, a tenth of a second later, hit
"Full Speed Reverse", etc. I.e., you can't (reliably)
predict the future -- yet have to cope with it.
> so you can be sure that you don't get more than X frames per second.
> Audio has sample rates, so you can be sure to receive exactly 44100 /
> 48000 samples per second (and have to produce the same amount). Mass
> storage has seek and read times. Video has frame rates.
>
> At least in the systems I work on. So I know precisely how many CPU
> cycles I may use to decode a MP3 frame.
>
>>> associated problems, like having to convince the customer that the file
>>> they've found which misses deadlines on every other frame is the
>>> absolute exception, because nobody else puts 20 Mbps video on a floppy
>>> disc with 99% fragmentation or something like that.
>>
>> What if he wants to put a 100MB video on that floppy?
>> Some things just can't be done. Deal with it. :>
>>
>> Even consumers are starting to get enough sophistication
>> that they understand that a machine (tends to) "slows down" when
>> doing multiple things at once.
>
> Honestly? No. When I buy a hard-disk recorder which claims to be able to
> record two channels at once and let me watch a third, I expect it to
> work. That's what I pay them for. Plugging a TV receiver into my
Correct. But, if that "appliance" can also make phone calls,
control the spark plug firing sequence in your automobile
*and* receive/decode satellite radio broadcasts, would you
be upset if that third video stream had visual artifacts
resulting from "missed deadlines", etc.? *That's* the sort
of devices I'm involved with. The user knows the device
can't do *everything* (just like a user knows his PC can't
run *every* application CONCURRENTLY that it has loaded onto it).
So, if given a means of expressing "preferences" ("values")
for those activities/applications, the device itself could
take measures to satisfy those preferences (instead of
forcing the user to respond to an "insufficient resources"
message and decide which things to *kill* (since he can't
tell them to "shed resources" :> ).
> computer's USB port, run three instances of an MPEG codec, and hope for
> the best - that's what I can do myself.
>
> I would accept if the recorder says, "hey, these channels have such a
> high bitrate that I cannot record two of them at once". But I would not
> accept if it "silently" damages the recording. At least not if it does
> that in a very noticable way. If it drops a single frame every three
> hours, I'll never notice.
>
>> But, they would not be very tolerant of a video player that
>> simply shut down (because it decided it was *broken* since
>> it missed a deadline).
>
> That's just my point: design the system that this never happens. Sure
> this is harder than doing a desktop best-effort system.
See above. (In such an environment) you *eventually* come
to a situation where a user is asking more of you (device)
than you can do with the fixed resources in your "box".
If you *must* always be able to do everything, you end up
with more in the box than you need -- or, lots of dedicated
"little boxes".
If, instead, you allow the user to trade performance
and preferences, you can do more with less (money, space,
power, MIPS, etc.)
>>>> I.e., if your HRT system misses a deadline, does it even
>>>> KNOW that it did??).
>>>
>>> My favourite design priniciple: never check for an error condition you
>>> don't know to handle :-)
>>
>> Yeah, I think ostriches have a similar "defense mechanism". :>
>> Not sure how effective it is, though, if the problem still
>> exists.
>>
>> I try to arrange things to eliminate the possibility of
>> errors, where possible.
>
> That's probably similar things. For example, every UTF-8 related
> document says you should treat non-minimally encoded UTF-8 runes as an
> error. Now what should I do? Show a pop-up error message to the user?
> "Hey, your playlist file contains bad UTF-8!" 95% of them do not even
> know what UTF-8 is. So I ignore that problem. Which also simplifies a
> lot of other code because it can assume that I'll decode every 'char*'
> into a 'wchar_t*'.
Yes. In my case, often even heavier handed (e.g., my calculator
discussion restricting the character set to USASCII).
Or, little things like using unsigned data types for "counts"
(so the problem of dealing with negative values simply doesn't
exist)
> [kernel asks task to free resources]
>>>> Uncooperative tasks make life difficult! That;s the whole
>>>> point of this :>
>>>
>>> I'm not sure I understood you correctly (maybe we mean the same thing?),
>>> but the problem that immediately comes to my mind is applications that
>>> claim to be good citizens, but by intention/bug/sabotage aren't.
>>> Something like a heap overwrite error causing it to run into an infinite
>>> loop, not finding the page to free.
>>
>> "Thou shalt not release buggy code" :>
>>
>> Why assume the "bug" lies in the application? If you are going
>> to *tolerate* bugs, what if the bug lies in the kernel itself??
>> <frown>
>
> That's why kernels are usually written by much smaller (and better)
> teams than user-land code. Thus the kernel can isolate the buggy tasks
Yes, but that is no guarantee that there are no bugs. It just
shifts the probabilities around.
> from the proven error-free[tm] supervisor tasks, for example. Okay, it's
> annoying if the MPEG decoder crashes on that particular file, but the
> kernel should isolate that crash from the power management task, so the
> device can at least be turned off without needing a powercycle. In
> particular if powercycle means disassembling your car.
>
> At least, that approach works quite well for "our" devices.
> Unfortunately, we cannot prove (in a mathematical sense) that our
> userland code is completely bug-free. I can construct a (far-fetched,
> unlikely) case that crashes my code, just because I simply have no idea
> how to reliably detect that. At least, my code crashes a magnitude less
> often than that of our favourite competitor :-)
The problem I am usually faced with is very long up-times,
limited/constrained user interfaces (a user might not even
be "present") and, often, significant "costs" associated with
failures (financial or safety).
I enjoy spending resources (MHz, memory, complexity, etc.)
to improve these aspects of a product's design instead of
"cosmetic crap".
supper. Another bowl of pasta *really* would go down
quite nicely! Though I suspect I should probably have
something a bit more "substantial"... :<