Self restarting property of RTOS-How it works?

Ed Beroset <beroset@mindspring.com> writes:
> It's interesting to learn that no engineers were ever involved in
> building such flaws.
>
> My background happens to be more in the engineering than the
> computer science end of things, but I don't share your evident
> contempt for the field.  Here's an example: An embedded
> communication system receives packet-based messages of varying
> lengths at an average rate of 100 packets per minute, but
> asynchronously.  Because the system also checks its timing against
> the recovered clock from the messages, which it can easily keep
> synchronized within limits as long as it doesn't go too long without
> receiving a packet.  What is the probability that no packets will
> arrive in an interval of five seconds?
>
> I can answer that question easily because I've studied a little
> computer science.  Can you?  If not, how can you properly engineer
> the system?

here is example of a configuration and workload analysis
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was System/1?)

with the help of performance predictor and configurators on
hone:
http://www.garlic.com/~lynn/subtopic.html#hone

hone was the online system(s) that provided support for world-wide
sales, marketing, and field people. 

performance predictor was outgrowth of work at the science center on
performance management, workload profiling, the early technology
transition from performance management to capacity polanning:
http://www.garlic.com/~lynn/subtopic.html#bench

that allowed sales people to input customer configuration and
operational information (often softcopy extracted from the system
itself) and be able to do what-if questions about changes to
configuration and workload.

as hardware got more and more complex ... configurators were the
applications that allowed a sales person to specify rough product
specification ... and the application would make sure that enuf
correct information was supplied for ordering the equipment.

now, this particular analysis ... i presented at the SNA architecture
review board meeting in raleigh and took lots of arrows on.

the reference about keeping timing sync ... is somewhat related when
the telcos stopped letting customers have clear-channel T1 links and
required them to conform to the ones-density (and 193rd bit)
specification.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Terje Mathisen wrote:
> Ed Beroset wrote:
> 
> With my old telecomms classes 25+ years behind me, I still remember 
> enough to say that this looks like a classic queueing theory question. 
> Erlang to the resque. (But only if the same simplifications hold true!)

That's the way I'd approach it.

> Anyway, this is most definitely an engineering problem (at least at my 
> alma mater), not CS.

The problem was deliberately phrased as an engineering problem.  But of 
course in order to solve it, it's useful to know a little about queueing 
theory which is certainly in the domain of computer science.

That was my point.  It's just the same as using calculus in the service 
of solving engineering problems.  Calculus was invented by scientists, 
not engineers, but it happens to be extremely useful in engineering. 
Computer science is also useful in engineering, and in my experience, 
those who have studied computer science have been useful and productive 
members of programming teams I've worked with.

Ed

Ed Beroset wrote:
> Terje Mathisen wrote:
> 
>> Ed Beroset wrote:
>>
>> With my old telecomms classes 25+ years behind me, I still remember 
>> enough to say that this looks like a classic queueing theory question. 
>> Erlang to the resque. (But only if the same simplifications hold true!)
> 
> 
> That's the way I'd approach it.
> 
>> Anyway, this is most definitely an engineering problem (at least at my 
>> alma mater), not CS.
> 
> 
> The problem was deliberately phrased as an engineering problem.  But of 
> course in order to solve it, it's useful to know a little about queueing 
> theory which is certainly in the domain of computer science.

Huh?

AS I wrote above, this class (Erlang/Queuing theory) was taught only in 
the EE department, not CS. :-(
> 
> That was my point.  It's just the same as using calculus in the service 
> of solving engineering problems.  Calculus was invented by scientists, 
> not engineers, but it happens to be extremely useful in engineering. 

Most theoretical breakthroughs were made by scientists, that doesn't 
mean engineers won't use the results.

> Computer science is also useful in engineering, and in my experience, 
> those who have studied computer science have been useful and productive 
> members of programming teams I've worked with.

I never stated that they weren't useful/productive, only that in my 
personal experience the very best all happened to be engineers, not CS 
graduates.

Terje
PS. This _might_ be a sore spot for me, since I declined an offer to 
change from EE to CS for my major. :-)

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

In article <4hpPd.9995$oO.7854@newsread2.news.atl.earthlink.net>,
Ed Beroset  <beroset@mindspring.com> wrote:
>
>> I.e. producing ridiculously unrealistic designs and leaving all
>> the real work to someone else.
>
>By implying that design work is not "real work" you have just proved my 
>point.

If you had been following this group for even a short while, you
would realise how foolish that makes you look.  I don't believe that
anyone could believe that I would post such an implication, though
trolls would claim it - though I am NOT claiming you are a troll,
merely mistaken.

As every experienced designer, engineer and so on will know, there
is a world of difference between a "broad brush" outline and a precise
template.  One difference between a good designer and a bad one is that
the former's outlines can be developed into something practical, and
the latter's often can't.


