YCruncher starting up slowly causing CoreCycler to treat it as an instability?

[thoraine]

I am running CoreCycler on my 9800X3D as admin, using YCruncher as the stress tester. When YCruncher is loading up, it seems to print so console really slowly, one word at a time, causing CoreCycler to sometimes detect it as an instability because no CPU load was detected. Not sure why it's outputting to console so slowly. Is this an issue?

My config

# Config file for CoreCycler
# You can always find the default config file in configs\default.config.ini as a reference


# This is a copy of the default.config.ini in the /configs/ directory
# It contains all the available settings with comments and examples of what they do
# You can replace this file with your own version, and any setting that does not show up
# here will use its default value instead



# General settings
[General]

# Use a predefined config file instead of this one
# If this value is set, it will use the content from the file provided, overwriting all settings further below
# (which means that if you use this setting, you can safely remove all other settings in the "main" config.ini file)
# If this value is empty or invalid, the other settings from this file will apply
#
# It's useful for quickly switching between various configs, and you can find some predefined config files in the "configs" directory
# The setting uses a relative path from the location where this file is located in
# Example:
# useConfigFile = configs\quick-initial-test.yCruncher.config.ini
#
# Default: (empty)
useConfigFile =


# The program to perform the actual stress test
# The following programs are available:
# - PRIME95
# - AIDA64
# - YCRUNCHER
# - YCRUNCHER_OLD
# - LINPACK
# You can change the test mode and options for each stress test program in the respective [section] further down
# Note: For AIDA64, you need to manually download and extract the portable ENGINEER version and put it
#       in the /test_programs/aida64/ folder
#       AIDA64 is somewhat sketchy as well
# Note: There are two versions of y-cruncher included, which you can select with either "YCRUNCHER" or "YCRUNCHER_OLD"
#       The "old" version uses the binaries and test algorithms that were available before version 0.8 of y-cruncher
#       See the comments in the [yCruncher] section for a more detailed description
#
# Default: PRIME95
stressTestProgram = YCRUNCHER


# Set the runtime per core
# You can define a specific runtime per core, by entering a numeric value in seconds,
# or use 'h' for hours, 'm' for minutes and 's' for seconds
# Examples: 360 = 360 seconds
#           1h4m = 1 hour, 4 minutes
#           1.5m = 1.5 minutes = 90 seconds
#
# Automatic runtime:
# You can also set it to "auto", in which case it will perform one "full" run for each core
# For Prime95, it will wait until all of the FFT sizes in the selected preset have been tested and
# will then continues to the next core and start again
# For y-cruncher the "auto" setting will wait until all selected tests have been finished for a core
# and will then continue to the next core
# If logging has been disabled for y-cruncher, it will fall back to 10 minutes per core
# For Aida64 the "auto" setting will default to 10 minutes per core
#
# Below are some examples of the runtime for one iteration of Prime95 for the various tests on my 5900X with one thread
# The first iteration is also usually the fastest one
# Selecting two threads usually takes *much* longer than one thread for one iteration in Prime95
# - Prime95 "Smallest":     4K to   21K - [SSE] ~3-4 Minutes   <|> [AVX] ~8-9 Minutes    <|> [AVX2] ~8-10 Minutes
# - Prime95 "Small":       36K to  248K - [SSE] ~4-6 Minutes   <|> [AVX] ~14-19 Minutes  <|> [AVX2] ~14-19 Minutes
# - Prime95 "Large":      426K to 8192K - [SSE] ~18-22 Minutes <|> [AVX] ~37-44 Minutes  <|> [AVX2] ~38-51 Minutes
# - Prime95 "Huge":      8960K to   MAX - [SSE] ~13-19 Minutes <|> [AVX] ~27-40 Minutes  <|> [AVX2] ~33-51 Minutes
# - Prime95 "All":          4K to   MAX - [SSE] ~40-65 Minutes <|> [AVX] ~92-131 Minutes <|> [AVX2] ~102-159 Minutes
# - Prime95 "Moderate":  1344K to 4096K - [SSE] ~7-15 Minutes  <|> [AVX] ~17-30 Minutes  <|> [AVX2] ~17-33 Minutes
# - Prime95 "Heavy":        4K to 1344K - [SSE] ~15-28 Minutes <|> [AVX] ~43-68 Minutes  <|> [AVX2] ~47-73 Minutes
# - Prime95 "HeavyShort":   4K to  160K - [SSE] ~6-8 Minutes   <|> [AVX] ~22-24 Minutes  <|> [AVX2] ~23-25 Minutes
#
# Default: 6m
runtimePerCore = auto


# Periodically suspend the stress test program
# This can simulate load changes / switches to idle and back
# Setting this to 1 will periodically suspend the stress test program, wait for a bit, and then resume it
# You should see the CPU load and clock speed drop significantly while the program is suspended and rise back up again
# Note: This will increase the runtime of the various stress tests as seen in the "runtimePerCore" setting by roughly 10%
#
# Default: 1
suspendPeriodically = 1


