Re: Good guy timers

On 3/30/2014 8:17 AM, David Barbour wrote:
>
> On Sun, Mar 30, 2014 at 2:01 AM, Jed Donnelley 
> <capability-iCFHVraI1K1Wk0Htik3J/[email protected] <mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]>> wrote:
>
>
>     your mention of a human supervisor who isn't paying attention
>     seems to me a particularly good case for good guy timers.
>
>
> Your 'good guy' timers are essentially just a way to avoid actually 
> timing out unless there is a competitor for the resources.

I of course bristle a bit at the adverb "just" in the above sentence.

<aside>  Interesting English word, "just", with such varied meanings:

http://www.merriam-webster.com/dictionary/just

In fact I find it difficult to find your dismissive meaning for "just" 
in the above definition, though it is common usage.  I guess:

/3 a/ *:* only <http://www.merriam-webster.com/dictionary/only>, simply 
<http://www.merriam-webster.com/dictionary/simply> </just/ last year> 
</just/ be yourself>

comes closest.  Example from the above, "She called him a liar and told 
him he was /just/ like all the other men she'd met." Interesting.  In 
terms of multiple meanings it reminds me a bit of the German word "doch".
</aside>

As I mentioned previously this function of 'just' avoiding actually 
timing out unless there is a competitor for resource solved some major 
problems for us.

> However, timers for human supervisors are more often for things like 
> "okay, we're about to crash. please select one of these actions or 
> perform another within 3 seconds, or I'll need to guess which action 
> is best." Timeouts are often relevant in domains where timing of 
> actions and commitment to actions are relevant.

Certainly /timing/ is relevant in such cases.  The use of the term 
"timeout" seems a bit odd to me in the above context:

http://en.wikipedia.org/wiki/Timeout_%28computing%29

"Timeout allows a more efficient usage of limited resources without 
requiring additional interaction from the agent interested in the goods 
that cause the consumption of these resources. The basic idea is that in 
situations where a system must wait for something to happen, rather than 
waiting indefinitely, the waiting will be aborted after the timeout 
period has elapsed. This is based on the assumption that further waiting 
is useless, and some other action is necessary."

(note - I wasn't involved in the writing of the above Wikipedia page - I 
just looked it up to see if my use of the "timeout" term was way off :-)

The above is the sense in which I've been using the "timeout" term.

> For something like live videos, timers are necessary not due to a 
> human supervisor but due to buffering issues.  There is a limit to how 
> much one can buffer live video while waiting for the remote client to 
> fetch them.
>
> Now, there are ways around this for video (such as using a ring-buffer

If there is a limit and you reach that limit then of course the oldest 
video will no longer be buffered.  A ring buffer seems appropriate to me 
in that case.  Not really a "timeout" in my terminology, though I can 
understand how you are applying the term.

In fact I believe the "ring-buffer" notion fits with the "good guy" 
timer concept.  Think of each bit of video storage as a resource. You 
conceptually have a timer with each bit tight enough so that if data 
keeps being produced at a constant rate and not being consumed, then you 
start "timing" out the oldest data.  If the data just keeps coming at a 
regular pace and isn't consumed, then by the time the buffer is full the 
oldest part of the buffer:

1.  Has timed out, and

2.  Is needed.

so it's "good guy" timer applies and it is recycled - just as with the 
"ring buffer" concept.

To generalize this example for illustration, suppose you have a video 
buffer that is being used for multiple bursty producers (e.g. perhaps 
due to upstream delays or resolution differences) and multiple 'bursty' 
(occasionally delayed) consumers (e.g. think of a relay satellite).  In 
that case I believe the good guy timer concept applies perfectly, though 
I could imagine finer priority schemes if the various incoming streams 
have different values.  For example high value incoming Mars data might 
be prioritized over a humorous sequence from the International Space 
Station.  I worked briefly at the "blue cube" in Sunnyvale where they 
juggled priorities of such incoming signals for ground stations all the 
time, for many years using a very large sheet of butcher paper on the wall.

Where other criteria start to become relevant is when time itself has a 
value.  For example, if older data is considered irrelevant or at least 
having less value, then keeping only the most recent data seems 
appropriate.  Even this case can be equivalent to a good guy timer 
mechanism with the "timeout" value set to zero (recycle oldest first in 
any case - just never block and always recycle resources as needed).

I'm suggesting that the "good guy" timeout concept is a bit more robust 
than you might otherwise think, though I certainly acknowledge that 
other priority schemes and adjustments of "timing" can be important in 
context.

> and accepting lossy video in case of timeout). But it can also be 
> expensive to keep producing video, in terms of battery life and so on, 
> e.g. if the video is coming from a remote robot platform. And it might 
> not be so expensive to simply restart the video. So one needs to 
> prioritize. Your 'good guy timers' would favor to keep the video 
> running and buffering in case someone is debugging the code or 
> similar, unless someone else needs the video stream.

I'm not sure, but the above sounds to me much like the case of multiple 
sources/sinks that I discussed above - where I acknowledge that 
"priorities" can indeed be important.  If there is more in the above 
example I didn't get it and perhaps you could clarify?

>
>     From my perspective the reason for timing something out is that
>     some resource is being consumed
>
>
> I think that's a very limited perspective. Timeouts can be used for a 
> fair number of reasons, including semi-autonomous systems and robust 
> health-maintenance (e.g. watchdog timers on heartbeats), and even 
> partitioning tolerance. Recovering exclusive resources is just one use 
> of timers, is it not?

This may partly be a matter of definition - e.g. that definition of 
"timeout" on the Wikipedia page vs. something else.  Certainly I 
acknowledge that notion of "time" can come into play in may ways in 
computing systems.

--Jed

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk