Self restarting property of RTOS-How it works?

CBFalconer wrote:
> israel t wrote:
> 
>>"del cecchi" <dcecchi.nojunk@att.net> writes:
>>
>>
>>>Like hardware doesn't have bugs or "errata".  Go check Intel's
>>>web site.
>>
>>Or for an example of hardware errors in a mature industry,
>>consider the hundreds or thousands of car recalls that occur
>>globally each year.
> 
> 
> Reminds me of the last GM car I will ever own, which happened about
> 25 years ago.  Within the first 500 miles it had seized the front
> brakes (that took less than 10), destroyed a fan belt pulley (with
> no replacements in the parts stream, jury rigged with a weld.  Two
> months later they had a replacement pulley).  Within 10,000 miles a
> front door had literally fallen off.  By 60,000 miles the engine
> block was cracked due to a non-functional freeze plug (this was
> also due to a careless mechanic who changed the coolant to pure
> water in the summer while repairing the failed heater).
> 
You suffer from a misunderstanding.  Those things in the block of an 
engine are there to get the sand out when casting.  They are not there 
to protect the block from cracking if the coolant freezes.

So the plugs are artifacts of the manufacturing process and not idiot 
savers.  You didn't check the coolant in the fall?  In the days you 
refer to "25 years ago" it was customary to change coolant every fall. 
Probably even listed in the manual.  You do read manuals, right?

And even a honda or a mercedes will crack the block if the coolant is 
wrong.  GM had nothing to do with it.

Now about the 200 series transmission in my 77 Impala.....

del

In article <110puevs1jeju00@corp.supernews.com>,
Guy Macon  <_see.web.page_@_www.guymacon.com_> wrote:
>Nick Maclaren wrote:
>
>>!!!!  My experience is that they are generally CATASTROPHIC at that;
>>MUCH worse than even engineers :-(
>>
>>Oh, yes, they work out an 'architecture' and a 'plan', but it is
>>usually based on a completely unrealistic view of the world, where
>>nothing ever goes wrong and nobody ever makes a mistake.  The worst
>
>[snip]
>
>Nonsense.  You can't tar an entire class of people based on the
>worst examples.  And I say that as an engineer who knows enough to
>let the computer science fellows do what they do best.

A) I was not referring to the worst examples - I have seen much,
MUCH worse examples than that.

B) I did NOT tar the "entire class".  If you had not been so keen
on being snippy, you would have included (or at least read) the
paragraph where I said that there were exceptions, as well as
computer scientists who regret the situation.  And, incidentally,
the paragraph you quoted contained the little words "generally" and
"usually" - they mean something, you know.

C) I have considerable experience with dealing with such people,
in academia, commerce and elsewhere.  Some of my colleagues and ex
colleagues have been among the best - but are YOU prepared to justify
the design of the X Windowing System, to take one prime example of
what I was referring to?

On the last point, the kindest thing that can be said about its
software engineering is that it was never intended to be used in a
commercial production context.


Regards,
Nick Maclaren.

Nick Maclaren wrote:

>but are YOU prepared to justify the design of the X Windowing 
>System, to take one prime example of what I was referring to?

What part of comp.arch.EMBEDDED are you having trouble understanding?
                       ^^^^^^^^
What part of RTOS are you having trouble understanding?
             ^^^^