# The test order of the cores
# Available modes:
# Default:    On CPUs with more than 8 physical cores: 'Alternate'. Otherwise 'Random'
# Alternate:  Alternate between the 1st core on CCD1, then 1st on CCD2, then 2nd on CCD1, then 2nd on CCD2, etc.
#             This should distribute the heat more evenly and possibly allow for higher clocks on CPUs with 2 CCDs
# CorePairs:  This will create "pairs" of cores, so e.g. core 0 - core 1, core 0 - core 2, ... core 0 - core max,
#             up to core max - core 0, core max - core 1, core max - core max-1
#             This allows for testing if there is any problem when switching from a specific core to another
# Random:     A random order
# Sequential: Cycle through the cores in numerical order
#
# You can also define your own testing order by entering a list of comma separated values.
# The list will be processed as provided, which means you can test the same core multiple times per iteration.
# Do note however that the "coresToIgnore" setting still takes precedence over any core listed here.
# The enumeration of cores starts with 0
# Example: 5, 4, 0, 5, 5, 7, 2
#
# Default: Default
coreTestOrder = Default


# Skip a core that has thrown an error in the following iterations
# If set to 0, this will test a core in the next iterations even if has thrown an error before
#
# Default: 1
skipCoreOnError = 1


# Stop the whole testing process if an error occurred
# If set to 0 (default), the stress test programm will be restarted when an error
# occurs and the core that caused the error will be skipped in the next iteration
#
# Default: 0
stopOnError = 0


# The number of threads to use for testing
# You can only choose between 1 and 2
# If Hyperthreading / SMT is disabled, this will automatically be set to 1
# Currently there's no automatic way to determine which core has thrown an error
# Setting this to 1 causes higher boost clock speed (due to less heat)
#
# Default: 1
# Maximum: 2
numberOfThreads = 1


# Use only one thread for load generation, but assign this thread to both virtual (logical) cores
# This way the Windows Scheduler or the internal CPU scheduler will choose which of both virtual CPU is used
# This may lead to additional stress situation otherwise not possible
# This setting has no effect if Hyperthreading / SMT is disabled or if numberOfThreads = 2
#
# Default: 0
assignBothVirtualCoresForSingleThread = 0


# The max number of iterations
# High values are basically unlimited (good for testing over night)
#
# Default: 10000
maxIterations = 10000


# Ignore certain cores
# Comma separated list of cores that will not be tested
# The enumeration of cores starts with 0
#
# Example: coresToIgnore = 0, 1, 2
# Default: (empty)
coresToIgnore =


# Restart the stress test process when a new core is selected
# This means each core will perform the same sequence of tests during the stress test
# This setting is best combined with runtimePerCore = auto
# Note: The monitor doesn't seem to turn off when this setting is enabled
#
# Important note:
# One disadvantage of this setting is that it has the potential to limit the amount of tests that the stress test program
# can run.
# In Prime95 for example, each FFT size will run for roughly 1 minute (except for very small ones), so if you want to make
# sure that Prime95 runs all of the available FFT sizes for a setting, you'll have to extend the "runtimePerCore" setting
# from the default value to something higher.
# For example the "Huge"/SSE preset has 19 FFT entries, and tests on my 5900X showed that it roughly takes 13-19 Minutes
# until all FFT sizes have been tested. The "Large"/SSE seems to take between 18 and 22 Minutes.
# I've included the measured times in the comment for the "runtimePerCore" setting above.
# This is why setting runtimePerCore = auto is beneficial when using this setting, to make sure every test is performed
# for every core.
#
# If this setting is disabled, a new core will very likely start with a different test / FFT size than the previous one.
# For longer testing periods (e.g. over night), the tested FFT sizes / algorithms will even out eventually, but if you
# want to make sure that each core is tested in exactly the same way, you should enable this setting.
#
# Default: 0
restartTestProgramForEachCore = 0


# Set a delay between the cores
# If the "restartTestProgramForEachCore" flag is set, this setting will define the amount of seconds between the end of
# the run of one core and the start of another
# If "restartTestProgramForEachCore" is 0, this setting has no effect
# Using this setting may help your CPU to cool down a little between cores, which could result in slightly higher
# core clocks at the start of the test (which could help in identifying instabilities)
#
# Default: 15
delayBetweenCores = 15


# Beep on a core error
# Play a beep when a core has thrown an error
#
# Default: 1
beepOnError = 1


# Flash on a core error
# Flash the window/icon in the taskbar when a core has thrown an error
#
# Default: 1
flashOnError = 1


# Check for WHEA errors
# If this is enabled, CoreCycler will periodicall check the Windows Event Log for WHEA errors
# These WHEA errors do not necessarily cause or show up together with a stress test error, but are indicative
# of an unstable overclock/undervolt
# A stable system should not produce any WHEA errors/warnings
#
# Default: 1
lookForWheaErrors = 1


# Treat a WHEA Warning Event Log entry as an error
# If this is enabled, a WHEA warning (Event Id 19, "corrected hardware error") will be treated as a "real" error
# The testing on the core will be stopped and continued on the next one
# However only if the APIC ID from the WHEA message matches the core that was currently tested, otherwise
# only a warning will be displayed
#
# Default: 1
treatWheaWarningAsError = 1




# Prime95 specific settings
[Prime95]

