Leaving Dell Dimension 8300 running 24/7 ...?

[Sparky]

Ah! UPS. I read it as ups's as in ups and downs. I assumed you were
talking about supply fluctuations.

We don't need UPS. All the computer rooms and most of the offices are
on very stable supplies. Mean time between fails is years. Even the
domestic supply that my home PCs are on hardly ever fails. I can only
remember one fail in the last few years.

Well bless your blessed location! Locally we had a blackout 2 summers
ago and an electrical failure the summer before after a thunderstorm
(NYC area). IIRC the blackout hit about 5 PM and we didn't get the
traffic lights back on or cable service restored until about 6 AM the
next day. Regular household service flickered a couple of times, but
never went out.

 

[Sparky]

;->
I bet you'd still rather do that than write VBscript, though.
I know I would

Actually, I'd prefer to write a REXX script; but that's an entirely
different smoke.

 

[Thomas G. Marshall]

w_tom coughed up:

....[rip]...

Once we apply numbers to the concept, then thermal stress
during powerup is virtually zero.

"junk science" as you put it also makes a rash assumption that numbers by
themselves mean something. Numbers and facts in general are *only as good*
as their interpretation.

*AND* numbers and concepts do not come close to being as important as actual
observations are. Steve has observed over time many machines that on/off
machines fair much worse than the 24/7 machines do.

I still don't see an answer from you resolving this.

....[rip]...

 

[Thomas G. Marshall]

User N coughed up:

"Thomas G. Marshall"

User N coughed up:

You seem to want a "AV" scans to be performed every day.
Specifically, what "AV" software are you referring to? Is it
something that lacks the ability to automatically scan on an as
needed basis? For example, when the filesystem opens [or
closes] files?

As I said in the original post, it is NAV2003.

Oh, so that is the only thing you'll be scanning with on a daily
basis?

Don't know yet. I routinely scan with AVG as well.

If so, I'd be interested to know why you feel it is
necessary to perform full NAV2003 scans every day.

I can only assume that the retention on your news server is less than 2 or 3
days, which is very unfortunate for you. The line of my thinking is in my
original post. I am not sure of any of this, so don't pretend that I have a
strict opinion one way or the other----that is the reason for this thread in
the first place.

The fundamental reasons for me wanting more than a week scan is that an old
and well known trojan slipped right through the auto-protect, but was caught
on the scan. I am considering placing more of a burden on the scanning for
this reason.

 

[Dave Budd]

observations are. Steve has observed over time many machines that on/off
machines fair much worse than the 24/7 machines do.

otoh, he has many more on/off to observe, iirc: the pool sizes
are very different.
having done some stats, i can say that you can't judge from the
absolute numbers, or the ones you get by dividing by the sizes
of the two pools: it's more complicated than that.
it does give you a good first estimate though

 

[w_tom]

We gave him a newspaper article from the tabloid. He read
it and drew an obvious conclusion. We then provided the same
story from a NY Times, Washington Post, or WSJ type
newspaper. Much longer article with those underlying details
created an obvious 180 degrees different conclusion. That is
the point. The 'leave it on' theory does not provide details
and even contains contrarian facts. IOW if it was accurate,
then we must also recommend leaving on the TV, radio,
incandescent light bulbs, and CRT.

Why do they not recommend leaving a CRT on? After all,
power up inside a CRT means much higher voltage changes, and
many times higher temperature changes. Clearly if anything
was more susceptible to power on stress, it is the CRT. And
yet the same conclusion that says 'leave a computer on' also
says power off the CRT?

Reasons for this contradiction would be found in missing
details. For example some possible missing details: a
location with 2000 computers use newer Dell computers and not
any clones? Clones, both by example and for reasons
technical, have a greater failure rate. Is the building AC
power delivered properly earthed? How utilities enter a
building also will significantly affect hardware life
expectancy. So the 2000 'always left on' computers were also
in a newer steel and concrete building with properly earthed
utilities? Even the building can affect hardware life
expectancy. How much does the new equipment sleep? Then it
is really power cycling. Extending hardware life expectancy
by doing frequent power reductions and yet *assumed* to be
always on. These missing details are damning to the
observation.