Nick Maclaren wrote:
> In article <Kw1Pd.9131$oO.4160@newsread2.news.atl.earthlink.net>,
> Ed Beroset <beroset@mindspring.com> writes:
> |> Terje Mathisen wrote:
> |> > 
> |> > I have noted previously here in c.a that most of the _really_ good 
> |> > low-level/systems programmers I know seem to have an engineering instead 
> |> > of computer science background.
> |> > 
> |> > A coincidence?
> |> 
> |> 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.
> 
> !!!!  My experience is that they are generally CATASTROPHIC at that;
> MUCH worse than even engineers :-(
> 
> Oh, yes, they work out an 'architecture' and a 'plan', but it is
> usually based on a completely unrealistic view of the world, where
> nothing ever goes wrong and nobody ever makes a mistake.  The worst
> fault is usually that they regard it as reasonable to omit all error
> recovery, diagnosis and robustness, and claim that going bananas is
> a perfectly reasonable response to a natural human error.

There is no substitute for hiring competent people, no matter what their 
background.

> 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.

Ed

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?

Ed

i have used their milia treatment for milia seed on my eye brown area
and below cheek. after three applications, i noticed a reduction in the
milia size, quite impressed as i thought only laser surgery can solve
my problem.
--------------------------------
zest_f...@yahoo.com
i keep seeing reviews and raves about this
http://www.naturalisproducts.com and http://www.organiconline.com.sg .
many people are discussing in beauty forums and magazines have positive
reviews on this . but this thing ain't new, its been around for many
years! anyone tried can feedback to me on exactly how good it is?

----------------------------------------
can anyone help me please, am looking for the local distributor or any
shop selling the naturalis range of skin and body care products, from
this company http://www.naturalisproducts.com . looking for this
urgently. for those who have not come across it, its some foodbased
anti-aging products. i googled for this and received result showing its
available at http://www.organiconline.com.sg. i need this
urgently but shipping from singapore will take some time, if anyone is
distributing this please contact me at g...@raterenterprise.com
urgently. i have a group of us looking to buy this. thanks!

"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?
>
> Ed
Well, first I would want to know the average utilization of the link.
Then I would want to know the distribution of the lengths of the
packets, and the distribution of the rate at which they are sent.  If
the distribution is that the utilization is 0.1 percent and the packets
are all sent once a minute by a batching system then the probability is
100 percent.  On the other hand if the utilization is 99.9 percent and
the distribution is uniform, then the probability is very low.

Yes, I too have studied some computer science.  The first time I saw
some of the algorithms, and the scheme language, I almost plotzed.

del cecchi
>

Ed Beroset wrote:

> 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?

Hm, I could make some assumptions about the statistical properties of those
"100 packets per minute", but simple assumptions can be quite wrong. If I
have a web server, and I get 100 requests per minute, I expect the traffic
to be shaped over the day, and that the likelyhood to receive a single
packet between 3 and 5am of my target audience is quite low, while there'll
be several high-activity spots during the day. That means a simply random
distribution of the packets is not sufficient to give you the worst case.

At least on my most popular German page, the access frequency drops down to
one tenth of the typical day use between 2 and 6am. The traffic during the
day is pretty flat, though, about one hit per minute. During late night,
there are only about five per hour.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Ed Beroset wrote:
> Del Cecchi wrote:
> It's interesting to learn that no engineers were ever involved in 
> building such flaws.

Of course they were! All professions make mistakes, only in some fields 
the consequences are more severe, and the cost of fixing it much higher.
> 
> 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?

Not enough info!

a) What is the packet arrival time distribution? Should we make the 
assumptions as for a many independent producers, or does the chance of 
generating a new packet increase as a function of the time since the last?

a) What is the average packet length (in milliseconds)? This is of 
course needed to be able to calculate the average and expected gap lengths.
> 
> 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?

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!)

The packet gaps will most probably follow a Poisson distribution, with 
just ~1.6 packets/second on average, the chance of a 5 second gap never 
happening seems pretty bad, i.e. this would be bad engineering.

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

Terje

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

del cecchi wrote:
> "Ed Beroset" <beroset@mindspring.com> wrote in message

>>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.  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?
> 
> Well, first I would want to know the average utilization of the link.
> Then I would want to know the distribution of the lengths of the
> packets, and the distribution of the rate at which they are sent.  If
> the distribution is that the utilization is 0.1 percent and the packets
> are all sent once a minute by a batching system then the probability is
> 100 percent.  On the other hand if the utilization is 99.9 percent and
> the distribution is uniform, then the probability is very low.

So you've got the answer narrowed down to somewhere between "very low" 
and 100%?  Impressive work.  ;-)

Ed