Quote:
Originally Posted by Welshchris
Whats the point of testing a good modem when they should be testing one with a fault, kind of defeats the object lol  |
Interests Computer Hardware
Occupation IT Tech
As you're quite nocturnal unsure if you're between jobs at the moment but if you aren't I kinda hope you don't work in a support role as
troubleshooting doesn't appear to be your strong suit.
Quote:
|
Troubleshooting is a form of problem solving most often applied to repair of failed products or processes. It is a logical, systematic search for the source of a problem so that it can be solved, and so the product or process can be made operational again. Troubleshooting is needed to develop and maintain complex systems where the symptoms of a problem can have many possible causes. Troubleshooting is used in many fields such as engineering, system administration, electronics, automotive repair, and diagnostic medicine. Troubleshooting requires identification of the malfunction(s) or symptoms within a system. Then, experience is commonly used to generate possible causes of the symptoms. Determining which cause is most likely is often a process of elimination - eliminating potential causes of a problem. Finally, troubleshooting requires confirmation that the solution restores the product or process to its working state.
|
Using a known good modem eliminates the modem as a cause, plugging the modem basically straight into a CMTS eliminates HFC leaving only CMTS and associated software / hardware. If fault cannot be replicated CMTS as a stand-alone root cause eliminated and search for a trigger for the fault from HFC layer begins.
Translating this into your interest of computer hardware if a PC doesn't boot and doesn't give much clue why you either change the components out for known good ones, one at a time, until it does boot or remove unnecessary components one at a time, ensuring that the original components are always replaced before removing the next one.
Same process dealing with faulty RAM when you have multiple sticks, remove one and see if POST still whines, put it back and remove another, etc, until POST is successful. Same story here just different scale, methodical, controlled elimination of potential causes one at a time which requires full control of the test environment.