# The test modes for Prime95
# SSE       Lightest load on the processor, lowest temperatures, highest boost clock
# AVX       Medium load on the processor, medium temperatures, medium boost clock
# AVX2      Heavy load on the processor, highest temperatures, lowest boost clock
# AVX512    Only available for certain CPUs (Ryzen 7000, some Intel Alder Lake, etc)
# CUSTOM    You can define your own settings for Prime. See the "customs" section further below
#
# Default: SSE
mode = SSE


# The FFT size preset to test for Prime95
# These are basically the presets as present in Prime95, plus an additional few
# Note: If "mode" is set to "CUSTOM", this setting will be ignored
# Smallest         4K to   21K - Prime95 preset text: "tests L1/L2 caches, high power/heat/CPU stress"
# Small           36K to  248K - Prime95 preset text: "tests L1/L2/L3 caches, maximum power/heat/CPU stress"
# Large          426K to 8192K - Prime95 preset text: "stresses memory controller and RAM" (although dedicated memory stress testing is disabled here by default!)
# Huge          8960K to   MAX - Anything beginning at 8960K up to the highest FFT size (32768K for SSE/AVX, 51200K for AVX2, 65536K for AVX512)
# All              4K to   MAX - 4K to up to the highest FFT size (32768K for SSE/AVX, 51200K for AVX2, 65536K for AVX512)
# Moderate      1344K to 4096K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
# Heavy            4K to 1344K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
# HeavyShort       4K to  160K - special preset, recommended in the "Curve Optimizer Guide Ryzen 5000"
#
# You can also define a single FFT size by just entering the value, or your own range by entering two FFT sizes joined by a hyphen, e.g 36-1344
#
# Default: Huge
FFTSize = Huge




# y-cruncher specific settings
# These apply to both "YCRUNCHER" and "YCRUNCHER_OLD"
[yCruncher]

# The test modes for y-cruncher
# y-cruncher offer various test modes (binaries/algorithms), that require different instruction sets to be available
# See the \test_programs\y-cruncher\Binaries\Tuning.txt file for a detailed explanation
#
# Automatic selection vs. manual selection:
# You can use the "auto" setting, in which case y-cruncher will automatically decide which binary it chooses for your CPU
# If instead you want to manually select a specific binary, you can see the list below:
#
# Test Mode Name       Automatic Selection For             Required Instruction Set
# --------------       -----------------------             ------------------------
# "04-P4P"             Intel Pentium 4 Prescott            SSE, SSE2, SSE3
# "05-A64 ~ Kasumi"    AMD Athlon 64                       x64, SSE, SSE2, SSE3
# "08-NHM ~ Ushio"     Intel Nehalem                       x64, SSE, SSE2, SSE3, SSSE3, SSE4.1
# "11-SNB ~ Hina"      Intel Sandy Bridge                  x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX
# "12-BD2 ~ Miyu"      AMD Piledriver                      x64, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, ABM, FMA3
# "13-HSW ~ Airi"      Intel Haswell                       x64, ABM, BMI1, BMI2, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "14-BDW ~ Kurumi"    Intel Broadwell                     x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "17-SKX ~ Kotori"    Intel Skylake X [AVX512]            x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ)
# "17-ZN1 ~ Yukina"    AMD Zen 1 Summit Ridge              x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "18-CNL ~ Shinoa"    Intel Cannon Lake [AVX512]          x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI)
# "19-ZN2 ~ Kagari"    AMD Zen 2 Matisse (and Zen 3)       x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2
# "22-ZN4 ~ Kizuna"    AMD Zen 4 Raphael [AVX512]          x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI/GFNI)
# "24-ZN5 ~ Komari"    AMD Zen 5 Granite Ridge [AVX512]    x64, ABM, BMI1, BMI2, ADX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, FMA3, AVX2, AVX512-(F/CD/VL/BW/DQ/IFMA/VBMI/VBMI2/GFNI)
#
# If you let y-cruncher run on its own, it will automatically select one of these test modes depending on the processor it detects,
# this is the "Automatic Selection For" column in the table above
# For CoreCycler however you need to select a specific test mode to be run
# As a general rule you can assume that the less instructions are required, the less heat a test mode will produce, and therefore the boost clocks can go higher
# On the other hand, if you actually want to test all the transistors in your chip, you will need to select a test mode that covers all of the available instruction sets
# So it's advised that you test both with the least and the highest amount of available instruction sets for your processor to cover all use cases
#
# Be aware that test modes that require AVX512 instructions will not work on processors that do not support AVX512!
# It will either outright crash or simply not start
#
# A quick overview:
# "04-P4P" produces the least amount of heat and should therefore produce the highest boost clock on most tests
# "14-BDW ~ Kurumi" is the test that y-cruncher itself would default to if you run it on an Intel CPU up to at least 14th gen
# "19-ZN2 ~ Kagari" is the test that y-cruncher itself would default to for Zen 2/3 (Ryzen 3000/5000)
# "22-ZN4 ~ Kizuna" is the test that y-cruncher itself would default to for Zen 4 (Ryzen 7000) and uses AVX512 instructions
# "24-ZN5 ~ Komari" is the test that y-cruncher itself would default to for Zen 5 (Ryzen 9000) and uses AVX512 instructions
#
# User experience seems to indicate that "19-ZN2 ~ Kagari" is pretty good for testing stability, even for Zen 4 (Ryzen 7000) CPUs
# It is unclear yet how Zen 5 / Ryzen 9000 CPUs will turn out
# So as a recommendation, use "04-P4P" for low load testing and "19-ZN2 ~ Kagari" for higher/AVX2 load scenarios
# As "14-BDW ~ Kurumi" is the test mode that y-cruncher chooses for Intel CPUs, it is not entirely clear if this or "19-ZN2 ~ Kagari"
# is the better test for AVX/AVX2 loads on Intel CPUs. At least they share the same instruction sets, so you might need to check for yourself
#
#
# When using the old y-cruncher version ("YCRUNCHER_OLD" selected as the stress test), there's an additional test mode you can use:
#
# Test Mode Name       Automatic Selection For       Required Instruction Set
# --------------       -----------------------       ------------------------
# "00-x86"             Legacy x86                    86/IA-32 since Pentium (BSWAP, CMPXCHG, CPUID, RDTSC, possibly others...)
#
# It is not available anymore in the recent version of y-cruncher, which is now the default one ("YCRUNCHER"), so if you want to use a test
# with the least used instruction sets for low loads, you would need to switch to "YCRUNCHER_OLD" as the stress test
# Also note that if you use "YCRUNCHER_OLD", you will also need to adapt the "tests" setting, as the old version uses different names
#
# Furthermore the "12-BD2 ~ Miyu" test mode is named "11-BD1 ~ Miyu" in "YCRUNCHER_OLD"
#
# Default: 04-P4P
mode = auto