Regards,
Nick Maclaren.

"s.subbarayan" wrote:

> Hi,
> Thanks for your reply.My inference from your reply is that better
> avoid using taskrestart when working on critical areas and use it only
> on noncritical tasks.
> But only one doubt reminds still to me:
> I agree that its not possible to resume a task,when it crashes.But
> when I restart it,How do we make sure that we are in synch with the
> current status of the application,the same dosage problem as stated in
> your posting?What if the task which is restarted requires a semaphore
> or a message which is held by some other task at the time of
> restarting?How do we make sure that the application reaches safely
> with out causing any trouble to the current situation?
>
> Regards,
> s.subbarayan

That is the problem unless you can make it work you can not use it.  There
may not be a safe way to restart a specific task.  It is your system so
you get to figure it out.  You may only be able to put the system in a
"safe" state if there is a problem.

prep@prep.synonet.com wrote:

> Neil Kurzman <nsk@mail.asb.com> writes:
>
> > 1. Crashing is always a software problem.  No input should cause the code to get lost.
>
> > 2. Restarting crashed task may be a bad Idea. For the Therac example
> > suppose the dose task dies. If you restart it does it try to give
> > another dose?  What if it keeps crashing and restarting. Can the
> > system figure out if the restart is helping or making it worse?
>
> THe Therac problem was that no one considered what would happen if the
> operator did an ABA type mode change with out waiting for either step
> to complete. The result was the real world was out of step with the
> software internal state. This negated the effect of the saftey checks.
>
> Although no input SHOULD cause a fault, and all Florida swampland
> should be wonderfull, in real systems there are some things where you
> need to act ASAP to prevent interesting times. Railway switching,
> BOS converter injection, plating power supplys to think of a quick few.
>
> It is not the system that figures out if a task is restarted or not, that
> is for the designer. The system just has to implement it.
>
> --
> Paul Repacholi                               1 Crescent Rd.,
> +61 (08) 9257-1001                           Kalamunda.
>                                              West Australia 6076
> comp.os.vms,- The Older, Grumpier Slashdot
> Raw, Cooked or Well-done, it's all half baked.
> EPIC, The Architecture of the future, always has been, always will be.

I agree the code must be good enough that it does not runaway, crash, or become confuse due
to bad input.
It should stop or recover.

Unlike my car.  An engine temperature sensor opened.  the computer decided it was very
cold.  It leaned the mixture till the head gasket blew.  It should have notice the engine
never got any warmer.  Unexpected states should always lead to safe behavior and/or blinking
lights and buzzers.

Terje Mathisen wrote:

> The packet gaps will most probably follow a Poisson distribution,

Poisson is unlikely to be a good model unless there are a large number 
of independant flows passing through the link.

Given the problem's parameters I'd expect only a few flows to be present.

The distribution of inter-packet gaps will depend on the behavior of the 
source, the sink, and on other factors such as the and-to-end round trip 
delay between the systems.

citeseer found a lot of possible papers on the topic.  this one
seems to be directly relevant:

http://www.cercs.gatech.edu/tech-reports/tr2004/git-cercs-04-09.pdf

and this looks like one of the first to say "hey, poisson doesn't fit":

http://www.cse.ohio-state.edu/~jain/papers/train.htm

						- Bill

Ed Beroset wrote:
> Del Cecchi wrote:
>> Ed Beroset wrote:
>>
>>> I have also noticed that the programmers from a computer science
>>> background tend to be much better at working out a system
>>> architecture and planning first.
> [...]
>>>
>> Those comp-sci geniuses are the ones that gave us a software
>> paradigm that is susceptible to attacks as simple as buffer
>> overruns, and store data in randomly scattered chunks linked by
>> pointers.   And put multiple unrelated locks in the same cache
>> line?  That the ones you are talking about?
> 
> It's interesting to learn that no engineers were ever involved in
> building such flaws.
> 
> My background happens to be more in the engineering than the
> computer science end of things, but I don't share your evident
> contempt for the field.  Here's an example:  An embedded
> communication system receives packet-based messages of varying
> lengths at an average rate of 100 packets per minute, but
> asynchronously.  Because the system also checks its timing
> against the recovered clock from the messages, which it can
> easily keep synchronized within limits as long as it doesn't go
> too long without receiving a packet.  What is the probability
> that no packets will arrive in an interval of five seconds?
> 
> I can answer that question easily because I've studied a little
> computer science.  Can you?  If not, how can you properly
> engineer the system?