Once we looked at actual failure rates considering other
variables such as quality of manufacturer, age of equipment,
how building was constructed, what actually failed, energy
star actions, and human biases, then with all things being
equal, we discovered no measurable difference but lots of
consumed electricity. The repair people just felt they were
spending less time repairing when systems were left on. They
had just observed without numbers and without the essential
details - and just knew.

Why did they not recommend leaving powered TVs, radios,
light bulbs, and the CRT? Clearly if an observation alone is
sufficient, then leaving powered all other electronics
including that CRT must be recommended. Why the
contradiction? Once underlying details were examined, such as
how things fail and what really does fail, then those 'leave
it on' observations fall apart mostly as examples of human
bias and problems created by not understanding underlying
concepts.

He made a 180 degree different conclusion once he read
details in that non-tabloid newspaper. And that is the
point. We have seen for decades that 'leaving it on' does not
preserve life expectancy once we consider the details. We see
obtain same in manufacturer data sheets. And yet, on a simple
observation without the always necessary details, one can
contradict decades of experience and published technical
numbers? Again the damning point. If leaving computers
'always powered' extends their life expectancy, then it must
also do same for TVs, radios, light bulbs, and CRTs. Why do
they not recommend leaving powered a CRT that would suffer (if
it exists) even greater from 'power on stress'? This last
sentence alone is damning. And again, the answer is found in
missing details.

Observations without both underlying concepts, numbers, and
without essential details from each example make that
observation nothing more than speculation. The concept of
'leave it on' is not justified, repeatedly, once we have those
details. The concept of 'leave it on' flies contrary to
decades of technical facts. What is missing in his example?
The numbers - important details. Provided was only a personal
observation without the always necessary facts and numbers -
the details.

Provided in a previous post were details about UPSes. IOW
those details demonstrate that plug-in UPSes (and filters, et
al) do nothing for hardware life expectancy ... if the
hardware is properly constructed to meet industry standards.
Again, many also claim improved life expectancy from a UPS
using the same observation only technique. Using observation
alone, they obtain junk science conclusions.

Without those essential and missing details, they obtained a
180 degree different conclusion. Observations alone are never
sufficient for facts. Never. Observations alone are
sufficient for speculation. Observations without "numbers and
concepts" create junk science conclusions.

"junk science" as you put it also makes a rash assumption that
numbers by themselves mean something. Numbers and facts in
general are *only as good* as their interpretation.

*AND* numbers and concepts do not come close to being as important
as actual observations are. Steve has observed over time many
machines that on/off machines fair much worse than the 24/7
machines do.

I still don't see an answer from you resolving this.

...[rip]...

 

[Roger Wilco]

A very embarrassing question is asked. What is the
component overstressed by powerup? And don't forget to
provide the numbers.

