Quick facts: Prime95 30.19 build 20 records what it did in text files in its own folder, principally results.txt for test outcomes and related log output often referred to from the program’s files. A passing entry means the computed result matched the known correct result. A rounding error or a hardware failure message means it did not, and the program’s stress.txt guidance says to suspect hardware first: unstable settings, memory problems, or overheating. This guide shows the shape of those entries and how to use the worker information in them. Entry wording below is shown as a format illustration to teach the layout, not as a log copied from any specific machine.

Where the evidence lives

Everything important is in the folder you extracted Prime95 into, which is another reason that folder must be writable. results.txt accumulates outcome lines over time, so a long-lived folder holds a history across many runs and even across machines if the folder travels. Before you interpret anything, note the date, preset, worker layout, and settings for the run you care about, and consider copying results.txt to a dated backup before the next run overwrites your context with newer lines. The Torture Test’s strength is that it checks arithmetic against known answers; the log is simply the written record of those checks, worker by worker.

What a passing entry looks like

A pass is recorded as a completed test with its identifying details and a successful result, without an error message. As a format illustration, expect a line pattern of this shape:

[Worker #1] Test completed successfully / no errors reported (format illustration)

The teaching points are the worker identifier at the start and the absence of an error term. One passing short run is weak evidence; a passing entry at the end of a long run in the preset you intended, with the worker layout you intended, is the evidence that matters. Always confirm the run actually lasted as long as you think it did. A test that stopped early because a worker was never started can look deceptively tidy in a quick glance at the log.

What a rounding error looks like

A rounding error means a computed value differed from the expected value by more than the allowed tolerance during the check. As a format illustration, expect a pattern of this shape:

[Worker #2] FATAL ERROR: Rounding was 0.5, expected less than 0.4 (format illustration)

The exact numbers vary by test, which is why the illustration is labelled as format only. The diagnostic content is consistent: rounding errors under load point first to unstable core or memory settings, voltage that is insufficient for the frequency, or heat changing the processor’s behaviour during the run. Note which worker reported it and after how long. Then change one variable and repeat the same preset. The dedicated diagnosis is in FATAL ERROR: Rounding explained.

What a hardware failure entry looks like

When the program detects a mismatch it may stop the worker and record a hardware failure message. As a format illustration:

[Worker #3] Hardware failure detected, consult stress.txt file (format illustration)

Read that message literally and calmly. It means this computation on this hardware at these settings produced a wrong answer. It does not, by itself, prove a permanently damaged processor; most such messages in overclocking practice trace back to settings, memory, or cooling that can be corrected and retested. It also does not mean the software is at fault. stress.txt makes the exception narrow: only if the identical error repeats at the identical place every time should you consider asking on the Mersenne forum whether you have found a program issue. The full response sequence is in Hardware failure detected: what to do.

Locating the problem by worker and core

The worker tag is your map. If you arranged workers by core groups and only one worker ever fails, suspect the settings or silicon associated with that part of the processor, or the memory channel pattern that worker’s preset exercises. If different workers fail on different runs with the same settings, suspect something global: memory timings or voltage, power delivery, or temperatures that rise over time. Pair the log with your run note: preset, elapsed time, and peak temperature you observed. A failure in the first minutes at Small FFTs tells a different story from a failure in hour nine of Blend, even if the error line looks similar. Small and early suggests core settings; late and in Blend or Large suggests heat soak or memory. Use those patterns to choose the next test, not to declare a verdict from one line.

When to ask for help, and what to bring

If two careful cycles of one-change-at-a-time testing still leave you with the same first error, outside help becomes reasonable, whether from a motherboard or memory maker’s support channel or from the Mersenne forum in the narrow case stress.txt describes. Bring evidence, not a summary from memory: the exact error lines from results.txt, the worker number, the preset, the elapsed time, your full settings note, and what you already changed and retested. State whether the failure happens at completely stock settings, because that single fact separates a tuning problem from a possible hardware fault more clearly than any other detail. A helper who can see the first error in context can often spot the pattern quickly, while a report that only says the test failed forces everyone to start from zero.

A clean interpretation routine

Stop the test properly. Save results.txt. Write down preset, workers, threads, settings, duration, and observed temperatures. Identify the first error, not the last, because later lines may be consequences. Change exactly one variable. Rerun the identical test. Compare first-error behaviour across the two logs. That routine, repeated, is how a text file becomes a diagnosis instead of an argument.

Next steps

For live faults, use the troubleshooting hub. For setup, revisit Worker Setup and How to Use Prime95. Every tutorial is indexed in the tutorials hub.

Quick facts: In Prime95 30.19 build 20, stress and GIMPS work is organised into workers. Each worker is an independent job with its own window on Windows, its own settings, and its own result lines. In the Test menu and the Worker Windows dialog you control how many workers run and how many threads each worker uses. The right arrangement depends on your goal, testing the whole processor at once or isolating part of it, and on your processor’s physical cores and simultaneous multithreading, not on a copied number from someone else’s machine.

What a worker actually is

A worker is a slot that runs one assignment or one Torture Test instance. When a worker stops with an error, Prime95 can tell you which worker it was, and when workers are mapped sensibly to cores, that information helps you localise a problem. Workers share the machine’s total threads, memory bandwidth, and cooling. Adding workers does not create performance; it divides the processor’s capacity into separately managed pieces. For GIMPS participation, multiple workers can run different assignments in parallel. For stress testing, the common purpose of the worker layout is coverage and diagnosis: cover every logical processor for a full-system test, or run fewer workers to isolate whether a fault follows a particular core group or disappears when part of the processor is idle.

Threads per worker, in plain terms

The threads setting inside a worker tells that worker how many hardware threads to use for its computation. If you run one worker, giving it all of the machine’s logical threads lets a single test span the whole processor. If you run several workers, their thread counts should add up to no more than the logical thread total if your goal is an even full load; oversubscribing, asking for more threads in total than the processor has, makes the operating system juggle work and muddies both heat behaviour and error localisation. Physical cores matter more than logical threads for this program’s heavy arithmetic: two threads on one physical core share that core’s execution resources, so doubling threads does not double throughput. That is why experienced testers think in physical cores first and treat extra logical threads as coverage for completeness rather than as extra computing muscle.

How to set workers on Windows

Open the Worker Windows dialog from the Test menu, the same dialog the current version may show when you enable PrimeNet in Test settings, and review each worker’s type of work and thread count before starting. For a first Torture Test, the program’s default arrangement is a sensible starting point; change it only with a reason you can write down. Before a long run, confirm three things: every worker you expect is actually running, the thread counts sum to the total you intended, and the Torture Test preset and memory setting are the ones you chose. A surprising number of confusing results are simply a worker that never started or a thread count left over from an earlier experiment in prime.txt. Because settings persist in prime.txt, a portable folder carries its worker layout to the next machine, where the core count may be different; recheck the layout on every new processor instead of trusting the travelled defaults.

Reading worker behaviour during a test

During the run, workers should progress steadily. If one worker stops with a rounding or hardware failure message while others continue, stop the whole test and record which worker stopped, its number, the preset, and elapsed time. That pattern is diagnostic gold compared with a whole-system freeze, because it ties the failure to the load that worker was running. If all workers stop or the machine restarts, the problem is more likely systemic: power, cooling, memory, or a setting that affects the whole processor. Do not immediately rerun hoping for a pass. Change one variable, such as restoring stock frequency or relaxing a memory profile, and repeat the same worker layout and preset so the comparison is clean.

A worked decision, without borrowed numbers

Suppose your goal is to find out whether one part of a processor is weaker than the rest after a full-system run stopped a single worker. Start by repeating the full layout once at completely stock settings; if the same worker area fails at stock, the issue is not your tuning. If stock passes, split the next run into fewer workers covering separate core groups, keeping total threads within the logical total, and run the same preset for the same duration on each arrangement. The arrangement that reproduces the failure has localised the search; the arrangements that pass have cleared their part of the processor under that test. Write each arrangement and outcome in your note as you go. This slow narrowing is slower than guessing, but it replaces guesses with evidence, and it is exactly what the worker system was designed to make possible.

Principles, not borrowed numbers

This guide gives no per-model worker table, because the program itself does not publish one and the correct layout follows from your processor’s core and thread counts and your testing goal. Count physical cores, count logical threads, decide whether the run is for coverage, isolation, or throughput, and write the layout in your test note. That short discipline makes results.txt far more useful when you later interpret it or ask for help.

Next steps

Set up the test itself with How to Use Prime95, then learn to read the outcome in Interpreting Prime95 Results. All guides are listed in the tutorials hub.

Quick facts: Prime95 30.19 build 20 includes a Benchmark mode alongside the Torture Test. The Torture Test checks correctness under sustained load by comparing results with known answers. Benchmark mode instead times how fast your processor completes defined FFT work, which makes it useful for comparing settings on your own machine, such as memory changes or the effect of an AVX switch. It is not a general-purpose benchmark suite, and this guide explains how to read its output without inventing comparison numbers that the program does not provide.

Benchmark mode versus the Torture Test

The two modes answer different questions, and confusing them produces bad conclusions. The Torture Test asks: does the machine compute correctly, continuously, under the heaviest load this program can create? Its important output is pass or error, the preset, and the time survived. Benchmark mode asks: how quickly does the machine complete this specific mathematical work? Its important output is timing for the FFT sizes it runs, which reflects core performance, cache behaviour, memory speed, and whether fast instruction paths such as AVX2 or AVX-512 are active. A fast benchmark result says nothing about stability, because a benchmark can finish quickly on settings that fail an hour into a Torture Test. A stable Torture Test result says nothing precise about speed. Use each mode for its own question, in that order if you are tuning: stability first, speed second.

How to run a clean benchmark

Close other demanding programs, let the machine reach a normal idle temperature, and run the benchmark from the program’s menus using the default worker arrangement for a first pass. Record the context alongside the result: processor, memory speed and timings, whether any prime.txt AVX switches are present, and whether the run used all workers or a single worker, because those choices change the meaning of the timings. Run the benchmark more than once and compare the repeatability of your own results before comparing them with anything else; a result that swings widely between identical runs tells you the machine was busy, throttling, or thermally unsettled. If you change one setting, such as enabling a memory profile, rerun the same benchmark the same way and compare your own before-and-after timings. That controlled, same-machine comparison is where Prime95’s benchmark is genuinely informative.

How to read the output

The benchmark reports timings for a series of FFT sizes, typically showing how long each size takes and a throughput-style figure for the work completed. Read the pattern, not a single line. Small FFT sizes live in cache and mainly reflect core and cache performance. Larger sizes spill toward memory and reveal more about memory bandwidth and controller behaviour. If large-size results improve after a memory change while small-size results barely move, that pattern is consistent with what you changed. If every size improves after removing an AVX switch, check that you actually removed it, because the switch changes which code paths the benchmark can use. Save the benchmark output with your notes; without the settings context, a saved timing is just a number with no diagnostic value. This guide deliberately publishes no score table and no model-versus-model chart: Prime95 does not ship an official comparison table for current processors, and inventing one would mislead more than it helps.

What Prime95 benchmarking cannot tell you

It cannot rank your machine for gaming, rendering, or office work, because FFT throughput is one narrow workload. It cannot measure your graphics card, storage, or single-core responsiveness in everyday applications. It also cannot separate every cause: a slower result could come from temperature, power limits, background tasks, memory settings, or a disabled instruction path, and the timing alone does not say which. Pair it with a monitoring and information tool when you need that context.

A complementary tool, disclosed

For broader system information, sensor readings, and its own benchmark panels, many builders also keep AIDA64 Extreme. If that fills a gap for you, the sponsored placeholder link is go/aida64 for AIDA64 Extreme. Sponsored: this site may earn a commission through that link at no extra cost to you; see the affiliate disclosure. Treat AIDA64 and Prime95 as complements: one describes and measures the system broadly, the other applies a focused, correctness-checked CPU and memory load. Neither replaces the other, and neither result should be borrowed to claim something it did not measure.

Recording results so they stay useful months later

A benchmark note should let you repeat the exact experiment. Write down the date, the Prime95 version and build, the preset-like choices the benchmark dialog offered, the number of workers, the memory amount in the machine and its configured speed, any prime.txt switches present, and whether the machine was on a cold start or already heat-soaked from a Torture Test. Save the program’s own output text rather than retyping a single headline figure, because the per-size pattern is where the diagnostic value lives. If you later upgrade memory or change a cooler, rerun under the recorded conditions before you change anything else, and keep both outputs together. Two comparable records are worth more than a folder of screenshots, because they show not only that a number moved, but which FFT sizes moved and by how much in relative terms on your own hardware.

Practical workflow

Establish a stable configuration with the Torture Test. Benchmark it and save the output with full settings notes. Change one variable. Benchmark again under the same conditions. Only then decide whether the change helped, hurt, or merely moved heat and power around. That discipline turns a simple built-in timing mode into a useful tuning record instead of a source of screenshots without context.

Next steps

Start from the tutorials hub and How to Use Prime95, then compare approaches in Prime95 vs Cinebench when that comparison is published.

Quick facts: Prime95 30.19 build 20 is portable by design. There is no installer for the standard Windows package, no administrator account is required for normal use, and the program keeps its settings and logs in the same folder as the executable. Extract the official zip to a writable folder and double-click prime95.exe. On Linux and macOS the command-line mprime follows the same extract-and-run pattern. Portable here means the official program’s normal behaviour, not a separate repackaged edition from a third-party site.

What portable means for Prime95, exactly

Many programs install services, scatter settings across the registry and user profile, and require an uninstaller. Prime95 does none of that for a normal stress test. Its folder contains the executable, its supporting libraries, its documentation, and, after you run it, the files it creates for itself: prime.txt for current settings, results output, and work-related files if you join GIMPS. Move the whole folder and you move the setup. Delete the whole folder and a test-only setup is gone. That design is why technicians carry Prime95 on a USB drive between machines, and why the most important setup rule is not installation at all, but choosing a folder the program can write to.

Set up a portable copy correctly

Download the verified package from the download page and check its SHA-256 if the copy will travel between machines. Extract the full contents to a new folder; do not run the executable from inside the zip viewer, and do not use an extraction wizard’s default temporary folder, a trap the program’s own readme warns about in effect by requiring a writable directory. The extracted folder needs to stay writable because the program writes prime.txt and result logs as it runs. On Windows, a folder in Documents, on a data drive, or at the root of a USB drive all work. A folder under Program Files is a poor choice because normal user accounts may not be able to write there without elevation, which defeats the no-administrator simplicity of portable use.

Using one copy on several machines

A USB copy is convenient, but treat each machine’s results separately. Copy or rename the results file after a run, or keep a small text note per machine recording the date, preset, duration, and outcome, because the folder’s logs otherwise blend together. Remember that settings in prime.txt travel with the folder: worker counts and AVX switches set for one processor may not be the choices you want on the next machine. The switches that disable AVX paths, for example, live in prime.txt, so a travelling folder can silently carry an AVX-off configuration to a new test. Before each machine’s run, open prime.txt, confirm it reflects the test you intend, and check that the folder still contains the complete set of library and data files from the original extraction. A partial copy is the most common portable failure, and it looks like a program fault when it is really a missing-file fault.

Configuration files: prime.txt and the old local.txt name

Current versions store settings in prime.txt. Older guides refer to local.txt because settings lived there in the past; the change notes for version 30.11 record the migration to prime.txt. If you find both names discussed in a forum thread, check the version the thread is about before copying its advice. For a portable folder this matters practically: when you back up a configuration you want to keep, back up prime.txt together with your results log. When you want a truly clean start on a new machine, extract a fresh copy from the verified zip rather than deleting files from a travelled folder one by one, so no stale setting survives unnoticed.

Checking a portable copy before you trust it

Before a portable copy earns a place on your diagnostic drive, prove it once on a machine you know well. Extract it fresh, run a short Torture Test, stop it from the menu, and confirm that prime.txt and the results output appeared in the folder and contain the run you just made. That five-minute check verifies the copy is complete, the folder is writable, and the settings file is the one the program is actually using. Repeat the check after you copy the folder to a different drive, because a copy interrupted halfway can leave a library behind. Label the drive folder with the version, 30.19 build 20, so a future copy is never confused with an older travelled folder whose prime.txt may hide settings from a different era of the program.

Limits of portability

Portable does not mean permission-free in every environment. Prime95’s readme is explicit that you should get permission from the employer or network administrator before running it on a workplace machine, and that rule applies with extra force to a USB copy brought from outside. A stress test also loads the power supply and cooling system hard; do not run it on a machine whose owner has not agreed, on a laptop running on a low battery, or on a system already showing hardware faults you have not backed up. Finally, portability does not extend across operating systems: the Windows folder will not run on Linux or macOS. Carry the separate mprime packages for those platforms if you service mixed machines, each in its own extracted folder.

A tidy portable routine

Keep the original verified zip in a separate archive folder. For each job, extract a clean copy, run the test, save the results and a settings note with the machine’s name, then archive or delete the working copy. That routine keeps checksums trustworthy, settings intentional, and evidence clear, which is the entire point of a portable diagnostic tool.

Next steps

Follow the full workflow in How to Use Prime95, choose settings from the tutorials hub, and get fresh packages only from the download page.

Quick facts: On macOS, Prime95 30.19 build 20 is a command-line program called mprime. There is no Mac GUI, no .app bundle, and no DMG installer. The official MacOSX package contains just a handful of files, centred on the mprime binary and its text documents. That binary is built for Intel x86_64 only, with no Apple Silicon slice, so on an M-series Mac it runs through Apple’s Rosetta 2 translation. That last point follows from the binary’s architecture; it is an architecture-based explanation, not a separate Apple Silicon edition, because no such edition exists in the official package.

Download the Mac package

Get the package from the download page or via the official direct link go/prime95-mac-official to mersenne.org. The MacOSX tar.gz package for 30.19 build 20 is 4,464,665 bytes, and the download page lists its verified SHA-256 and MD5 so you can check the file after downloading. If a site offers a Mac Prime95 .app, a DMG, or an Apple Silicon native build of this version, that offer does not match the official package described here. Stick to the archive whose checksum you can verify, extract it yourself, and run the binary from Terminal.

Extract to a writable folder

Create a folder in a place your account can write to, such as a Prime95 folder in your home directory, and extract the archive there. mprime stores prime.txt, work files, and result logs beside the binary, so the folder must remain writable and should not be a temporary download location that macOS may clear. After extraction you will see mprime plus the text files that ship with every platform, including readme.txt and stress.txt. There is nothing to drag into Applications and nothing to install. Keeping the folder intact is the whole installation, and deleting the folder is the whole uninstall for a machine you only used for testing.

Apple Silicon and Rosetta 2, stated plainly

On an Intel Mac, mprime runs natively. On an Apple Silicon Mac, the first launch of an Intel binary normally prompts macOS to offer Rosetta 2 installation if it is not already present; accept that system prompt if you want to proceed, because without translation the x86_64 binary cannot run on the ARM processor. Performance under translation is not the same as a native build would be, which matters if you use mprime for GIMPS throughput comparisons. For a stability check the translation layer does not change the meaning of the test: mprime still computes known problems and compares the results, and a mismatch still points first to hardware settings, memory, or heat. Do not interpret any speed difference between an Intel Mac and an Apple Silicon Mac running this binary as a pure processor comparison.

Run mprime from Terminal

Open Terminal, change into the extracted folder, and start the menu:

./mprime -m

The menu is where you choose between joining GIMPS through PrimeNet and using the program only for stress testing, configure workers, and launch the Torture Test. For a hardware check, take the stress-testing path. The Torture Test presets carry the same official meanings as on every platform: Smallest FFTs test the L1 and L2 caches; Small FFTs test L1, L2 and L3 caches with maximum power, heat and CPU stress; Large FFTs stress the memory controller and RAM; Blend, the default, tests all of the above. Since version 29.8 the FFT sizes are chosen automatically from cache size. The official duration guidance in stress.txt is 6 to 24 hours for a thorough run, unstable machines often fail within minutes, and 10 to 15 minute runs are for quick tuning steps only. On a Mac laptop, run on mains power, keep vents unobstructed, and watch temperatures with a Mac monitoring utility, because a thin laptop cooling system is often the limiting factor long before the processor is.

Stopping, logs, and what an error means

Stop the test from the mprime menu rather than force-quitting Terminal, so the program can finish writing its files. Then read the results output in the same folder. A completed entry means that worker’s computation matched the known result for that test. A rounding error or hardware failure message means it did not, and stress.txt guidance says to suspect hardware first: unstable settings, memory problems, or overheating, unless the identical error repeats at the identical place every time. Save the log lines and the time the worker stopped before changing anything. On a stock Mac with no tuning options, an error is still useful evidence for a support conversation, especially if it repeats across runs at the same settings.

Laptops, desktops, and sustained load on a Mac

The same mprime menu behaves differently in practice depending on the Mac’s cooling design. A desktop Mac with larger fans and a roomier case can usually sustain a long run with temperatures that level off, while a thin laptop may reach its thermal limit quickly and reduce clock speed to protect itself. That throttling does not invalidate the correctness check, because mprime still compares every result, but it does mean the run is testing the machine at the speed its cooling allows rather than at its short-burst speed. For a fair repeat test, use the same power connection, the same surface, and a similar room temperature, and note those conditions beside the log. If a laptop cannot complete a long run without severe throttling, treat that as useful information about sustained-load suitability, not as a reason to block vents or override fan behaviour to force a pass.

What mprime on Mac cannot do

It cannot give you the Windows graphical experience, because that interface exists only in the Windows build. It also does not test the Mac’s graphics processor, storage, or display pipeline; it stresses CPU and RAM, with cooling and power delivery stressed indirectly. There is no official iPhone or iPad version to continue a test on mobile, either. Treat mprime as one focused instrument: excellent at exposing CPU and memory calculation errors under sustained load, silent about everything else.

Next steps

Compare platforms on the platforms page, follow the general workflow in How to Use Prime95, and browse the tutorials hub for preset and results guides.

Quick facts: On Linux, Prime95 30.19 build 20 is not a graphical program. The same code ships as a command-line program called mprime in the official linux64 package, p95v3019b20.linux64.tar.gz (5,912,959 bytes, SHA-256 listed on the download page). There is no Linux GUI to install. You extract the archive to a writable folder, run ./mprime -m to open the menu, and control workers, PrimeNet communication, and the Torture Test entirely from the terminal.

Download and verify the Linux package

Get the package from the download page or through the official direct link at go/prime95-linux64-official, which points to mersenne.org. The download page lists the verified SHA-256 for the linux64 package, so you can run a checksum command in the terminal and compare the output before extracting anything. That habit matters more on Linux because you will run the binary directly from the extracted folder; there is no installer signature step in between. Save the archive somewhere sensible, such as your home folder, rather than a system directory you need elevated permissions to write to.

Extract to a writable working folder

Create a dedicated folder, move the archive into it, and extract it there. mprime writes its configuration, work files, and logs in its working directory, including prime.txt and results files, so the folder must stay writable by your normal user account. Do not extract into a protected system path and then fight permission errors. After extraction you should see the mprime binary together with library files shipped in the package and the familiar text documents, including readme.txt and stress.txt. If the binary does not start, check that you are in the correct folder and that the file is marked executable, and consult the readme’s Linux instructions about the bundled libraries. Run mprime as your regular user; a stress test does not need root.

Start mprime and use the menu

From a terminal in the extracted folder, run:

./mprime -m

The -m flag opens the main menu. From there you can configure whether the machine joins GIMPS through PrimeNet or is used only for testing, set worker counts, and reach the Torture Test. First-time prompts ask about joining GIMPS; if your only goal is stability testing, choose the stress-testing path and skip work assignment, mirroring the Just Stress Testing choice in the Windows program. Menu choices are numbered, and the program saves your answers to prime.txt in the same folder. Because everything is text, mprime works well over SSH on a headless machine, which is one reason Linux builders favour it for overnight runs. Keep the terminal session alive for the run, or use your usual terminal multiplexer so an SSH disconnect does not end the test.

Running the Torture Test on Linux

Inside the menu, open the Torture Test option and choose a preset. The presets mean the same thing as on Windows: Smallest FFTs test the L1 and L2 caches with high power and heat; Small FFTs test L1, L2 and L3 caches with maximum power, heat and CPU stress; Large FFTs stress the memory controller and RAM; Blend, the default, tests all of the above. Since version 29.8 the FFT sizes are selected automatically from cache size, so do not copy fixed size ranges from old guides. The duration guidance is also the same official guidance from stress.txt: 6 to 24 hours for a thorough check, with unstable machines often failing within minutes, and 10 to 15 minute runs reserved for quick steps while tuning. While the test runs, monitor temperatures with your distribution’s usual sensor tools in a second terminal. mprime itself focuses on the computation check; it is not a temperature dashboard.

Files, stopping, and reading the outcome

To stop, use the menu’s stop option or interrupt the program cleanly, then read the result files in the working folder before you change settings. results output records completed tests and error messages, including which worker stopped. If a worker reports a rounding error or a hardware failure message, treat it the same way as on Windows: the computation did not match the known correct result, so suspect the overclock, memory settings, or cooling before suspecting the software. The detailed reading method is in the results interpretation guide linked below. Because prime.txt lives beside the binary, backing up a known-good Linux setup is as simple as copying the whole folder, which also makes mprime naturally portable between similar machines.

Keeping a Linux test folder tidy

Because mprime keeps everything in one folder, a little housekeeping makes long-term testing far clearer. Keep the original verified archive separate from the working folder. After each significant run, copy the results output into a dated subfolder or rename it with the machine name and date, and keep a short note with the preset, duration, and any settings you changed in prime.txt. If you test several machines from the same home directory structure, use one clearly named folder per machine rather than reusing a single mprime folder for all of them, because prime.txt carries worker and menu choices from the previous system. A tidy folder turns a stopping worker from a confusing terminal memory into a record you can compare against the next run, which is the whole point of a checked computation test.

Differences from Windows to remember

There is no system tray icon, no graphical worker windows, and no point-and-click Options menu; every equivalent action is a menu entry or a prime.txt value. Scheduling also differs: if you want mprime to start with the machine for GIMPS work, that is a service or startup configuration you create yourself, separate from a one-off stress test. For a pure stability check, manual menu runs are clearer because you see the start time, preset, and any error directly. Finally, remember that Prime95 and mprime stress CPU and RAM; they do not test a Linux machine’s graphics stack, disks, or network, however long they run.

Next steps

See the platform overview on the platforms page, the Windows workflow in How to Use Prime95, and the full index in the tutorials hub.

Quick facts: Prime95 30.19 build 20 can skip its AVX, AVX2, and AVX-512 code paths if you add settings to prime.txt, the configuration file in the Prime95 folder. The documented keys are CpuSupportsAVX=0, CpuSupportsAVX2=0, and CpuSupportsAVX512F=0. Since version 30.11, settings live in prime.txt; older guides that tell you to edit local.txt are describing the previous arrangement. Disabling AVX changes what you are testing, so read the trade-offs below before you treat a pass as equivalent.

Why people disable AVX at all

AVX instructions let the processor do more arithmetic per clock cycle, which raises power draw and heat under a continuous load like the Torture Test. A widely cited community source, the Tom’s Hardware Intel Temperature Guide, reported that on older Core processors from the 2nd to 8th generations, versions after 26.6 running AVX code could produce temperatures up to about 20 degrees Celsius higher than version 26.6, and described those temperatures as unrealistic compared with typical workloads. That is a second-hand community guide figure for older platforms, not an official GIMPS conclusion and not a number to apply directly to a modern processor with AVX offset and power-limit management. The underlying point still holds on many systems: an AVX-heavy Prime95 run is a deliberately extreme load, and some testers want a run that resembles a heavy non-AVX workload more closely, or want to isolate whether AVX power draw is what pushes their cooling over the edge.

The exact settings

Close Prime95 first, so it does not overwrite the file when it exits. Open the folder where you extracted Prime95 and find prime.txt. Open it in a plain text editor and add the lines you need, one per line, then save and relaunch the program:

CpuSupportsAVX=0
CpuSupportsAVX2=0
CpuSupportsAVX512F=0

You do not have to add all three. Adding only the AVX-512 line, for example, keeps AVX2 paths active while removing the widest vector path. These keys tell the program to act as if the CPU does not support the feature; they do not change your processor, your BIOS, or any other application. To undo the change, delete the lines or set them back to 1 and restart Prime95. If you followed an old tutorial and created the entries in local.txt instead, move them to prime.txt, because current versions read their settings from prime.txt following the migration recorded in the version 30.11 change notes. Keep a backup copy of the original prime.txt before editing, so you can restore your worker and communication settings exactly.

What a test with AVX disabled actually proves

With AVX disabled, the Torture Test still compares results against known correct answers and still stresses caches, cores, and memory, but it no longer proves stability for AVX workloads. Video encoders, scientific software, emulators, and some games do use AVX instructions, and an overclock that passes only with AVX disabled can still fail in those programs. Treat the AVX-off run as a diagnostic and as a heat reference, not as a replacement for a full test. A clear method is to run both: first with AVX enabled to find the true worst case, then with AVX disabled to see how much of the heat and power is AVX-driven. If the system passes with AVX off and fails quickly with AVX on at the same settings, your limit is likely power, voltage under AVX load, or cooling, and a BIOS AVX offset is often the more honest fix for daily use.

How this relates to version 26.6

Version 26.6 is searched for the same reason: it is the last release before AVX optimisation entered the FFT code in version 27.1, so it naturally produces a lighter, non-AVX load. Using an ancient build is not necessary to get that effect, and 26.6 lacks later features such as PRP proof generation, AVX-512 support, and heterogeneous core support. The modern equivalent is current Prime95 with the prime.txt switches above. The full story is on the Prime95 26.6 page. For BIOS-side control instead, see Prime95 and AVX offset.

Verify the switch took effect

After relaunching, do not assume the edit worked just because the file saved. Start a short Torture Test run and watch power and temperature behaviour compared with your earlier AVX-enabled run at the same preset and settings; a clear change in the heat pattern is practical evidence that a different code path is in use. Check also that Prime95 did not recreate or overwrite prime.txt on exit, by reopening the file after you close the program and confirming your lines are still present exactly as written. If nothing changed, the usual causes are editing a copy of prime.txt in a different extracted folder, leaving a second Prime95 instance running, or a spelling difference in the key name. Fix the file location first, then the spelling, and test again with the same short run so the comparison stays honest.

Common mistakes

The most common mistake is editing the wrong file, local.txt, and concluding the switches do not work. The second is editing prime.txt while Prime95 is still running, so the program rewrites the file on exit. The third is forgetting the edit exists: weeks later, benchmark or GIMPS results look low and the hidden cause is a disabled instruction path. Add a comment to your own notes, not to prime.txt in a way that breaks its format, recording the date you added the switches and why. Finally, do not disable AVX to hide an overheating problem you intend to ignore. If a cooler cannot handle the AVX run, the correct responses are better cooling, lower voltage, an AVX offset, or stock settings, in whichever combination you can verify with a repeat test.

Next steps

Return to the tutorials hub for the main workflow in How to Use Prime95, and compare presets in Small vs Large vs Blend before your next run.

Quick facts: The only official duration guidance for Prime95 30.19 build 20 is in stress.txt, the guide written by the program’s author and included with the download. It recommends running the Torture Test for 6 to 24 hours. It also says unstable machines often fail within minutes, and that people who are overclocking can use short 10 to 15 minute runs to explore each frequency step before a long final test. There is no official statement that any fixed run length makes a system completely stable or safe.

What stress.txt actually says, and why it matters

Many forum posts turn duration into a contest or a badge: pass a certain number of hours and the machine is declared finished. The official guide is more careful. It explains that the program has exposed errors after several hours, and in some cases after much longer, which is why the recommended window stretches to 24 hours. At the same time, it recognises that most clearly unstable configurations do not survive long at all. A machine that cannot pass the first few minutes does not need an overnight run to prove the point; it needs a settings change. A machine that passes an hour has cleared only the easiest hurdle. Duration buys probability, not certainty, and each additional hour is most valuable when temperatures and settings stay exactly the same throughout.

Short tests have a job, but it is not certification

When you are tuning an overclock, rebooting for a 24-hour test after every small change would waste days. That is the situation the 10 to 15 minute short run is for. Use a short Small FFTs run to check that a new frequency boots under load, watch whether temperatures level off, and catch immediate errors. Then move to the next step or back off. Once you reach settings you actually intend to keep, switch modes completely: run the long test, in Blend or in the preset that matches your concern, and do not change settings mid-run. Mixing the two modes, for example calling a system stable because it survived the same short test five times, is the most common mistake in stress testing. Five short runs still leave the long-run failure modes untested, including heat soak in the case and memory errors that appear only after sustained access patterns.

How to plan a long run you can trust

Start a long run only when you can monitor the beginning in person. Watch the first 15 to 30 minutes for temperature behaviour, fan response, and early worker errors. Confirm the extracted Prime95 folder is writable so results.txt is saved, and disable sleep so the operating system does not suspend the machine overnight. Note the preset, the worker count, your voltage and frequency settings, and the ambient conditions in a simple text note. If a worker stops, the value of the run is in those details: which preset, after how long, and with what message. Stop the test from the Test menu, preserve results.txt, and change one variable before retesting. Repeating an identical failing run without a change tells you nothing new.

Temperature is a reason to stop, not a duration to endure

No duration guidance overrides thermal common sense. Prime95’s documentation does not publish a universal safe temperature that fits every processor, and this site will not invent one. Check your exact CPU model on the manufacturer’s specification page, watch temperatures with a monitoring tool during the run, and stop if temperatures keep climbing instead of levelling off, if fans fail, or if the system throttles heavily or shuts down. A test you stop for cooling reasons has still done its job: it found the limit. Fix mounting, paste, airflow, or voltage, then start the clock again from zero.

Choosing a preset for the long run

The duration guidance applies to whichever preset matches your question, but the choice changes what a long run proves. A long Blend run is the broadest single choice because it cycles through sizes that live in cache and sizes that press memory. A long Small FFTs run is the stronger statement about core stability and cooling, because that preset produces maximum power and heat. A long Large FFTs run is the stronger statement about memory and the memory controller. If time allows only one overnight run, match it to the change you just made: core voltage or frequency changes call for Small, memory profile changes call for Large, and a brand-new build with no specific suspicion is best served by Blend. Record the preset beside the duration in your note, because a duration without a preset is only half a result.

Frequently asked questions

How long should I run Prime95 according to the official guide?

The stress.txt guide included with Prime95 recommends running the Torture Test for 6 to 24 hours for a thorough stability check.

Can a short Prime95 run prove my system is stable?

No. The same guide notes that unstable machines often fail within minutes, and that short runs of 10 to 15 minutes are useful while exploring overclock steps, but a short pass cannot prove a system is stable. Running longer gives the test more chance to expose a problem.

My system failed after only a few minutes. What does that mean?

According to stress.txt, unstable machines often fail quickly, sometimes within minutes. Treat an early failure as a clear sign that the current settings are not stable, save the error from results.txt, and adjust one setting at a time before retesting.

Does Prime95 promise that a system is safe after a long run?

No. Prime95 provides no such promise. Its license provides the program as-is without warranty, and stress.txt gives duration guidance only. A long error-free run is evidence of stability under that test, not a certification for every workload.

Next steps

For the full workflow, see How to Use Prime95. For the broader question of risk and monitoring, read Is Prime95 Safe? More short answers are collected on the FAQ page, and all guides are indexed in the tutorials hub.

Quick facts: Prime95 30.19 build 20 offers four Torture Test presets plus Custom. Smallest FFTs test the L1 and L2 caches with high power, heat and CPU stress. Small FFTs test the L1, L2 and L3 caches with maximum power, heat and CPU stress. Large FFTs stress the memory controller and RAM. Blend, the default, tests all of the above. Since version 29.8, the program sizes each preset automatically from your CPU’s cache, so there is no current fixed FFT size table to memorise.

The official definitions, without the folklore

The definitions above come from the Torture Test menu itself and the program’s stress.txt guidance. They are short on purpose: each preset is defined by where its data lives. When the FFT data fits inside the processor caches, the cores can work continuously with few pauses, which is why the small presets draw so much power and produce so much heat. When the data is too large for the caches, the processor must constantly fetch from system memory, which shifts the pressure onto the memory controller and the RAM itself. Blend mixes data sizes across that boundary, so over time it exercises both paths. Custom lets you set the minimum and maximum FFT size, the amount of memory to use, and how long to spend on each size, which is useful only when you already know which boundary you want to probe.

Why old FFT size tables mislead

Search results still surface tables that assign exact ranges to each preset, such as a small range for Small FFTs and a larger range for Large FFTs. Those numbers are from versions published many years ago. The version 29.8 change notes record that Torture Test options are now generated from cache size, and version 30.19 follows that approach. On a modern processor with large L3 cache, the sizes the program picks will differ from a processor with a small cache, and both can be correct. In Custom mode you can see the minimum and maximum FFT values the program offers on your own machine; treat those as your machine’s values, not as a universal specification. If a guide quotes a fixed range without naming a version, assume it is historical until proven otherwise.

Which preset should you run first?

For a new build at stock settings, start with Blend for a broad check, then follow up with the specific preset that matches any symptom. For an overclocked CPU, start with Small FFTs: because it is the maximum heat and power preset, it reveals cooling limits and core instability quickly. For a new memory kit, a changed memory profile, or random crashes that happen outside stress tests, include a long Large FFTs run, because Blend alone spends part of its time on small sizes that fit in cache and may not press memory as continuously. Many testers run all three in sequence across different sessions rather than expecting one preset to answer every question.

The most useful diagnostic clue in the menu

The Torture Test menu carries an official note worth remembering: if Blend fails but the small FFT tests pass, the problem is more likely in memory or the memory controller. Read that in reverse as well. If Small FFTs fails quickly at a given frequency, changing memory timings first is unlikely to fix a core problem. This one clue can save hours of random setting changes. Record which preset failed, which worker stopped, and how long the run lasted before you change anything. Change one variable at a time, then repeat the same preset; switching presets at the same time as settings makes the comparison meaningless.

Small FFTs, heat, and your cooler

Because Small FFTs is officially the maximum power and heat preset, it is the right test for judging a cooler, but also the test most likely to expose weak cooling. Before blaming the processor, check that the cooler is mounted evenly, thermal paste coverage is sensible, and case fans actually spin up under load. Two widely recommended large air coolers for demanding stress testing are linked here as sponsored Amazon links: the Noctua NH-D15 and the Thermalright Peerless Assassin. Sponsored: this site may earn a commission from purchases made through those links at no extra cost to you; see the affiliate disclosure. A cooler upgrade helps only if your case airflow can feed it, so treat cooler, paste, and airflow as one system. If your processor is already hitting its limit, read Prime95 overheating and 100C readings before running another long test.

A practical testing order

First, run Small FFTs long enough to see temperatures level off and to catch quick core errors. Second, run Large FFTs to press memory and the controller. Third, run Blend for the longest session, ideally following the official duration guidance of 6 to 24 hours for a final check. Between stages, save results.txt and note your settings. If every preset passes but the machine still misbehaves in games or rendering, the fault may lie in a component Prime95 does not test, such as the graphics card or storage; Prime95 stresses CPU and RAM, plus cooling and power delivery indirectly, and the official guide points to other tools for the rest.

Next steps

New to the program itself? Follow How to Use Prime95 first. For errors and shutdowns, use the troubleshooting hub. The complete tutorial index lives in the tutorials hub.

Quick facts: Current version is Prime95 30.19 build 20, a freeware program by George Woltman for GIMPS, the Great Internet Mersenne Prime Search. Its main job is hunting for Mersenne primes. The Torture Test covered in this guide is a secondary use described in the program’s own stress.txt file: it stresses your CPU and RAM by comparing every result against a known correct answer. Only the Windows version has a graphical interface. There is no installer and no administrator account is needed for normal use.

Step 1: Download the right package

Start on the download page, which lists the verified packages for version 30.19 build 20 with their exact sizes and SHA-256 checksums. Most desktop users need the Windows 64-bit package, p95v3019b20.win64.zip. Choose the 32-bit package only for a very old 32-bit Windows installation. Linux and macOS users do not get this graphical program at all; they use the command-line program called mprime, covered in separate guides linked at the end of this article. Before you run anything, you can compare the checksum of your downloaded file with the value on the download page. That simple check tells you whether the file arrived complete and unchanged from the official mersenne.org package.

Step 2: Extract to a folder you can write to

Prime95 is portable software. Right-click the zip file and extract it to a normal, writable folder, for example a new Prime95 folder inside your Documents folder or on a second drive. Avoid the default temporary location offered by some extraction wizards, and avoid protected system folders. The program needs to write its configuration and result files in the same folder where it runs, including prime.txt and results.txt. If the folder is read-only or buried in a temporary directory that gets cleaned up, settings will not save correctly and you may lose a long test’s log. Once extracted, you should see prime95.exe alongside supporting library files and text documents such as readme.txt and stress.txt. Keep all of those files together; do not move the executable on its own.

Step 3: Launch and choose Just Stress Testing

Double-click prime95.exe. You do not need to right-click and run as administrator for a normal stress test. On first launch the program may ask whether you want to join GIMPS or just run stress testing. If your goal is checking a new build, an overclock, or suspected instability, choose Just Stress Testing. That keeps the program offline from PrimeNet work assignment and puts the testing tools front and centre. Joining GIMPS is a separate, worthwhile activity in which your computer searches for Mersenne primes and reports results to the PrimeNet server, but it is not required to validate your hardware.

Step 4: Open the Torture Test and pick a preset

From the menu bar, choose Options > Torture Test. You will see preset choices named Smallest FFTs, Small FFTs, Large FFTs, and Blend, plus a Custom option. Since version 29.8, the program chooses the FFT sizes for each preset automatically from your CPU’s cache sizes, so you do not need to copy size numbers from an old forum table. Those fixed tables circulating online are from much older versions and do not describe version 30.19. Pick Small FFTs when you want maximum power, heat, and CPU stress. Pick Large FFTs when you want to stress the memory controller and RAM. Pick Blend, the default, for a broad mix of everything. The full preset comparison is in Small vs Large vs Blend FFTs.

Step 5: Watch temperatures while it runs

A stress test is only useful if you watch what your hardware is doing. Keep an eye on CPU temperature, clock speed, and voltage in a monitoring tool while Prime95 runs. Many builders use HWiNFO, a free monitoring tool available from hwinfo.com. HWiNFO is mentioned here only as a practical monitoring companion; this site has no partnership with it. There is no single official safe temperature number in Prime95’s documentation that applies to every CPU, so check the limit for your specific processor on the manufacturer’s specification page instead of relying on a generic number from a forum. If temperatures climb steadily and never level off, stop the test and improve cooling before trying again. Sudden shutdowns, a frozen screen, or a worker stopping with an error are all information, not a reason to push harder.

Step 6: Decide how long to run it

Do not judge a system by a two-minute run. The official stress.txt guide recommends 6 to 24 hours for a thorough check, notes that unstable machines often fail within minutes, and suggests short runs of 10 to 15 minutes only as a quick way to explore each step while tuning an overclock before a long final test. Running longer gives the test more chances to expose a problem; no fixed number of hours can prove a machine will never fail. The reasoning is explained in detail in How Long to Run Prime95.

Step 7: Stop the test correctly

To stop, use Test > Stop in the menu, or simply close the program after stopping the workers. Stopping preserves your log files so you can review them later. If a worker already stopped on its own with a message about rounding or a hardware failure, do not just restart and hope. Save the relevant lines from results.txt, note which worker stopped and after how long, and work through the diagnosis steps. A single error is enough to say the current settings are not stable; lowering an overclock, restoring default memory timings, or improving cooling are the usual next moves, in that order of simplicity.

What to do next

Browse the full tutorials hub for preset deep-dives, AVX settings, and platform guides. If your test produced an error, go straight to result interpretation and troubleshooting rather than repeating the same run. Keep your extracted folder, your results.txt, and a note of your BIOS settings together; that small record makes the second run far more informative than the first.

Sponsored: If you want to study overclocking and PC hardware more systematically, structured courses can help. See the course placeholder at Coursera via our sponsored link and read our affiliate disclosure before enrolling. The link is sponsored and this site may earn a commission at no extra cost to you.