# Set the test algorithms to run for y-cruncher
# y-crunchers offers various different test algorithms that it can run, here you can select which ones it should use
# Tag     Test Name                     Component        CPU------Mem
# ---     ---------                     ---------        ------------
# BKT     Basecase + Karatsuba          Scalar Integer   -|--------
# BBP     BBP Digit Extraction          AVX2 Float       |---------
# SFT     Small In-Cache FFTv3          AVX2 Float       -|--------
# SFTv4   Small In-Cache FFTv4          AVX2 Float       -|--------
# SNT     Small In-Cache N63            AVX2 Integer     --|-------
# SVT     Small In-Cache VT3            AVX2 Float       --|-------
# FFT     Fast Fourier Transform (v3)   AVX2 Float       ---------|
# FFTv4   Fast Fourier Transform (v4)   AVX2 Float       ---------|
# N63     Classic NTT (v2)              AVX2 Integer     ---|------
# VT3     Vector Transform (v3)         AVX2 Float       ----|-----

#
# Use a comma separated list
# Default: BKT, BBP, SFT, SFTv4, SNT, SVT, FFT, FFTv4, N63, VT3
tests = SFTv4, SNT, SVT, FFTv4, N63, VT3


# Set the test algorithms to run for the "old" version of y-cruncher ("YCRUNCHER_OLD" selected as the stress test)
# This older version (v0.7.10.9513) has a different set of tests to choose from
# Tag   Test Name               Component         CPU------Mem
# ---   ---------               ---------         ------------
# BKT   Basecase + Karatsuba    Scalar Integer    -|--------
# BBP   BBP Digit Extraction    Floating-Point    |---------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# SFT   Small In-Cache FFT      Floating-Point    -|--------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# FFT   Fast Fourier Transform  Floating-Point    ---------|    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# N32   Classic NTT (32-bit)    Scalar Integer    -----|----    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# N64   Classic NTT (64-bit)    Scalar Integer    ---|------    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# HNT   Hybrid NTT              Mixed Workload    -----|----
# VST   Vector Transform        Floating-Point    ------|---    depending on the selected mode uses SSE, AVX, AVX2 or AVX512
# C17   Code 17 Experiment      AVX2/512 Mixed    ---|------    depending on the selected mode uses AVX2 or AVX512
#
# Important:
# "C17" (Code 17 Experiment) will only work with a AVX2 and AVX512 workload (so with mode "13-HSW ~ Airi" and above)
#
# Use a comma separated list
# Default: BKT, BBP, SFT, FFT, N32, N64, HNT, VST
#tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST


# Set the duration in seconds for each test in y-cruncher
# The duration for each individual test selected above in the "tests" setting
# Note: not the total runtime
#
# Default: 60
testDuration = 60


# Memory allocation for y-cruncher
# This allows you to customize the allocated memory for y-cruncher
# Set the value in bytes or use a "short" notation like e.g. "64MB"
# The default setting uses 13.4 MB (13418572 bytes, 12.8 MiB) for one resp. 26.7 MB (26567600 bytes, 25.3 MiB) for two threads
# Note the difference between "MB" (1000 kilobyte = 1000*1000 byte) and "MiB" (1024 kibibyte = 1024*1024 byte)
#
# Default: Default
memory = Default


# Enable or disable the custom logging wrapper for y-cruncher
# We are using the helpers/WriteConsoleToWriteFileWrapper.exe executable to capture the output of y-cruncher and write it to a file
# It is using the Microsoft Detours C++ library to do so
# Here you can disable this behaviour and revert back to the original y-cruncher execution
#
# It is strongly recommended to leave this setting enabled, unless you're experiencing problems with it!
#
# Default: 1
enableYCruncherLoggingWrapper = 1




