From 1adba473e6917b227e1b0a1118148101dca202e7 Mon Sep 17 00:00:00 2001 From: Manuel Traut Date: Mon, 31 Mar 2014 16:53:55 +0200 Subject: add quellcode Signed-off-by: Manuel Traut --- quellcode/versuch3/readme | 65 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100755 quellcode/versuch3/readme (limited to 'quellcode/versuch3/readme') diff --git a/quellcode/versuch3/readme b/quellcode/versuch3/readme new file mode 100755 index 0000000..e331092 --- /dev/null +++ b/quellcode/versuch3/readme @@ -0,0 +1,65 @@ +CPU Burn-in README +------------------ + +What is CPU Burn-in? +------------------- + +CPU Burn-in v1.0 by Michal Mienik is the ultimate stability testing tool for overclockers. +The program heats up any x86 CPU to the maximum possible operating temperature that is achievable +by using ordinary software. This allows the user to adjust the CPU speed up to the practical +maximum while still being sure that stability is achieved even under the most stressful conditions. +The program continuously monitors for erroneous calculations ensuring the CPU does not +generate errors during calculations. + + +Why use CPU Burn-in? +------------------- + +In the past overclocking stability was tested by running intensive software such as +Distributed.Net clients or SETI@home. Running either piece of software for 24 hours would generally +show up instability. A looping Quake3 timedemo was also a good choice. + +However, there are inherent limitations in these tests: + +Not every error caused by overclocking causes a program to crash or the system to hang. Some +errors may be more subtle, such as a slight miscalculation. If such an event occurs and causes a pixel +to render a slightly different colour in Quake3 for example, the user is unlikely to notice and overall +this is no big deal. However such small errors can have a potentially devastating on distributed projects +such as SETI@home, which rely on the reliable processing of data. + +CPU Burn-in consistently delivers a higher CPU operating temperature than the above mentioned +applications. This allows CPU Burn-in to be particularly effective at testing overclocking stability +and cooling effectiveness. + +How does it work? +---------------- + +CPU Burn-in constantly cycles FPU intensive functions for a user specified period of time. The +resultant calculations are constantly checked for data integrity. If the program detects erroneous +data the user is immediately informed. Applications such as SETI@home and Distributed.Net perform no +such data checking. The user must rely on those programs to crash or the system to hang before a +problem can be noticed. + +Instructions: +------------ + +Please Note: Overclocking can potentially be harmful to your CPU. It may fry or fail prematurely +in the long term. I cannot and will not be responsible for any damage you do to your hardware. +By it's very nature, CPU Burn-in pushes the CPU to the max. Increasing the voltage, Mhz, or PCI/AGP +above the recommended levels can cause damage. + +CPU Burn-in runs best as a high priority process on an otherwise idle system. + +Run the program with one command line value to specify the length of time to run the test: + +eg. + "./cpuburn-in 10" will run the test for ten minutes. + + +Contact: +------- + +If your system experiences instability during the burn-in test or you receive error messages it's likely +the system has been overclocked too far. + +If you believe a bug in the program has been found please email cluster2k@hotmail.com -- cgit v1.2.3