How can hardware monitoring software help???
Straight_Man
Geeky, in my own wayNaples, FL Icrontian
First, I manage computers by exception for the most part. What does MBE have to do with hardware??? First, things wear out that are physical, like bearings on HD spindles. Second, too much heat, and you get the good -- for computers read this as best resistive and best conductive-- materials reacting with the impurities in them. Thus you get changes over time, inevitably. LOGGING the values lets you see changes, and the ones that change over increasingly shorter times let you see what area (based on sensor location and what sensor is sensing) of computer is changing fastest and needs to be fixed.
IF a software fix does not fix what could be a hardware failure, and this is so repetitively, you can then concentrate or drill logically down into hardware subsystem that is likely to be cause of problem. And the hardware monitoring values can help tell you what is up when you use symptom sets and what you were doing also (what piece of computer as far as functional subsystem you were using at same time as what could be a hardware fault happened). If hardware values are stable for that subsystem, more likely to be mostly software at at fault at that time.
MBE is attacking what is out of acceptable range first. Knowing hardware subsystems and major components and how they inter-react with monitor software lets you discriminate between hard and soft errors better, and exception typing trends let you see what is likely to be wrong in hardware and tell if the thing is a hardware thing or a software thing. Looking for trends is why I ask seemingly unrelated questions or bring up seemingly unrelated to thread topic ideas, because many faults of soft kind or many KINDS of soft faults related to one piece of hardware lead me to look more at hardware than software.
IF I see many threads of soft faults, or extreme things, I tend to more and more think hardware and will address the thread starter if it his box to look at that seemingly topic irrelevant hardware thing becasue he is monitoring the thread for ideas, and issue is to fix box or make it more usuable from my POV.
I am deliberately skimming the surface here, to see if folks want to discuss how you can go from global or isolated symptom sets and see what is really the underlying cause of issues (exceptions from what is wanted) in some cases. I could PM, but an unknown to user with problem person is likely to have to spend aover half the communication justifying his logic-- that is why posts are so long, to teach both user with trouble and to leave some ideas for others searching for answers-- keeping old threads forms a knowledge archive, and knowledge lets you drill down faster if you can apply theory to how things interreact with some knowledge of how your system works for you.
One way to do this, is to apply knowledge of hardware symptoms and when and what diagnostics are appropriate and what has been common in computers for a long time. Many times fast hardware diagnostics tell you that software is problem-- they tell you hardware hardware is not failing in worst result case. They can also give you clues that can tell you if you need to concentrate on hardware if they show exceptions from what is right. Ruling out things that could be relevant hardware-wise leaves you with what is left-- software. Vice versa also applies here. If problems but no soft solution except an extreme one works, consider hardware faults.
John D-- who wants to provoke thinking and not flames.
IF a software fix does not fix what could be a hardware failure, and this is so repetitively, you can then concentrate or drill logically down into hardware subsystem that is likely to be cause of problem. And the hardware monitoring values can help tell you what is up when you use symptom sets and what you were doing also (what piece of computer as far as functional subsystem you were using at same time as what could be a hardware fault happened). If hardware values are stable for that subsystem, more likely to be mostly software at at fault at that time.
MBE is attacking what is out of acceptable range first. Knowing hardware subsystems and major components and how they inter-react with monitor software lets you discriminate between hard and soft errors better, and exception typing trends let you see what is likely to be wrong in hardware and tell if the thing is a hardware thing or a software thing. Looking for trends is why I ask seemingly unrelated questions or bring up seemingly unrelated to thread topic ideas, because many faults of soft kind or many KINDS of soft faults related to one piece of hardware lead me to look more at hardware than software.
IF I see many threads of soft faults, or extreme things, I tend to more and more think hardware and will address the thread starter if it his box to look at that seemingly topic irrelevant hardware thing becasue he is monitoring the thread for ideas, and issue is to fix box or make it more usuable from my POV.
I am deliberately skimming the surface here, to see if folks want to discuss how you can go from global or isolated symptom sets and see what is really the underlying cause of issues (exceptions from what is wanted) in some cases. I could PM, but an unknown to user with problem person is likely to have to spend aover half the communication justifying his logic-- that is why posts are so long, to teach both user with trouble and to leave some ideas for others searching for answers-- keeping old threads forms a knowledge archive, and knowledge lets you drill down faster if you can apply theory to how things interreact with some knowledge of how your system works for you.
One way to do this, is to apply knowledge of hardware symptoms and when and what diagnostics are appropriate and what has been common in computers for a long time. Many times fast hardware diagnostics tell you that software is problem-- they tell you hardware hardware is not failing in worst result case. They can also give you clues that can tell you if you need to concentrate on hardware if they show exceptions from what is right. Ruling out things that could be relevant hardware-wise leaves you with what is left-- software. Vice versa also applies here. If problems but no soft solution except an extreme one works, consider hardware faults.
John D-- who wants to provoke thinking and not flames.
0