# Aida64 specific settings
[Aida64]

# The test modes for Aida64
# Note: "RAM" consumes basically all of the available memory and makes the computer pretty slow
#       You can change the amount of RAM being used / tested with the "maxMempory" setting below
# CACHE: Starts Aida64 with the "Cache" stress test
# CPU:   Starts Aida64 with the "CPU" stress test
# FPU:   Starts Aida64 with the "FPU" stress test
# RAM:   Starts Aida64 with the "Memory" stress test
# You can also combine multiple stress tests like so: CACHE,CPU,FPU
#
# Default: CACHE
mode = CACHE


# Use AVX for Aida64
# This enables or disables the usage of AVX instructions during Aida64's stress tests
#
# Default: 0
useAVX = 0


# The maximum memory allocation for Aida64
# Sets the maximum memory usage during the "RAM" stress test in percent
# Note: Setting this too high can cause your Windows to slow down to a crawl!
#
# Default: 90
maxMemory = 90




# Linpack specific settings
[Linpack]

# Which version of Linpack to use
# There are four different choices available
# 2018: Intel Linpack version 2018.0.3.1 - this is the same version as used in Linpack Xtreme 1.1.5
# 2019: Intel Linpack version 2019.0.3.1
# 2021: Intel Linpack version 2021.4.1.0 - this version always uses FASTEST (AVX2)
# 2024: Intel Linpack version 2024.2.1.0 - this version always uses FASTEST (AVX2)
#
# Version 2018 and 2019 are the only ones where you can set the mode to anything but "FASTEST"
# These two version also run slightly faster (more GFlops) on AMD processors than the newer versions when set to "FASTEST"
# But the newer versions might have additional optimizations that are missing in the older ones
#
# Default: 2018
version = 2018


# The test mode for Linpack
# You can choose between five settings:
# SLOWEST
# SLOW
# MEDIUM
# FAST
# FASTEST
# These settings define how fast one iteration will be completed (how many GFlops you'll see and the time it takes)
# It should also affect which instruction set is being used, e.g. FASTEST should enable AVX2, while FAST should
# use AVX
# I'm not entirely sure what instructions the other settings use exactly, but I did see a difference in the runtime
# and GFlops for these settings
# Here are some examples (not comparable to anything else, since determined with a custom overclock/undervolt setting):
#             Ryzen 5900X 1 Thread         Intel 14900KF 1 Thread
#             GFlops    Time    Temp       GFlops    Time    Temp
# SLOWEST     ~21       ~126s   ~67°C      ~28       ~96s    ~64°C
# SLOW        ~25       ~105s   ~71°C      ~28       ~94s    ~65°C
# MEDIUM      ~27       ~99s    ~71°C      ~30       ~89s    ~66°C
# FAST        ~45       ~59s    ~75°C      ~51       ~52s    ~66°C
# FASTEST     ~66       ~40s    ~76°C      ~78       ~34s    ~69°C
#
# As you can see, the setting has a more pronounced effect on AMD CPUs, but Intel CPUs are affected as well, just not
# as much on the slower settings
# This setting makes use of an undocumentented environment variable (MKL_DEBUG_CPU_TYPE) for Intel's MKL library
# (Math Kernel Library), which is interally used by Linpack
#
# Default: MEDIUM
mode = MEDIUM


# Memory allocation for Linpack
# Set the amount of memory to use with Linpack
# Enter the value either as a string like 500MB, 2GB, 4GB, etc
# Or as a raw value in bytes, e.g. 250000000 (which would equal "250MB")
# Note the difference between "MB" (1000 kilobyte = 1000*1000 byte) and "MiB" (1024 kibibyte = 1024*1024 byte)
# Also be aware that the memory size directly influences the time it takes to run one test, here are some examples:
# Setting    Sample runtime    Sample runtime
#               with MEDIUM      with FASTEST
# 100MB                  1s              0.5s
# 250MB                  4s                2s
# 500MB                 12s                5s
# 750MB                 23s                9s
# 1GB                   35s               14s
# 2GB                   99s               40s
# 4GB                  287s              117s
# 6GB                  534s              216s
# 30GB         unknown, >1h        not tested    (I aborted after over an hour)
# Also note that choosing more memory doesn't necessarily help in finding CPU related problems
# It may help identifying RAM or IMC (Internal Memory Controller) related issues
#
# Default: 2GB
memory = 2GB




# Settings for the Automatic Test Mode
[AutomaticTestMode]