If it's internal clock can't stay synchronized over 5 seconds, or
even much longer, I think there is something wrong with the
hardware design.  Of course you haven't defined synchronized.  I
certainly couldn't answer it, but I would know enough to hunt up
queueing theory, which is quite mature and predates computers. 
Whatever the synchronizing requires, I would attempt to put
something in the transmitter system to ensure satisfaction. 
Statistics can always burn you.

But you are asking the wrong question.  However, if you asked what
is the probability that 10 packets will arrive in 5 seconds, you
would have a good point.  Again, the place to look is queueing
theory.  I do know that the design is going to require some sort of
buffering, and if there is nothing else critical and resources are
pre-established I will assign as much buffer space as possible
(assuming no other similar requirements) and not bother with the
details.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Terje Mathisen wrote:
> Ed Beroset wrote:
> 
>> Terje Mathisen wrote:
>>
>>> Ed Beroset wrote:
>>>
>>> With my old telecomms classes 25+ years behind me, I still remember 
>>> enough to say that this looks like a classic queueing theory 
>>> question. Erlang to the resque. (But only if the same simplifications 
>>> hold true!)
>>
>>
>>
>> That's the way I'd approach it.
>>
>>> Anyway, this is most definitely an engineering problem (at least at 
>>> my alma mater), not CS.
>>
>>
>>
>> The problem was deliberately phrased as an engineering problem.  But 
>> of course in order to solve it, it's useful to know a little about 
>> queueing theory which is certainly in the domain of computer science.
> 
> 
> Huh?
> 
> AS I wrote above, this class (Erlang/Queuing theory) was taught only in 
> the EE department, not CS. :-(

A local university here teaches the same course under two different 
numbers in the catalog.  The only difference is that one is nominally in 
the CS department and the other in the EE department.  At least one of 
the books I've got on the subject was written by a university professor 
who works in the EE department.  It's still computer science.  The 
*application* of it is engineering.

>> That was my point.  It's just the same as using calculus in the 
>> service of solving engineering problems.  Calculus was invented by 
>> scientists, not engineers, but it happens to be extremely useful in 
>> engineering. 
> 
> Most theoretical breakthroughs were made by scientists, that doesn't 
> mean engineers won't use the results.

Of course.  We agree on that, and naturally engineers invent things all 
the time that are of use to scientists.

>> Computer science is also useful in engineering, and in my experience, 
>> those who have studied computer science have been useful and 
>> productive members of programming teams I've worked with.
> 
> I never stated that they weren't useful/productive, only that in my 
> personal experience the very best all happened to be engineers, not CS 
> graduates.

I wasn't disputing your observation.  I was just adding to it by noting, 
from my experience, what CS graduates tend to do better.  Others seemed 
to be implying that CS graduates are incapable of working usefully on 
embedded systems, hence my comment here.

> Terje
> PS. This _might_ be a sore spot for me, since I declined an offer to 
> change from EE to CS for my major. :-)

Evidently it's a sore spot for a lot of people!  I expect that will fade 
over time, in the same way that few people working in electrical 
engineering had EE degrees in the 1950's (because few universities had 
EE degree programs then).  I've hired people with no degree and people 
with PhDs in unrelated fields; what matters ultimately was whether they 
could do the job.

Adm. Grace Hopper had a PhD in mathematics.

Could she program?  ;-)

Ed

"Ed Beroset" <beroset@mindspring.com> wrote in message 
news:uvpPd.19360$wK.11885@newsread3.news.atl.earthlink.net...
> Del Cecchi wrote:
>> Ed Beroset wrote:
>>
>>> I have also noticed that the programmers from a computer science 
>>> background tend to be much better at working out a system architecture 
>>> and planning first.
> [...]
>>>
>> Those comp-sci geniuses are the ones that gave us a software paradigm 
>> that is susceptible to attacks as simple as buffer overruns, and store 
>> data in randomly scattered chunks linked by pointers.   And put multiple 
>> unrelated locks in the same cache line?  That the ones you are talking 
>> about?
>
> It's interesting to learn that no engineers were ever involved in building 
> such flaws.
>
> My background happens to be more in the engineering than the computer 
> science end of things, but I don't share your evident contempt for the 
> field.  Here's an example:  An embedded communication system receives 
> packet-based messages of varying lengths at an average rate of 100 packets 
> per minute, but asynchronously.  Because the system also checks its timing 
> against the recovered clock from the messages, which it can easily keep 
> synchronized within limits as long as it doesn't go too long without 
> receiving a packet.  What is the probability that no packets will arrive 
> in an interval of five seconds?
>
> I can answer that question easily because I've studied a little computer 
> science.  Can you?  If not, how can you properly engineer the system?


If you think you can answer it at all with the information given,
you are badly mistaken. Provide the rest of the needed information,
and I'll be glad to give you the answer.

-- 

  ... Hank

http://home.earthlink.net/~horedson
http://home.earthlink.net/~w0rli