Feed-throughs (in case you don't know, that is part of a circuit board).
I didn't say component failure of solid state devices, I said parts that
were otherwise considered non-moving parts. Hell - semiconductors can
fail for no reason just sitting in a parts bin - and yet to some extent
temperature (or sometimes heat) can damage them. The non-moving parts I
referred to are not actually stressed (you said stressed, not I) they
are fatigued. And as to the topic of powerup itself, it is not the
weight (stress) it's the reps (reference to weightlifting there).

Sorry, no numbers - just facts.

 

[Ben Myers]

This is now a thread that is running 24/7. ... Ben Myers

 

[Thomas G. Marshall]

Dave Budd coughed up:

otoh, he has many more on/off to observe, iirc: the pool sizes
are very different.
having done some stats, i can say that you can't judge from the
absolute numbers, or the ones you get by dividing by the sizes
of the two pools: it's more complicated than that.
it does give you a good first estimate though

Correct. At this point, and with this issue, I'll take anything that is
based upon unbiased population domains.

 

[Thomas G. Marshall]

w_tom coughed up:

"junk science" as you put it also makes a rash assumption that
numbers by themselves mean something. Numbers and facts in
general are *only as good* as their interpretation.

*AND* numbers and concepts do not come close to being as important
as actual observations are. Steve has observed over time many
machines that on/off machines fair much worse than the 24/7
machines do.

I still don't see an answer from you resolving this.

....[rip]...

Reasons for this contradiction would be found in missing
details. For example some possible missing details: a
location with 2000 computers use newer Dell computers and not
any clones? Clones, both by example and for reasons
technical, have a greater failure rate. Is the building AC
power delivered properly earthed? How utilities enter a
building also will significantly affect hardware life
expectancy. So the 2000 'always left on' computers were also
in a newer steel and concrete building with properly earthed
utilities? Even the building can affect hardware life
expectancy. How much does the new equipment sleep? Then it
is really power cycling. Extending hardware life expectancy
by doing frequent power reductions and yet *assumed* to be
always on. These missing details are damning to the
observation.

Not "damning", it just makes the observation less (or un-) supported:
Damning means full contradiction---it is not strong enough to fully
contradict it yet.

Good. You have /now/ given me what I've been asking for: a rationale that
explains steve's observations. Your prior suppositions on miscategorizing
the failures found did not address his observations at all.

The next step is to evaluate your rationale. Perhaps we can decide one way
or the other soon. But probably not, since this has been regarded by others
already as a never ending debate.

....[rip]...

Without those essential and missing details, they obtained a
180 degree different conclusion. Observations alone are never
sufficient for facts.

Cart before the horse. Facts are derived from observations. And facts
themselves are of no use as such. Facts /require/ interpretation. And the
interpretation is what is most often argued about.

Never. Observations alone are
sufficient for speculation. Observations without "numbers and
concepts" create junk science conclusions.

Again, cart before the horse. The observations include the numbers (as
measurements), and then form the concepts. The only time this is reversed
is when the concept is first, and then it is a hypothetical.

We're spinning in circles on this one. I'll not argue this detail any
longer, since I couldn't care less about it. I am more interested in
analyzing the possible reasons you've given for steve's observations not
indicating 24/7 as the winner. /That/ is what's important. /That/ is what
will help iron out the debate.

 

[User N]

User N coughed up:

I can only assume that the retention on your news server is less than 2 or 3
days, which is very unfortunate for you. The line of my thinking is in my
original post.

FWIW, Giganews retention is pretty good... over a year in text groups.
Please forgive me for the additional questions. You did mention that
you'd be scanning with NAV2003 and communicate that it only picked
up on the byte verify threat during a full scan. But alot of people utilize
multiple anti-malware tools and some choose to perform full scans for
other reasons (like they haven't figured out how to prevent their SO
from disabling real-time protection when it gets in his or her way).

The fundamental reasons for me wanting more than a week scan is that an old
and well known trojan slipped right through the auto-protect, but was caught
on the scan. I am considering placing more of a burden on the scanning for
this reason.

FWIW, I use AVG and I've seen the same thing. I'm not terribly surprised.
I believe the most common/generic approach to real-time scanning is to
hook into the filesystem and scan when a file is opened. If a program just
downloads an object into memory, or saves it to a new file and accesses it
without closing and reopening the file, the real-time scanner won't be able to
catch it at that time.

AVG, at least, supports an "on-close scan" option (off by default I believe).
Given the name and all, I suspect it simply triggers the scanning engine
when files are closed. There would be more overhead (twice the scanning
one would think) and it wouldn't seem to prevent any attacks (I believe
they say it won't make you any safer), but it should automatically catch bad
files earlier (ie before they are caught by a subsequent open or full scan).

There are other ways to achieve real-time scanning. For example, via
network proxies and hooking into the applications that download things.
I'm not familiar with all the features that are available with the various
desktop anti-malware tools. But I believe I've come across solutions
that offer real-time scanning for malicious applets, javascripts, etc. If
the idea of catching things *before* they can infect your system appeals
to you (full scans are of relatively little use in terms of prevention), you
might shop around.

 

[w_tom]

The manufacturer so undersized a fuse that in a warm room,
the fuse would blow. That is proof that heat causes failure?
No, that is proof that the design is defective. The observer
may blame heat only because he first did not learn facts ...
the underlying details.

Feedthroughs fail due to trivial thermal cycling? You would
accept this as an example of how thermal cycling is so
destructive? Again, it is a manufacturing defect so heinous
that it must not exist with any computer model. Am I to
assume this is the reasoning that also promotes the myths
about power cycling being destructive? Feedthroughs fail due
to thermal cycling? That was not acceptable even 30 years
ago.

If your solution to PC board feedthrough problems is to
avoid trivial thermal cycles - to always leave a computer on -
then I also have an East River bridge I can sell you. That
feedthrough is not - by any means - an example of a component
overstressed by powerup. It is a classic example of a
manufacturer with a very seriously defective product - or an
isolated and extremely rare failure.

But again, what is this component rumored to be harmed by
thermal cycling?

 

[w_tom]

Actually we are not spinning wheels. For example, we
finally have someone willing to suggest a details. That
thermal cycling caused PC board feedthrough failures. That
detail says thermal cycling (again) did not cause the
problem. The problem is directly traceable to a manufacturing
defect that must not exist in any electronics. Power cycling
got blamed only when an observer saw a failure, then
speculated without sufficient facts: blamed failure on thermal
cycling.

Notice how those who speculated power cycling was so
destructive are no longer defending that claim - once we
demand underlying details. IOW we are making great progress
as myths are replaced by silence. Why? Underlying reasons
for 'rumored to be destructive' power cycling do not exist.

IOW observation - that the computer failed due to power
cycling - was found erroneous once we add underlying details.
Why did the feedthrough fail? Is the computer manufacturer
that deficient? Or is the computer owner a bean counter type
that uses only one number - price - to make decisions? Either
way, defects aggrevated and exposed by thermal cycling say the
defect is due to other completely different reasons.
Observation alone (again) would not be sufficient to learn
that conclusions. But once we have underlying facts - that
feedthrough failed - then we know power cycling was not the
reason for failure. Power cycling only exposed symptoms of
another completely different problem.

Still waiting for someone to provide components that would
be damaged by power up. Many were willing to post when it was
speculation: power cycling is so destructive. Now that we are
down to the reasons why, the responses are 'thread bare'. And
that is the point. Those who claim power cycling is so
destructive don't learn the whys - they only speculate. IOW
they are easily deceived by the myths of power cycling rather
than acutally learn facts. Again, what component is being
damaged by power cycling?

....
Good. You have /now/ given me what I've been asking for: a
rationale that explains steve's observations. Your prior
suppositions on miscategorizing the failures found did not
address his observations at all.

The next step is to evaluate your rationale. Perhaps we can
decide one way or the other soon. But probably not, since this
has been regarded by others already as a never ending debate.

...[rip]...

w_tom coughed up:

Without those essential and missing details, they obtained a
180 degree different conclusion. Observations alone are never
sufficient for facts.

Cart before the horse. Facts are derived from observations. And
facts themselves are of no use as such. Facts /require/
interpretation. And the interpretation is what is most often
argued about.

Never. Observations alone are sufficient for speculation.
Observations without "numbers and concepts" create junk
science conclusions.

Again, cart before the horse. The observations include the
numbers (as measurements), and then form the concepts. The only
time this is reversed is when the concept is first, and then it
is a hypothetical.

We're spinning in circles on this one. I'll not argue this detail
any longer, since I couldn't care less about it. I am more
interested in analyzing the possible reasons you've given for
steve's observations not indicating 24/7 as the winner. /That/
is what's important. /That/ is what will help iron out the debate.

 

[Thomas G. Marshall]

w_tom coughed up:

....
Good. You have /now/ given me what I've been asking for: a
rationale that explains steve's observations. Your prior
suppositions on miscategorizing the failures found did not
address his observations at all.

The next step is to evaluate your rationale. Perhaps we can
decide one way or the other soon. But probably not, since this
has been regarded by others already as a never ending debate.

...[rip]...

w_tom coughed up:

Without those essential and missing details, they obtained a
180 degree different conclusion. Observations alone are never
sufficient for facts.

Cart before the horse. Facts are derived from observations. And
facts themselves are of no use as such. Facts /require/
interpretation. And the interpretation is what is most often
argued about.

Never. Observations alone are sufficient for speculation.
Observations without "numbers and concepts" create junk
science conclusions.

Again, cart before the horse. The observations include the
numbers (as measurements), and then form the concepts. The only
time this is reversed is when the concept is first, and then it
is a hypothetical.

We're spinning in circles on this one. I'll not argue this detail
any longer, since I couldn't care less about it. I am more
interested in analyzing the possible reasons you've given for
steve's observations not indicating 24/7 as the winner. /That/
is what's important. /That/ is what will help iron out the debate.

Actually we are not spinning wheels. For example, we
finally have someone willing to suggest a details.

No, the spinning I was talking about has to do with the notion of concepts
vs. numbers vs. facts vs. observations. I'm not interested in that.

That
thermal cycling caused PC board feedthrough failures. That
detail says thermal cycling (again) did not cause the
problem. The problem is directly traceable to a manufacturing
defect that must not exist in any electronics. Power cycling
got blamed only when an observer saw a failure, then
speculated without sufficient facts: blamed failure on thermal
cycling.

Notice how those who speculated power cycling was so
destructive are no longer defending that claim - once we
demand underlying details. IOW we are making great progress
as myths are replaced by silence. Why? Underlying reasons
for 'rumored to be destructive' power cycling do not exist.

IOW observation - that the computer failed due to power
cycling - was found erroneous once we add underlying details.

No. Now I see where the spinning takes place. What you are referring to as
observation is /conclusion/. The observation is the failed computer.

....[rip]...


--
I've seen this a few times---Don't make this mistake:

Dwight: "This thing is wildly available."
Smedly: "Did you mean wildly, or /widely/ ?"
Dwight: "Both!", said while nodding emphatically.

Dwight was exposed to have made a grammatical
error and tries to cover it up by thinking
fast. This is so painfully obvious that he
only succeeds in looking worse.

 

[Thomas G. Marshall]

w_tom coughed up:

The manufacturer so undersized a fuse that in a warm room,
the fuse would blow.

....[rip]...


w_tom, *please* do not top post after others have bottom posted. It makes
it impossible to reply to with an interleaved-posting style, and makes the
conversation a headache to follow.

 

[Roger Wilco]

Actually we are not spinning wheels. For example, we
finally have someone willing to suggest a details. That
thermal cycling caused PC board feedthrough failures. That
detail says thermal cycling (again) did not cause the
problem. The problem is directly traceable to a manufacturing
defect that must not exist in any electronics.

You sound like an engineer who has never had to repair anything.

The engineering and the manufacturing process is designed to increase
the mean time between failures and if it were possible to eliminate the
causes of failures. You sound like the ol' "I didn't kill him - I pushed
him off the cliff, the fall killed him - no it didn't it was the sudden
stop at the end of the fall...no, it was the fact that not all parts of
him decelerated together equally that caused tearing of
tissue....etc...."

Power cycling
got blamed only when an observer saw a failure, then
speculated without sufficient facts: blamed failure on thermal
cycling.

Components mounted above board (not flush mounted) are supposed to have
(in many cases) their leads bent to absorb the repeated stress (and
hence fatigue) that thermal cycling would otherwise produce. We're
talking about quality products here and so it may not really matter if
the device is always on or cycled. I am merely pointing out that the
thermal fatigue scenario is real and not imagined (and yes, it applies
to radios and televisions too - not too sure about the light bulbs
though.

Notice how those who speculated power cycling was so
destructive are no longer defending that claim - once we
demand underlying details. IOW we are making great progress
as myths are replaced by silence. Why? Underlying reasons
for 'rumored to be destructive' power cycling do not exist.

You can interpret the silence any way that soothes your ego, but it is
often the case that other may tire of attempting to educate some peeps.

IOW observation - that the computer failed due to power
cycling - was found erroneous once we add underlying details.
Why did the feedthrough fail? Is the computer manufacturer
that deficient? Or is the computer owner a bean counter type
that uses only one number - price - to make decisions? Either
way, defects aggrevated and exposed by thermal cycling say the
defect is due to other completely different reasons.
Observation alone (again) would not be sufficient to learn
that conclusions. But once we have underlying facts - that
feedthrough failed - then we know power cycling was not the
reason for failure. Power cycling only exposed symptoms of
another completely different problem.

Right - if it failed - it was broken. \

Still waiting for someone to provide components that would
be damaged by power up.

Power switches are designed to operate through thousands of
repetitions - but they will eventually wear out. The more you use them
the more wear they get. Same goes for relay contacts. Repetitive stress
disorders like carpal tunnel syndrome aren't caused by repetitive
stress - they are design flaws.

Many were willing to post when it was
speculation: power cycling is so destructive. Now that we are
down to the reasons why, the responses are 'thread bare'.
Nice!

And
that is the point. Those who claim power cycling is so
destructive don't learn the whys - they only speculate. IOW
they are easily deceived by the myths of power cycling rather
than acutally learn facts. Again, what component is being
damaged by power cycling?

The "wear" part of "normal wear and tear" is increased on some
components by this - while other components may see decreased wear by
it. Overall, it probably doesn't matter either way in most high quality
modern computers.

 

[Roger Wilco]

The manufacturer so undersized a fuse that in a warm room,
the fuse would blow. That is proof that heat causes failure?

Thermal fuses are designed to open (fail?) when a current results in a
certain temperature melting the link or increasing the tension
(slow-blow) to the point of breakage. The "failure" of the fuse is what
prevents the possible failure of the circuit the fuse delivered the load
current to. So - yes heat (actually temperature) does cause failure.

No, that is proof that the design is defective.

No, the failure was BY design and worked flawlessly (the fuse failed at
the temperature it was designed to fail at). They could have just as
easily forgot that a slow blow type of fuse was needed to allow the
surge of initial powerup to not result in the requisite temperature
being reached to soon (allow transient temperature overages while
persistent overages cause failure). Back on point - many slow blow fuses
have a "heater" element and a bi-metal strip that when heated to a
certain temperature increases tension to the point of failure (but not
instantaneously) - after repeated cycling the bi-metal strip becomes
fatigued and a lack of failure results. Luckily there is usually an
instantaneous fuse link that fails at a slightly higher temp also
incorporated as failsafe. You've probably seen these - thin metal strip,
a bead, a bi-metal coiled strip all in one package.

The observer
may blame heat only because he first did not learn facts ...
the underlying details.

Yes, I do see what you are saying and it is not incorrect in my
assessment (considering we are not talking theory but practice). I have
been involved in the electronics industry for many years and you will
not convince me that thermal expansion/contraction problems are a thing
of the past only.

Feedthroughs fail due to trivial thermal cycling? You would
accept this as an example of how thermal cycling is so
destructive? Again, it is a manufacturing defect so heinous
that it must not exist with any computer model. Am I to
assume this is the reasoning that also promotes the myths
about power cycling being destructive? Feedthroughs fail due
to thermal cycling? That was not acceptable even 30 years
ago.

Steps have been taken to reduce the effect of fatigue on MTBF, that does
not mean it doesn't exist. It might not be an important consideration
for a complex electro-mechanical device that has other issues related to
"always on" wear.

If your solution to PC board feedthrough problems is to
avoid trivial thermal cycles - to always leave a computer on -
then I also have an East River bridge I can sell you.

I never suggested such a thing, I countered your insistence that it is a
myth. I made no claims about any "always-on" scenario being better or
worse for any individual components. Your car suffers more wear during
startup than most any other time - that does not mean I suggest leaving
it running all night in the garage. If you said the car startup wear was
a myth then I would counter point.

That
feedthrough is not - by any means - an example of a component
overstressed by powerup. It is a classic example of a
manufacturer with a very seriously defective product - or an
isolated and extremely rare failure.

It was just one example of expansion/contraction wear. Mounting screws,
plugs & sockets, heatsinks, risers - many things are affected by this
motion and we have yet to design them completely out.

But again, what is this component rumored to be harmed by
thermal cycling?

What is this fixation you have for components? It is what is in-between
these components (what connects them) that is most affected. A physical
trait of dissimilar materials is that they expand and contract with
temperature with differing amounts even though they are physically
connected (and often rigidly).

 

[Sparky]

You sound like an engineer who has never had to repair anything.

The engineering and the manufacturing process is designed to increase
the mean time between failures and if it were possible to eliminate the
causes of failures. You sound like the ol' "I didn't kill him - I pushed
him off the cliff, the fall killed him - no it didn't it was the sudden
stop at the end of the fall...no, it was the fact that not all parts of
him decelerated together equally that caused tearing of
tissue....etc...."

You omitted: "He was dead when I got here - I was just going thru his
pockets looking for loose change".

 

[Sparky]

w_tom coughed up:

The manufacturer so undersized a fuse that in a warm room,
the fuse would blow.

...[rip]...

w_tom, *please* do not top post after others have bottom posted. It makes
it impossible to reply to with an interleaved-posting style, and makes the
conversation a headache to follow.

You're still trying to follow this???

 

[Sparky]

And we powered down our GE-225 computer every night back in the '60s, unless I
was working around the clock doing some programming.

Maybe GE's were designed to handle the power off/power on sequence
better than the IBM iron? After all, they "bring good things to life".