# Enable the automatic test mode
# If you enable this setting, the script will automatically adjust the Curve Optimizer or voltage offset values
# when an error occurs
#
# For Ryzen CPUs it uses "ryzen-smu-cli", which is included in the /tools/ryzen-smu-cli/ directory
# For Intel, it uses "IntelVoltageControl", which allows you to set a voltage offset (also included in the /tools/ directory)
#
# Note that this will only INCREASE the Curve Optimizer / voltage offset values, i.e. it will try to make the settings
# more stable, it will never push the settings more into the negative
# Also note that enabling this setting will require the script to be run with administrator privileges
# And lastly, enabling it will set "skipCoreOnError" to 0 and "stopOnError" to 0 as long as the limit has not been reached
#
# IMPORTANT: The automatically adjusted Curve Optimizer / voltage offset values are NOT permanent, so after a regular reboot they
#            will not be applied anymore
#            If you want to permanently set these values, you will need to set them in the BIOS, or use a startup script to
#            set them on every Windows start (see the .txt files for ryzen-smu-cli resp. IntelVoltageControl in the /tools
#            directory for an explanation of the various settings)
#
# Default: 0
enableAutomaticAdjustment = 1


# The starting Curve Optimizer / voltage offset values
# You can provide the Curve Optimizer / voltage offset starting values here, or let them be automatically detected
# If you specify values here, they will overwrite your currently applied CO / voltage offset settings
# If you leave the value blank or set it to "CurrentValues" or "Default", it will try to automatically detect your current settings
#
# For Ryzen, you can use the "Minimum" value to automatically set the values to their respective minimum Curve Optimizer values
# (-30 for Ryzen 5000 and -50 for Ryzen 7000 and upwards)
#
# Use a comma separated list or define a single value that will be applied to all cores
# You can also use spaces or "|" to separate the cores
# For Intel, this currently only really supports a single voltage offset that is applied to each core
# For Ryzen, you can define the Curve Optimizer value for each core
#
# Note: For Ryzen, the minimum possible Curve Optimizer value is defined by your CPU
#       -30 is the minimum value for Curve Optimizer on Ryzen 5000, and -50 for Ryzen 7000 and upwards
#       (and each point of Curve Optimizer equals around 3-5 millivolts)
# Note: For Intel, the values are provided in millivolts, so e.g. -120 for an undervolt of -0.120v
#
# IMPORTANT: Use a negative sign if you want negative CO values / a negative voltage offset, not providing a negative sign will
#            instead apply a positive CO / voltage offset!
# IMPORTANT: The automatically adjusted Curve Optimizer / voltage offset values are TEMPORARY, so after a regular reboot they
#            will not be applied anymore
#            If you want to permanently set these values, you will need to set them in the BIOS, or use a startup script to
#            set them on every Windows start (see the text files in the /tools directory for an explanation of the various settings)
#
# Example for setting Curve Optimizer values for a Ryzen 5800X with 8 cores:
# startValues = -15, -10, -15, -8, 2, -20, 0, -30
# Or
# startValues = -15 -10 -15 -8 2 -20 0 -30
# Or
# startValues = -15 | -10 | -15 | -8 | 2 | -20 | 0 | -30
#
# Example to assign a single Curve Optimizer value to all cores:
# startValues = -20
#
# Example to assign a voltage offset of -0.120v (-120mv) for Intel processors:
# startValues = -120
#
# Default: CurrentValues
startValues = -17 | -23 | -10 | -20 | -19 | -26 | -24 | -22


# The upper limit for the Curve Optimizer values / voltage offset
# If this limit has been reached, no further adjustments will be performed
# Instead the core will now simply throw an error and the regular "skipCoreOnError" setting will be obeyed
# This is either a Curve Optimizer value or a voltage offset value
#
# IMPORTANT: Be sensible about this value, setting it too high into the positive could apply a too high
#            voltage to your CPU and may damage it!
#
# Default: 0
maxValue = 0


# The amount by which to increase the Curve Optimizer / voltage offset value
# On an error, the Curve Optimizer / voltage offset value will be increased by this amount
# For Ryzen, a value between 1 and 5 seems reasonable
# For Intel, you should probably set this to 5 to increase the vCore by 5mv after an error
#
# Setting it to "Default" will set the value to 1 for Ryzen and 5 for Intel
#
# Default: Default
incrementBy = 1


# Set only the currently tested core to the selected Curve Optimizer / voltage offset value
# All the other cores will be set to 0, resp. the determined maximum value if it's higher than 0
# This should prevent errors caused by other cores than the currently tested one, or at least diminish the chance for that
#
# Note: Currently this only has an effect for Ryzen processors, for Intel up to 14th gen there is only one voltage value
#
# Default: 0
setVoltageOnlyForTestedCore = 0


# Repeat the test on a core if it has thrown an error and the Curve Optimizer / voltage offset value was increased
# Setting this to 1 will restart the test, until it has not thrown an error, or until the maximum value has been reached
# Setting it to 0, the script will continue to the next core in line as normal
#
# Default: 1
repeatCoreOnError = 1


# Try to automatically resume after a crash / hard reboot
# If this setting is enabled, the script will try to automatically resume after a reboot has occurred
# It creates a Scheduled Task that will be run at logon, which then tries to resume where it left off,
# optionally repeating the last core with an adjusted value (see the repeatCoreOnError setting)
#
# IMPORTANT: If you just close the CoreCycler window without properly exiting the script with CTRL+C,
#            the Scheduled Task will remain and will be executed on the next reboot!
#            So make sure that you always exit CoreCycler by pressing CTRL+C
#
# IMPORTANT: The Scheduled Task will execute once you log back in to your user account
#            So for a true automated testing, it would be beneficial if you activated auto-logon
#            Be aware that this might pose a security risk though, so make sure to consider the risks!
#            https://learn.microsoft.com/en-us/sysinternals/downloads/autologon
#            https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon
#
# NOTE: On some systems, especially Ryzen 9000 systems, the computer doesn't seem to reset during an unstable
#       Curve Optimizer setting, instead it just seems to freeze and would need to be manually restarted.
#       Unfortunately there's currently no way around this that I know of.
#       Maybe there is a BIOS setting somewhere, if you know something, please let me know.
#
# Default: 0
enableResumeAfterUnexpectedExit = 0


