This file lists the undocumented features available in the program. These features may change or be discontinued at any time. Their use is totally unsupported. In prime.txt you can force the program to use different filenames for 6 files. You can also change the working directory (identical to the -W command line argument). prime.ini=your_filename local.ini=your_filename worktodo.ini=your_filename prime.log=your_filename prime.spl=your_filename results.txt=your_filename WorkingDir=your_directory_name Some options in prime.txt can be configured to have different values at different times of the day using this syntax: Option=setting where setting is defined as value OR value during list-of-times else setting At present, only Memory, MaxHighMemWorkers, PauseWhileRunning, LowMemWhileRunning, and PauseCheckInterval support this during/else syntax. Also note you can no longer edit these options from the user interface. To use this feature, you must manually edit the prime.txt/local.txt file. An example in local.txt: Memory=500 during 1-5/17:30-24:00,1-5/0:00-8:30,6-7/0:00-24:00 else 200 The 1-5 and 6-7 refer to days of the week, with Monday=1 and Sunday=7. The time portion refers to the hours of the day based on a 24-hour clock. You do not need to specify days of the week (e.g. 1-7/0:00-8:00 is the same as 0:00-8:00). The above example lets the program use 500MB during the week from 5:30PM to 8:30AM and all day on weekends. Otherwise (weekdays from 8:30AM to 5:30PM), the program can use only 200MB. You can control whether the program does extra error checking on every iteration of a primality test. This runs a little bit slower. Windows user can control these options from the Advanced Menu. Linux users must add one or both of these lines to prime.txt to control these options: ErrorCheck=0 or 1 SumInputsErrorCheck=0 or 1 The first line controls "ROUNDOFF > 0.4" error checks, the second line controls "SUM(INPUTS) != SUM(OUTPUTS)" error checks. You can control how the "count of errors during this test" message is output with every screen update. These messages only appear if possible hardware errors occur during a test. In prime.txt set: ErrorCountMessages=0, 1, 2, or 3 Value 0 means no messages, value 1 means a very short messages, value 2 means a longer message on a separate line, value 3 means a very long message possibly on multiple lines. Default value is 3. You can control how often Jacobi error checking is run. Default is 12 hours. If a Jacobi test takes 30 seconds, then the default represents an overhead of 30 / (12 * 60 * 60) or 0.07% overhead. Each Jacobi test has a 50% chance of discovering if a hardware error has occured in the last time interval. In prime.txt: JacobiErrorCheckingInterval=N (default is 12) where N is in hours. You can control how many save files are kept that have passed the Jacobi error check. This value is in addition to the value set by the NumBackupFiles setting. So if NumBackupFiles=3 and JacobiBackupFiles=2 then 5 save files are kept - the first three may or may not pass a Jacobi test, the last two save files have passed the Jacobi error check. In prime.txt: JacobiBackupFiles=N (default is 2) You can disable Jacobi error checking which has a 50% chance of catching hardware errors. You might do this if you are running the first LL test and double-checking LL test concurrently. In prime.txt JacobiErrorCheck=0 or 1 (default is 1) You can disable printing Jacobi error-checking messages using this prime.txt entry: SilentJacobi=0 or 1 (default is 0) You can force the Options/CPU dialog to display times using AM/PM or a 24-hour clock format. Otherwise, the program will make its best guess as to the proper format. Add this line to prime.txt: AMPM=n where n is 1 for AM/PM formatting and n is 2 for 24-hour formatting. You can adjust how many decimal digits of precision are displayed in lines output to the screen. In prime.txt enter a value between 0 and 6: PercentPrecision=n You can choose whether the program uses the high resolution system clock, the standard system clock, or the read timestamp counter instruction (RDTSC) to time events. By default the program uses the high resolution system clock if available. Choose one of these values for n (default is 1): 0 - use the system clock. 1 - use RDTSC but do not output clock counts. 2 - use RDTSC and output clock counts. The above values will only have an affect if a high resolution system clock is not available. You can force the program to bypass the high resolution clock by adding 10 to one of the values above. In prime.txt, enter RdtscTiming=n You can alter the way the program outputs timings. In prime.txt set: TimingOutput=n Where n=1 for seconds with 3 digits of precision, n=2 for milliseconds with 1 digit of precision, n=3 for milliseconds with 2 digits of precision, n=4 for milliseconds with 3 digit of precision. You can change the formatting of date and time to the screen. In prime.txt: TimeStamp=n where n=0 turns output off, n=1 is the default date/time without seconds, n=2 is date/time with seconds, n=3 is time only without seconds, n=4 is time-only with seconds. You can have the timings that are output to the screen be cumulative (from program restart or start of a new exponent) rather than resetting after each screen output. Add this line to prime.txt: CumulativeTiming=1 You can change the interval between outputs of the timestamp to the results.txt file ResultsFileTimestampInterval=n If n is zero, the timestamp will never be output. Otherwise the timestamp will be written no more frequently than every n seconds. Default for n is 300 which is 5 minutes. You can revert to the "classic" style output for worker windows doing Lucas-Lehmer and PRP tests. This classic style does not display the ETA. This style was in use prior to version 28.5. In prime.txt: ClassicOutput=0 or 1 (default value is 0) You can output the maximum round off error seen thusfar in the worker windows when doing LL or PRP tests. OutputRoundoff=0 or 1 (default value is 0) You can reset the maximum round off error seen thusfar after each time the maximum round off is output. CumulativeRoundoff=0 or 1 (default value is 1) You can update the title more frequently than the lines are output to the worker window. This feature, only useful in Windows, allows you to keep track of progress in the tray icon or window title without "cluttering up" the worker window. In prime.txt: TitleOutputFrequency=n (default value is 1) The title will update n times more frequently than the worker window. When workers are testing wildly different numbers, such as ECM on a small Mersenne number in one window and an LL test on a 100 million digit number in another window, then the "iterations between screen outputs" setting will cause the windows to output at wildly different rates. You can workaround this in prime.txt: ScaleOutputFrequency=0 or 1 (default value is 0) If you set this to 1, then "iterations between screen outputs" will be automatically scaled so that windows produce output at roughly the same rate. An LL test on M50,000,000 will not scale at all, ECM on a small number will scale to a much larger value and an LL test on a 100 million digit number will scale to a much smaller value. The program normally will not start any calculation until 90 seconds after a reboot. This is done so that your normal boot up procedure can be as fast as possible. You can control how long this delay is by adding this line to prime.txt, where n is the number of seconds to sleep: BootDelay=n Some machines report much better timings if the worker threads stagger their starts. This was first noticed on Core i7 machines running Windows. Presumably staggering starts improves timings due to each worker allocating contiguous memory. You can control how long the program waits between starting each worker. In prime.txt, enter: StaggerStarts=n where n is the number of seconds to wait. The default is 5 seconds. The program supports many different code paths for LL testing depending on the CPU type. It also has a few different factoring code paths. You can force the program to choose a specific code path by setting the proper combination of these settings in local.txt: CpuSupportsRDTSC=0 or 1 CpuSupportsCMOV=0 or 1 CpuSupportsPrefetch=0 or 1 CpuSupportsSSE=0 or 1 CpuSupportsSSE2=0 or 1 CpuSupports3DNow=0 or 1 CpuSupportsAVX=0 or 1 CpuSupportsFMA3=0 or 1 CpuSupportsFMA4=0 or 1 CpuSupportsAVX2=0 or 1 CpuSupportsAVX512F=0 or 1 This shouldn't be necessary though as the program uses the CPUID instruction to see if the CPU supports these features. The program also supports different code paths for LL testing on a Pentium 4 based on the size of the L2 cache. You can explicitly specify the L2 cache size although this shouldn't be necessary since the program uses the CPUID instruction to determine the L2 cache size. In local.txt enter: CpuL2CacheSize=128 or 256 or 512 CpuL2CacheLineSize=32 or 64 or 128 CpuL2SetAssociative=4 or 8 The program automatically computes the number of CPUs, hyperthreading, and speed. This information is used to calculate how much work to get. If the program did not correctly figure out your CPU information, you can override the info in local.txt: NumCPUs=n CpuNumHyperthreads=1 or 2 CpuSpeed=s Where n is the number of physical CPUs or cores, not logical CPUs created by hyperthreading. Choose 1 for non-hyperthreaded and 2 for hyperthreaded. Finally, s is the speed in MHz. As an alternative to the above, one can set NumPhysicalCores=n in local.txt. This is useful on machines that are somtimes booted with hyperthreading enabled and sometimes without. Normally, the program can detect this situation, but one notable problem case is a dual-CPU hyperthreaded machine, For example, take a dual-CPU quad-core hyperthreaded machine. When booted with hyperthreading enabled this is properly detected as an 8-core hyperthreaded machine. When booted with hyperthreading disabled, this is improperly detected as a 4-core hyperthreaded machine. If you set NumPhysicalCores=8, then the program will set the hyperthreading state properly no matter how the machine is booted. The program used to do factoring and P-1 testing on exponents even if they were not the first entry in worktodo.txt. The rationale was that if the number had a factor, the server could be contacted and another exponent reserved. This avoids the possible scenario where the LL test for the first worktodo.txt line completes, a factor is quickly found for the second line in worktodo.txt and the computer now sits idle until the server can be contacted. This behavior was confusing, especially to newcomers. To restore this old behavior add this line to prime.txt: SequentialWorkToDo=0 One added benefit is time estimates in Test/Status will be more accurate because we'll know no factors will be found and the LL test must be run. The program will restrict how many exponents can be added to worktodo.txt. To override this, change prime.txt: MaxExponents=n By default, ECM will stop when a new factor is found. You can have ECM always stop or always continue searching for factors by using a value of zero or one in prime.txt: ContinueECM=n You can skip the GCD in stage 1 of P-1 factoring with this prime.txt setting: Stage1GCD=0 You can have the program generate save files every n iterations. The files will have a .XXX extension where XXX equals the current iteration divided by n. In prime.txt enter: InterimFiles=n You can have the program output residues every n iterations. The default value is the InterimFiles value. In prime.txt enter: InterimResidues=n By default P-1 work does not delete the save files when the work unit completes. This lets you run P-1 to a higher bound at a later date. You can force the program to delete save files by adding this line to prime.txt: KeepPminus1SaveFiles=0 You can force the program to skip the trial factoring step prior to running a Lucas-Lehmer test. In prime.txt add this line: SkipTrialFactoring=1 You can do "optimal" P-1 factoring of k*b^n+c by adding lines to worktodo.txt: Pfactor=k,b,n,c,how_far_factored,num_primality_tests_saved For example, Pfactor=1,2,10000157,-1,64,2.0 You can reduce the number of times worktodo.txt is read and written by setting in prime.txt: WellBehavedWork=1 This only works for worktodo.txt files that contain only Factor= lines. Only turn this on if you have BIG worktodo.txt files and each Factor= operation does not take much time. You must stop the program before manually editing the worktodo.txt file. In Advanced/Time, you can enter a value between 9994 and 9999 for the exponent to run a QA script. The QA file looks like this: 64511,0,400,99999999,3389BC878321980A Where the first value is the exponent, the second value is the FFT size where zero means use the default FFT size. The third value is the number of iterations to run. The fourth value is the shift count (if the shift count is greater than the exponent a random shift count is used). The final value is the expected 64-bit residue. The dialog box values between 9994 and 9999 force slightly different code to run. 9999 and 9998 run straightforward squaring code, 9998 differs by gathering some standard deviation data. 9997 does squarings also but exercises the general purpose add/sub/mul routines too. 9996 does operations typical during ECM - the final residue won't match but the convolution error data can be useful. 9994 and 9995 probably blow up. Advanced/Time of exponent 9990 forces reading of a file called factors. The program then tries to refind each factor using the factoring code. This is not an efficient way to verify factors as it goes through the entire sieving process and trial factoring many potential factors. You can control which FFT sizes are tested by the torture test. In prime.txt you can set: MinTortureFFT=n MaxTortureFFT=m Where n and m are in "K". The default for n and m is 8 and 1024 which will run tests on FFT sizes rom 8K to 1024K. Set n to 8 and m to 16 and you will run only small FFT sizes. These FFTs will fit in the L2 cache and may be more stressful to the CPU. You can control how many minutes each FFT size is tested by the torture test. In prime.txt set: TortureTime=n The default value is 15 minutes. You can control how much memory the torture test uses. In prime.txt set: TortureMem=n The default value is the larger of your daytime and nighttime memory settings. If this is set to 8MB or less, then the torture test does FFTs in-place. This may be more stressful but could miss memory errors that only occur at a specific physical address. The program normally does round-off error checking every 128 iterations. When you are testing an exponent near the limit of an FFT length, the program does this error checking every iteration. NearFFTLimitPct=value The default value is 0.5 (if the exponent you are testing is within 0.5% of the maximum exponent that can be tested using the current FFT length, then the extra error checking is performed). A value of 0.0 will turn off this extra error checking. You can tune trial factoring performance with several prime.txt settings. Probably only the first parameter below is worth tuning: MaxTFSievePrime=x (default is 155000 on AVX512 CPUs, 145000 on FMA CPUs, 1000000 otherwise) The TF code uses a small prime sieve to eliminate composite trial factors. Set x to the maximum small prime used by this sieve. MaxTFSievePrime is limited to the range of 5,000 to 100,000,000. ThreadsPerTFPool=n (default is number of hyperthreads) When multithreading, set n to the number of threads to group together in a "pool". Pooling ensures that both sieving and trial factoring will be done by threads within the same pool. Thus, if the threads share a cache, locality is increased. For example, on Knights Landing the best setting is 8 because 2 cores with 4 hyperthreads each share an L2 cache. PercentTFSieverThreads=y (default is 50) When multithreading TF, set y to be the percentage of threads in each pool that can be running the small prime sieve. NOTE: If y is set to 100, then pooling is turned off. That is, each thread sieves and then immediately TFs. While this offers perfect locality, it gives slightly worse performance and I cannot explain why. My best theory is that pooling improves usage of the instruction cache. UseMaxSieverAllocs=0, 1, 2,or 3 (default is 3) If UseMaxSieverAllocs is 1 then at least 7 sievers will be allocated, resulting in a 14% reduction in single-threaded sieving. If UseMaxSieverAllocs is 2 then at least 60 sievers will be allocated, resulting in a further 9% reduction in sieving. If UseMaxSieverAllocs is 3 then at least 720 sievers will be allocated, resulting in a further reduction of 7%. The downside is more memory is required and initialization of each of the 16 factoring passes is slower. Allocating a lot of sievers can be detremental when factoring to low bit levels. AlternateTFSieveCount=z (default is 9) On AVX2 and AVX512 cpus, the code can sieve for small primes using either traditional x86 instructions or using AVX2/AVX512 instructions. As sieve primes get larger, the x86 code is faster than the AVX2/AVX512 code. Set z to the number of blocks of small primes to use the AVX2/AVX512 code path. On my AVX2 Skylake cpu the optimal block count is 9. Using too large a value here can result in memory corruption depending on the MaxTFSievePrime setting. You can control how many CPU cores and hyperthreads are used in Advanced/Time. Put these line in prime.txt: AdvancedTimeMinCores=n (default 1) AdvancedTimeMaxCores=n (default all cores) AdvancedTimeCoresIncrement=n (default 1) AdvancedTimeMinHyperthreads=n (default 1) AdvancedTimeMaxHyperthreads=n (default is number of hyperthreads supported by each core) You can disable the display of every iteration's timing when using Advanced/Time leaving just the ending summary. Useful for machines with lots of cores. Put this line in prime.txt: PrintTimedIterations=0 WINDOWS ONLY: When Tray Icon or No Icon is selected the "X" at the right of the title bar will minimize rather than exit. You can make the program exit if you prefer. In prime.txt set: ExitOnX=1 WINDOWS ONLY: You can change the Windows NT/2000/XP service name and service display name. The default for both is "Prime95 Service". In local.txt, set: ServiceName=your service name DisplayName=your service display name You may need to turn off the "Start at Bootup" and exit, change the local.txt file, restart prime95 and turn the "Start at Bootup" option on to make this change effective. Most FFT sizes have several implementations. The program uses throughput benchmark data to select the fastest FFT implementation. The program assumes all CPU cores will be used and all worker threads will be running FFTs. This can be overridden in gwnum.txt: BenchCores=x BenchWorkers=y An example: a 4-core computer running 4 total workers with 3 workers configured for LL testing and one configured for trial factoring. In this scenario, the trial factoring worker does not use much memory bandwidth. You might get a faster FFT implementation selected by setting BenchCores=3 and BenchWorkers=3. Of course, you'll need to generate throughput benchmark data for the 3 cores / 3 workers combination. The program no longer uses hard FFT crossover points. The soft crossovers have two adjustments in prime.txt: SoftCrossover=n SoftCrossoverAdjust=n The first setting controls which exponents are examined. The default value is 0.2. This means that an exponent that is 0.2% above or below an FFT crossover point are tested for the best FFT size to use. A value of 0.0 will turn off this soft FFT crossovers feature. The second setting defaults to 0.000. This controls how aggressive or conservative the program is in selecting the best FFT size. The program normally uses the smaller FFT size if the average roundoff error is below a value in 0.241 to 0.243 range. If you set SoftCrossoverAdjust to say 0.003 then the program will use the smaller FFT size if the average roundoff error is below a value in 0.244 to 0.246 range. This will generate more iterations that generate roundoff error above 0.40 warnings and a time loss returning to the previous save file. It also increases the chance that a deadly roundoff error above 0.6 will occur. On the plus side, using the smaller FFT size each iteration will be a bit quicker. I wouldn't set this adjustment to more than 0.006. If you set SoftCrossoverAdjust to say -0.002, then the program will be more conservative and use the larger FFT size more often. Alexander Kruppa wrote some code that allows the output of ECM stage 1 to be passed to Paul Zimmermann's more efficient GMP-ECM stage 2. This program is usually faster in stage 1. You can activate this feature by entering GmpEcmHook=1 in prime.txt. Then select ECM bound #2 between 1 and bound #1. Results.txt will contain data that can be fed to GMP-ECM for stage 2. In rare cases, users have reported the program can interfere with the performance of some programs such as disk defragmenters and some games. You can pause the program automatically when these programs are running by adding this line to prime.txt: PauseWhileRunning=prog1[n1],prog2[n2],etc The [n1], [n2] values are optional and indicate the number of worker threads to pause when prog1 and prog2 are running. The default value for n1 and n2 is to pause all worker threads. Note that the program will pause if the program name matches any part of the running program's file name. That is "foobar" will match "c:\foobar.exe", "C:\FOOBAR\name.exe", and even "C:\myfoobarprog.exe". Also, if prog1 is "*" the program will pause no matter what. Examples: PauseWhileRunning=*[1] during 6-7/2:00-3:00 PauseWhileRunning=* during 23:00-24:00 else decomp[1],mygame[2] The first example pauses one worker thread on Saturday and Sunday between 2AM and 3AM. The second example pauses all workers between 11PM and 12AM and pauses 1 worker if decomp is running and 2 if mygame is running. LowMemWhileRunning is similar to PauseWhileRunning. This option does not allow workers to use a lot of memory. This example in prime.txt will make sure the program is using the minimum amount of memory possible while photoshop is running: LowMemWhileRunning=Photoshop By default, the program will check the PauseWhileRunning list every 10 seconds. You can adjust the time period with this prime.txt setting: PauseCheckInterval=n where n is the number of seconds between checking which programs are running. LINUX/FREEBSD/APPLE ONLY: In prime.txt you can have mprime suspend one worker when the system load gets above a threshold. This can improve system responsiveness by freeing up memory that mprime is currently using. Mprime bases its decisions using the first average displayed by uptime. In prime.txt, set MaxLoad=a MinLoad=b PauseTime=c For example, if MaxLoad is set to 4.5, mprime will suspend a worker whenever the load average gets above 4.5. If MinLoad is set to 3.1, then mprime will resume one worker when the load average goes below this value. Set PauseTime to how often you want the program to check the load average. This value is in seconds. Normally, the program will unreserve an exponent if it is scheduled to start thirty days after the Test/Primenet Days of work to get value and there are more than four exponents queued up for the worker. You can adjust the days interval by setting in prime.txt: UnreserveDays=n (default 30) where n is the number of days. You can also adjust the number of protected exponents in each worker with this setting in prime.txt: UnreserveExponents=m (default 4) where m is the number of protected exponents. You should increase one or both of these values if you are loading up worktodo.txt with a large amount of work and do not want any of the work to be unreserved. WARNING: There have been several reports of a bug in prime95's calculations for UnreserveDays. Thus, we recommend using UnreserveExponents to prevent unexpected unreserving of work, WINDOWS ONLY: By default, Prime95 uses RAS routines to determine if your modem is connected to the Internet. Microsoft now prefers the InternetGetConnectedState call in WININET.DLL. To use this method instead of the RAS routines, add this line to prime.txt: AlternateModemDetection=1 LINUX ONLY: Mprime supports 4 different ways of checking if your computer is connected to the internet. Set RouteRequired=n in [PrimeNet] section of prime.txt. The following values of n are supported. The last entry is what happens if RouteRequired is not given. 0: Assume computer is always connected 1: Assume connected if there is an entry in /proc/net/route other than for the loopback device. 2: Assume connected if there is an entry in /proc/net/route with a netmask of 00000000. none: Same as 2 except that if /proc/net/route is unreadable mprime assumes computer is connected. If you are running on a laptop or in a hot room and you want to slow the program down to reduce heat, then you can add this line to prime.txt: Throttle=n where n is the percentage of time the program should run. For example, Throttle=40 means the program will run 40% and be idle 60% of the time. Since P-1 stage 2 runs faster with more memory available you can have the program only run stage 2 at night when more memory is available. In prime.txt set: OnlyRunStage2WithMaxMemory=1 You can control the maximum prime.log file size. The default is 2MB. Add this line to prime.txt to change the default: MaxLogFileSize=n You can use the old sockets communication code instead of the robust CURL library. Add this line to the [PrimeNet] section of prime.txt: UseCURL=0 When not using CURL , you can control what type of URLs are used to contact the PrimeNet server. In the [Primenet] section of prime.txt enter: UseFullURL=n where n is 0 for use relative URLs, 1 for use full URLs, 2 for try full URL and if an error is returned try a relative URL. The default setting is 2. Note that a full URL is always sent when using a proxy server. When not using CURL and using a proxy server, the program sends the port number in http strings. That is the ":80" in "http://mersenne.org:80/cgibin_text". At least one proxy server only works if the ":80" is not present. In this case, set SendPortNumber=0 in the [Primenet] section of prime.txt file. When not using CURL, you can add additional information to the HTTP request sent to the server. This might be useful in some tough firewall setups. In the [Primenet] section of prime.txt enter: OtherGetInfo=string where string is any text up to 256 bytes. The benchmarking dialog box lets you control many options, yet there are a few more that are only available using the settings below: BenchOutputTopology=0 or 1 (default is 1) BenchOddWorkers=0 or 1 (default is 1) BenchDummyWorkers=0 or 1 (default is 0) BenchOutputTopology can be used to disable printing the machine topology in results.txt. BenchOddWorkers can be used to disable throughput benchmarks when number of cores is not a multiple of the number of workers (e.g. 3 cores on 2 workers). BenchDummyWorkers is used to enable starting dummy workers while benchmarking. The theory is that keeping the other CPU cores busy will prevent "turbo boost" from kicking in. This may lead to more consistent benchmarks that are more indicitive of what will happen running this program in a real-world, all-cores-busy environment. Option not available in throughput benchmarks. Since benchmark dialog boxes now accept a comma separated list of ranges, this next setting is now obsolete. When benchmarking on CPUs with lots of cores, the volume of output can be overwhelming. You can limit which core counts are benchmarked using the prime.txt settings below: BenchMinCores=n (default 1) BenchMaxCores=n (default all cores) BenchCoresIncrement=n (default 1) Similarly, for thoughput benchmarks, these prime.txt settings can reduce output: BenchMinWorkers=n (default 1) BenchMaxWorkers=n (default all cores) BenchWorkersIncrement=n (default 1) The program automatically runs benchmarks to aid in optimal FFT selection. It looks at worktodo.txt for upcoming exponents to test and the amount of benchmarking already done to decide if more benchmarks are needed. You can disable this feature by adding to prime.txt: AutoBench=0 If you want to run the program on several machines this is typically done by carrying the program and files around on portable media such as a floppy or USB memory stick. In this case, you need to defeat the program's automatic detection of hardware changes. To do this, in prime.txt set FixedHardwareUID=1 Adding 32 to the MergeWindows value in prime.txt suppresses screen output of the "Comm thread", "Main thread", "Work thread" prefix. The Memory=n setting in local.txt refers to the total amount of memory the program can use. You can also put this in the [Worker #n] section to place a maximum amount of memory that one particular worker can use. You can set MaxHighMemWorkers=n in local.txt. This tells the program how wany workers are allowed to use lots of memory. This occurs doing stage 2 of P-1 or ECM on medium-to-large numbers. Default is available memory / 200MB. You can change the amount of information the program outputs while setting affinities. AffinityVerbosity=0 or 1 (default is 1) AffinityVerbosityTorture=0 or 1 (default is 0) AffinityVerbosityTime=0 or 1 (default is 0) AffinityVerbosityBench=0 or 1 (default is 0) These settings are made in prime.txt. Zero for less output, one for more output. The first setting is for all normal work (LL, TF, ECM, P-1, PRP). The others are for torture testing, Advanced/Time, and benchmarking. One user reported problems with setting affinity on machines with more than 64 cores. Though this problem has been addressed, the following options may prove helpful if similar issues occur in the future: EnableSetPriority=0 or 1 (default is 1) EnableSetAffinity=0 or 1 (default is 1) Set these options in prime.txt One can override the default affinity settings with the Affinity= option in local.txt. Suppose you want to change which logical CPUs the second worker window uses. Here are some example lines you might add to the "[Worker #2]" section of local.txt (the logical CPUs use the zero-based numbering scheme for PU# returned by hwloc which you can see in results.txt by doing a benchmark): Affinity=3,6,9 Run main worker thread on logical CPU #3, run two aux threads on logical CPUs #6 & #9 Affinity=3-4,5-6 Run main worker thread on logical CPUs #3 & #4, run aux thread on logical CPUs #5 & #6 Affinity={3,5,7},{4,6} Run main worker thread on logical CPUs #3, #5, & #7, run aux thread on logical CPUs #4 & #6 Affinity=(3,5,7),(4,6) Run main worker thread on logical CPUs #3, #5, & #7, run aux thread on logical CPUs #4 & #6 Affinity=[3,5-7],(4,6) Run main worker thread on logical CPUs #3, #5, #6, & #7, run aux thread on logical CPUs #4 & #6 In the prime.txt file, the DaysBetweenCheckin value can be set to any value between 0.04 and 7.0. Some SeventeenOrBust users want to send updates hourly. In local.txt, add the line UseLargePages=1 to attempt using 2MB pages under Windows Vista and later. Warning: these pages will never be swapped out. Thus, using this option could negatively impact the performance of other applications. Also, you'll need to have the "Lock Pages in Memory" privilege to use this option. When looking for probable primes, the following 4 options are available in prime.txt: SilentVictoryPRP=0 or 1 (default is 1) OutputPrimes=0 or 1 (default is 0) OutputComposites=0 or 1 (default is 0) OutputJSON=0 or 1 (default is 1) Setting SilentVictoryPRP=0 will cause prime95 to make a continuous noise if a PRP is found. Setting OutputPrimes=1 will cause prime95 to output a non-JSON message for probable primes to results.txt. Setting OutputComposites=1 will cause prime95 to output a non-JSON message for composite PRP tests to results.txt. Setting OutputJSON=0 will cause prime95 to not output the JSON message for PRP tests to results.txt. When PRPing k*b^n+c, there are two types of highly-reliable error checking available. Gerbicz error checking is available when b=2 and there are either no known factors or residue type (see following paragraphs) is 5. It almost guarantees a correct result at an overhead of about 0.2%. The second high-reliability error check is to run the PRP twice comparing residues along the way. Obviously, this doubles the runtime. To select which error checking is performed or to disable error-checking, use the following setting in prime.txt: PRPErrorChecking=0 or 1 or 2 (default is 1) Set to zero to disable high-reliability error checking. Set to 1 to perform Gerbicz high-reliability error checking whenever possible, otherwise no error checking. Set to 2 to do Gerbicz high-reliability error checking whenever possible, otherwise do the much slower error check of doing each iteration twice and periodicly comparing residues. When doing highly-reliable error checking, the interval between compares can be controlled with these two settings in prime.txt: PRPGerbiczCompareInterval=n (default is 1000000) PRPDoublecheckCompareInterval=n (default is 100000) Reducing the interval will reduce how far the program "rolls back" when an error is detected. It will also increase the overhead associated with error-checking. NOTE: For technical reasons, PRPGerbiczCompareInterval is rounded to the nearest perfect square. ALSO NOTE: The program automatically adjusts the Gerbicz interval downward when an error is detected. This will reduce the amount of time "lost" rolling back to the last verified good iteration after an error is detected. Over time, the Gerbicz interval will be adjusted back upward after many successful compares. You can change the default base used in PRP tests. In prime.txt: PRPBase=n (default 3) The base can also be changed for individual PRP tests in worktodo.txt entries making this option obsolete. PRP supports 5 types of residues for compatibility with other PRP programs. If a is the PRP base and N is the number being tested, then the residue types are: 1 = 64-bit residue of a^(N-1), a traditional Fermat PRP test used by most other programs 2 = 64-bit residue of a^((N-1)/2) 3 = 64-bit residue of a^(N-c+1), only available if b=2 4 = 64-bit residue of a^((N-c+1)/2), only available if b=2 5 = 64-bit residue of a^(N*known_factors-1), same as type 1 if there are no known factors To control which residue type is generated, use this setting in prime.txt: PRPResidueType=n (default is 5) The residue type can also be set for PRP tests in worktodo.txt entries making this option somewhat obsolete. When PRPing k*b^n+c and b=2, there are some optimizations possible that reduce the number of small constant multiplications. Although there should be no reason to turn off these optimizations, it can be done with this setting in prime.txt: PRPStraightForward=1 (default is 0) NOTE: Selecting the straight forward (no optimization) code path disables the very efficient and powerful Gerbicz error checking. WINDOWS ONLY: You can have prime95 pause when the battery level gets low. This will allow you to charge the battery faster. Add the line BatteryPercent=n to prime.txt, where n is a number from 0 to 100. The default value is zero. LINUX/FREEBSD/APPLE ONLY: In prime.txt you can have set the nice level. By default, on startup mprime automatically sets the program to nice priority. This isn't really necessary since worker threads are usually set to run at a much lower priority. However, sysadmins might be alarmed to see a CPU intensive program not running at nice priority when they execute a ps command (it takes a more complicated ps command to see that the CPU intensive threads are running at a lower priority). You can change the nice level in prime.txt with the line: Nice=n where n is the nice level. The default nice level is 10. In linux you can select a value from -20 to +19. In FreeBSD and Mac OS X you can select a value between -20 and 20. Higher numbers represent a "nicer" program (lower priority). In all OSes, a zero nice level means run at the normal priority.