# Windows treats crashes or reboots that happen within 120 seconds of the boot as a "failed" boot
# To prevent the Windows Recovery Screen from appearing after three of those "failed" boots, the script will wait for this
# amount of time before resuming the testing process
# Set this to 0 if you don't care about that and want to resume immediately
#
# Default: 120
waitBeforeAutomaticResume = 120


# Create a System Restore Point when using the Automatic Test Mode
# Using the Automatic Test Mode with very unstable starting settings may result in a corrupted Windows installation,
# so creating a System Restore Point before activation is highly recommended
# This way you can more easily restore a corrupted installation
#
# NOTE: The script will only create a System Restore Point if the last one is older than 24 hours
#       It will also not do so while in the middle of the Automatic Test Mode process, only when starting a fresh one
#
# Default: 1
createSystemRestorePoint = 1


# Ask for the creation of a System Restore Point
# If this setting is disabled, the System Restore Point will be automatically created without user interaction
#
# Default: 1
askForSystemRestorePointCreation = 1



# Log specific settings
[Logging]

# The name of the log file
# The "mode" parameter, the selected stress test program and test mode, as well as the start date & time will be
# added to the name, with a .log file ending
#
# Default: CoreCycler
name = CoreCycler


# Set the log level
# 0: Do not log or display additional information
# 1: Write additional information to the log file (verbose)
# 2: Write even more information to the log file (debug)
# 3: Also display the verbose messages in the terminal
# 4: Also display the debug messages in the terminal
#
# Default: 2
logLevel = 2


# Make use of the Windows Event Log to log core tests and core errors
# If this is enabled, CoreCycler will add entries to the Windows Event Log when it has been started, ended,
# and also when iterating over the cores
# This can be helpful if you suffer from corrupted log files after a hard reboot during testing
# To be able to use this, a new Windows Event "Source" for CoreCycler needs to be added, the script will ask
# you add this if it's not available yet
# Adding this Source will require Administrator rights (once), but after it has been added, no additional rights
# are required
# The entries can be found in the Windows Logs/Application section of the Event Viewer
#
# Default: 1
useWindowsEventLog = 1


# Periodically flush the disk write cache
# If this is enabled, CoreCycler will periodically try to flush the disk write cache, which could help to prevent
# corrupted log files when a hard reboot during testing occurs
# Note that some drives have an additional internal write cache, which is NOT affected by this setting
# Also note that this will not work for all drives/volumes, e.g. if you run the script from a VeraCrypt volume,
# this setting will have no effect
#
# Default: 0
flushDiskWriteCache = 0




# Settings for updates
[Update]

# Enable the update check
#
# Default: 1
enableUpdateCheck = 1


# The frequency of the check, in hours
#
# Default: 24
updateCheckFrequency = 24




# Custom settings for Prime95
[Prime95Custom]

# This needs to be set to 1 for AVX mode
# (and also if you want to set AVX2 below)
CpuSupportsAVX = 0


# This needs to be set to 1 for AVX2 mode
CpuSupportsAVX2 = 0


# This also needs to be set to 1 for AVX2 mode on Ryzen
CpuSupportsFMA3 = 0


# This needs to be set to 1 for AVX512 mode
CpuSupportsAVX512 = 0


# The minimum FFT size to test
# Value for "Smallest FFT":   4
# Value for "Small FFT":     36
# Value for "Large FFT":    426
MinTortureFFT = 4


# The maximum FFT size to test
# Value for "Smallest FFT":   21
# Value for "Small FFT":     248
# Value for "Large FFT":    8192
MaxTortureFFT = 8192


# The amount of memory to use in MB
# 0 = In-Place
TortureMem = 0


# The max amount of minutes for each FFT size during the stress test
# Note: It may be much less than one minute, basically it seems to be "one run or one minute, whichever is less"
TortureTime = 1




# Debug settings that shouldn't need to be changed
# Only change them if you know what you're doing and there's a problem you're trying to identify
[Debug]

# Debug setting to disable the periodic CPU utilization check
#
# This setting enables or disables the CPU utilization check during stress testing.
# Some stress test programs (like Aida64) do not generate a log file, so the only way to detect an error is by
# checking the current CPU utilization.
#
# This uses a pretty basic check to see if the stress is still running at all, for a more detailled check
# enable the "useWindowsPerformanceCountersForCpuUtilization" below.
# Be aware that enabling the Windows Performance Counters may introduce other issues though, see the
# corresponding setting for an explanation.
#
# Default: 0
disableCpuUtilizationCheck = 0


# Debug setting to enable the use of Windows Performance Counters for the CPU utilization check
#
# This setting controls if the Windows Performance Counters should be used, which can be corrupted for unknown
# reasons. Please see the readme.txt and the /tools/enable_performance_counter.bat file for a possible way
# to fix these issues. There's no guarantee that it works though.
#
# Default: 0
useWindowsPerformanceCountersForCpuUtilization = 0


# Debug setting to enable querying for the CPU frequency
#
# This setting enables checking the CPU frequency
# Currently it doesn't really serve any purpose. The retrieved CPU frequency is not accurate enough (e.g. compared to HWiNFO),
# and its output is limited to the "verbose" channel.

# According to some reports, enabling it can result in incorrect CPU utilization readings, so be aware of this when you enable
# this setting.
#
# Note that this also enables the usage of the Windows Performance Counters, which may not work on certain systems.
# They can become corrupted, please see the readme.txt and the /tools/enable_performance_counter.bat file for a possible way
# to fix these issues. There's no guarantee that it works though.
#
# Default: 0
enableCpuFrequencyCheck = 0


# Debug setting to control the interval in seconds for the CPU utilization check and the "suspendPeriodically" functionality
#
# Don't set this too low, it will spam the log file and can produce unnecessary CPU load.
# It would also increase the time when the stress test program is suspended
# I'd consider 10 to be the minimum reasonable value (which is also the default)
#
# If 0, will disable this functionality
# This basically would mean "disableCpuUtilizationCheck = 1" and "suspendPeriodically = 0"
# Not entirely though, as the last check before changing a core is not affected
#
# Default: 10
tickInterval = 10


# Debug setting to delay the first error check for each core
#
# With this setting you can define a wait time before the first error check happens for each core
# Some systems may need longer to initialize the stress test program, which can result in an incorrect CPU utilization detection,
# so setting this value might resolve this issue
# Don't set this value too high in relation to your "runTimePerCore" though
#
# Default: 0
delayFirstErrorCheck = 0


# Debug setting to set the priority of the stress test program
#
# The default priority is set to "High" so that other applications don't interfere with the testing
# It can cause the computer to behave sluggish though. Setting a lower priority can fix this
#
# Note: "RealTime" probably won't work and you shouldn't set this anway, as the computer won't be responsive anymore
#
# Possible values:
# Idle
# BelowNormal
# Normal
# AboveNormal
# High
# RealTime
#
# Default: Normal
stressTestProgramPriority = Normal


# Debug setting to display the stress test program window in the foreground
#
# If enabled, will display the window of the stress test program in the foreground, stealing focus
# If disabled (default), the window will either be minimized to the tray (Prime95) or be moveed to the background,
# without stealing focus of the currently opened window (y-cruncher)
#
# Default: 0
stressTestProgramWindowToForeground = 0


# Debug setting to control the amount of milliseconds the stress test program is being suspended
#
# Default: 1000
suspensionTime = 1000


# Debug setting to define the method that is used to suspend the stress test process
#
# Can either be set to "Debugger" or "Threads"
# "Debugger" uses the "DebugActiveProcess" and "DebugActiveProcessStop" kernel32.dll methods on the main process
# "Threads" uses the "SuspendThread" and "ResumeThread" kernel32.dll methods on the process threads
# There's no clear benefit to either of these settings, but if there's a problem with one of these settings,
# the other one may work better
#
# Default: Threads
modeToUseForSuspension = Threads

[sp00n]

I think I've seen something like this if the global PowerShell output logging had been enabled. Not the logging behavior of CoreCycler itself, but the global setting that I think could be enabled with the group policy editor or a registry entry.

Do other stress test work?

If it isn't the global logging setting, you could maybe work around this by setting stressTestProgramPriority to AboveNormal or High, and maybe even use the delayFirstErrorCheck setting to postpone the first error check. Both settings are in the [Debug] section.

[thoraine]

Hmm I changed stressTestProgramPriority = AboveNormal and while it's still printing word by word, it prints it noticeably faster now. Leaving it at Normal and changing the test to P95, When running my own copy of yCruncher standalone, everything gets printed quickly.

it starts immediately, so it might be due to the PowerShell global logging? I don't remember enabling this option though.

[sp00n]

The instructions to enable the global logging were described in this issue:
#98 (comment)

Although there the problem was actually that the script itself was outputting the text very very slowly, and not y-cruncher. So I'm not sure if this would actually be the same issue.
And it doesn't seem to be active for you anyway, so very likely not.

Besides that, I currently have no idea what could be causing this. Does it go away if you run it with 0 CO? Maybe it could be a sign of instability, although that would be a very weird one.

Maybe the wrapper I use to intercept the output from y-cruncher somehow acts up. You could disable this with enableYCruncherLoggingWrapper = 0, however this will also disable catching any of the errors that y-cruncher prints out and will then solely rely on the detection of the CPU usage, which itself can be problematic at times (as you experienced), so it's not the preferred way.
But it might help to circle in on the root of the problem.

[thoraine]

Well I changed it to -1 CO Normal priority and it was acting the same way with y-cruncher. Disabling enableYCruncherLoggingWrapper worked perfectly but I don't want to rely on CPU usage detection so I'll leave it on despite the startup problems.

Unrelated but setting startValues to 0 seems to fail.