Motherboard Optimisation/settings

[ASRMichael]

Hi, I thought I would start a thread on motherboard optimisation. I see in many post people taking about motherboard setting tweaks. 
 

Would like to know what others have done, I appreciate there are different settings per manufacturer. 
 

I’ve done the following with ASUS MB

 

Speed step off

Turbo off

Hyperthreading off

RAM voltage set to spec not auto

Turned off USB ports I’m not using

 

Has anyone dared to change any of these auto settings to fixed settings? 
 

Is there other optimisations that can we trialled? 

[Iving]

Also ASUS (Z270-WS)

            Disable SpeedStep, C-States, Turbo

            ASUS Multicore Enhancement Off

            spread spectrum OFF x 3 (VRM/BCLK pcie)

            Hyperthreading Disabled

            Hardware Prefetcher / Adjacent Cache Line Prefetch Off

            Execute Disable Bit Disabled

At your own risk!

 

[DMelby]

A few things to try that might help your system. I've experimented with an ASUS prime x-299 deluxe II, and found the following were the most beneficial (try at your own risk, and your system will be slow as a turtle but sound better). In general principle the higher the clock speeds, switching frequencies, etc the worse the sound. Perhaps related to EMI generated at higher speeds? Not sure...

BCLK frequency 100

Asus multicore enhancement disabled

SPU Core ratio sync all cores

All-Core Ratio Limit 7 (or 8 if you cant choose 7)

Min CPU Cache Ratio 8

Max CPU Cache Ratio 8

BCLK Frequent:DRAM Frequency Ratio 100:100

DRAM Frequency DDR4-1000MHZ (or if you can, 800MHZ)

CPU Load line Calibration Level 1

Fixed CPU VRM Switching Frequency 300

DRAM Switching Frequency Manual

Fixed DRAM Switching Frequency 300

Hyper-Threading Disabled

Active Processor Cores (all but 1 or 2 disabled)

 

When complete, confirm that bios says your CPU frequency is 700 (or 800) and memory frequency is 1000 (or 800)

 

 

[John Dyson]

One thing that I know for sure -- depending if your applications are heavily multi-threaded and the app/os or CPU don't have intimate control over hyperthreading CPU affniity -- sometimes disabling hyperthreading can make a big difference.   It works out like this-- if you have an application that uses the SIMD floating point a lot, but some threads don't use SIMD all that much...  Specific example --

4 cores -- 4 SIMD capable units, 8 threads...

Sometimes, SIMD dependent threads will bunch up onto the same core -- for example core 1 might have two threads that need SIMD, but the rest of the cores are not using SIMD, but have essentially idle SIMD math processing capability.  Each of the threads bunched up on 'core 1' will run 1/2 speed because the multithreading mostly only shares the math capability, each hyperthread doesn't replicate the math capabilities (just the named registers.)   To make sure that the threads dont bunch up like that, then disable SIMD -- and the scheduling for SIMD FP or integer operations will match what the OS expects.

 

The DHNRDS controls the threading for Linux so it doesn't happen like that, but I am not a windows expert, and I don't know the api that describes the core/thread layout so that I can set the affinity correctly.  The DHNRDS is especially bad because it will utilize almost ALL SIMD/threading  capabilities of a CPU up to at least 8 cores.

 

But, if an application uses a resource that is per-core rather than per-hyperthread, you can run into that kind of problem, and disabling hyperthreading might speed up the program and computer.

 

On CPUs like Haswell, hyperthreading in general seems only to help just a little bit -- but with CPUS with more resources, it might help more.

 

John

 

[davide256]

Somehow I doubt audio is a multi-thread process.... that faster/stable CPU clock and good power supply matters most. IME with NUC's

the power supply quality makes or breaks USB SQ and which enhancement features you are able to leave enabled.

[mansr]

On 11/23/2019 at 1:45 PM, Iving said:

            spread spectrum OFF x 3 (VRM/BCLK pcie)

Why? Spread spectrum generally improves the EMC behaviour. It's the reason it was invented.

 

Quote

            Execute Disable Bit Disabled

Again, why? This is a security feature that should be kept on. The reason it can be disabled is for compatibility with some old software that might break.

[Iving]

15 minutes ago, mansr said:

Why? Spread spectrum generally improves the EMC behaviour. It's the reason it was invented.

 

Again, why? This is a security feature that should be kept on. The reason it can be disabled is for compatibility with some old software that might break.

 

Spread Spectrum

https://www.reddit.com/r/audiophile/comments/9pohq6/a_very_easy_tip_to_make_your_pcs_audio_much/

https://www.soundonsound.com/techniques/bios-tweaks-music-performance

https://audiophilestyle.com/forums/topic/24132-enable-spread-spectrum/?do=findComment&comment=499030

Disabling didn't hurt me - I thought maybe "cleaner" after

 

Execute Disable Bit - no strong view

[Blackmorec]

8 minutes ago, mansr said:

Why? Spread spectrum generally improves the EMC behaviour. It's the reason it was invented.

 

Again, why? This is a security feature should be kept on. The reason it can be disabled is for compatibility with some old software that might break.

Spread spectrum reduces EMI levels for FCC compliance reasons by varying the frequency of the main oscillator, thereby spreading the EMI over a wider range of frequencies. Exactly what you don’t want when transmitting music data streams as it creates jitter and corresponding phase noise.  

 

 

[mansr]

16 minutes ago, Blackmorec said:

Spread spectrum reduces EMI levels for FCC compliance reasons by varying the frequency of the main oscillator, thereby spreading the EMI over a wider range of frequencies.

Right, and this reduces interference with other equipment nearby. Like your DAC.

 

16 minutes ago, Blackmorec said:

Exactly what you don’t want when transmitting music data streams as it creates jitter and corresponding phase noise.

Why would it do that? The spread spectrum clocks are not used for audio timing.

[botrytis]

Turning off hyperthreading? You may as well use a Gen 2 i5 or i7 without it. You hare basically cutting the capability of the CPU by close to 50%.

 

Use multicores when ever possible. That means you may as well have a single core processor.

 

Do people actually understand what they are turning on and off in the BIOS before they do it? 

[mansr]

22 minutes ago, botrytis said:

Turning off hyperthreading? You may as well use a Gen 2 i5 or i7 without it. You hare basically cutting the capability of the CPU by close to 50%.

In my experience, the difference is more like 15%. Regardless, if the performance is sufficient, the setting doesn't matter. Audio playback uses only a few percent of the available performance anyway.

 

22 minutes ago, botrytis said:

Do people actually understand what they are turning on and off in the BIOS before they do it? 

I have my doubts.

[John Dyson]

1 hour ago, botrytis said:

Turning off hyperthreading? You may as well use a Gen 2 i5 or i7 without it. You hare basically cutting the capability of the CPU by close to 50%.

 

Use multicores when ever possible. That means you may as well have a single core processor.

 

Do people actually understand what they are turning on and off in the BIOS before they do it? 

Hyperthreading doesn't multiply the amount of CPU resources other than registers and instruction scheduling.  Most of the actual core  isn't replicated.  Hyperthreading is not 100% good -- that is why there is often a disable for it.  Hyperthreading at at most help a little - assuming a sane OS schduler, and can actually lose as much as 50% of the CPU.

 

The main thing that hyperthreading helps with is stuff like memory wait states, but if the application is written efficiently, then the read-ahead/etc will take care of most of it.

 

John

 

[John Dyson]

2 hours ago, davide256 said:

Somehow I doubt audio is a multi-thread process.... that faster/stable CPU clock and good power supply matters most. IME with NUC's

the power supply quality makes or breaks USB SQ and which enhancement features you are able to leave enabled.

It depends on the audio process and how much processing whether it is muti-threaded or not.

Think of it like this -- GUI is usually at least one thread (whether hidden in the OS or driver or whatever), and the a simple streaming application can be one thread, etc...   If the application is doing more than streaming or serving multiple users, then process threading comes into its own.

 

Back when I was a beginning programmer, I didn't realize how cool, useful and how much efficiency improvement that could be done.  Now, I won't write much more complex than 'Hello World' without considering threading.   It is easy, and you really only gain from it if done correctly (and don't run into the hyperthreading botch, where the hyperthreading doesn't have a good control in most CPUs.)

 

John

 

[Nenon]

I look at my digital source as one system from the file you play all the way to the analog output of the DAC. Everything in between is a complex chain - software, hardware, power supplies, cables, clocking, DAC interface etc. etc. - they all interact with each other. It is especially important how the computer interacts with the DAC, what conversion stages the source is going through, and how they affect the overall sound.

Everything needs to be optimized for your particular system. Hence, I don't believe there are many universal BIOS settings that you can apply to every system.

- First, there are unused things you can turn off from the BIOS like the audio card, any unused USB ports, other I/O interfaces, etc. Basically the less chips are working, the less EMI your motherboard would generate, which typically results in less jitter / better overall sound quality.

- Second, you have some power settings. Some people tweak their system for using less power. I guess the power supply is one of the big factors here. 

- Third, you have performance settings - turbo, hyperthreading, CPU speed, RAM speed, etc. Those settings overlap with the power settings, because you can reduce the performance to reduce the power usage. They also depend on the quality of the power supply, the hardware, OS, the player and so on. 

 

I started with a system tweaked for lower power consumption / lower performance. As part of that I was disabling turbo, reducing the clock speed, and doing some of the other things mentioned above. But now I have a system that is tweaked for performance - power draw is not an issue - I have 16 cores doing almost nothing and tweaked for low latency / high performance. And that system, which is also much more expensive, sounds a lot better.  

 

OP probably wanted a universal list of BIOS settings, but I don't think it is that simple. Knowing what you are trying to achieve would help narrow down some of the choices and things to try. 

[John Dyson]

17 minutes ago, Nenon said:

I look at my digital source as one system from the file you play all the way to the analog output of the DAC. Everything in between is a complex chain - software, hardware, power supplies, cables, clocking, DAC interface etc. etc. - they all interact with each other. It is especially important how the computer interacts with the DAC, what conversion stages the source is going through, and how they affect the overall sound.

Everything needs to be optimized for your particular system. Hence, I don't believe there are many universal BIOS settings that you can apply to every system.

- First, there are unused things you can turn off from the BIOS like the audio card, any unused USB ports, other I/O interfaces, etc. Basically the less chips are working, the less EMI your motherboard would generate, which typically results in less jitter / better overall sound quality.

- Second, you have some power settings. Some people tweak their system for using less power. I guess the power supply is one of the big factors here. 

- Third, you have performance settings - turbo, hyperthreading, CPU speed, RAM speed, etc. Those settings overlap with the power settings, because you can reduce the performance to reduce the power usage. They also depend on the quality of the power supply, the hardware, OS, the player and so on. 

 

I started with a system tweaked for lower power consumption / lower performance. As part of that I was disabling turbo, reducing the clock speed, and doing some of the other things mentioned above. But now I have a system that is tweaked for performance - power draw is not an issue - I have 16 cores doing almost nothing and tweaked for low latency / high performance. And that system, which is also much more expensive, sounds a lot better.  

 

OP probably wanted a universal list of BIOS settings, but I don't think it is that simple. Knowing what you are trying to achieve would help narrow down some of the choices and things to try. 

With so many cores -- no reason to enable hyperthreading in normal user situations  -- few user envrionments will use that many cores simultaneously executing.  As I wrote above, the DHNRDS has 20-24 threads so can TRY to take advantage of that many cores, but will limit to 8 cores because of some threads that limit the througput.

 

Whether or not to use hyperthread all depends on the situatoin, but if I had 12 (maybe even 8  ) or more cores, even with the extreme load that my system is hit with, I almost definitely wouldn't bother with hyperthreading.

 

John

[botrytis]

11 minutes ago, John Dyson said:

With so many cores -- no reason to enable hyperthreading in normal user situations  -- few user envrionments will use that many cores simultaneously executing.  As I wrote above, the DHNRDS has 20-24 threads so can TRY to take advantage of that many cores, but will limit to 8 cores because of some threads that limit the througput.

 

Whether or not to use hyperthread all depends on the situatoin, but if I had 12 (maybe even 8  ) or more cores, even with the extreme load that my system is hit with, I almost definitely wouldn't bother with hyperthreading.

 

John

 

But people are also turning off multi-cores. As I said, they do not understand what they are doing.

[botrytis]

33 minutes ago, John Dyson said:

Hyperthreading doesn't multiply the amount of CPU resources other than registers and instruction scheduling.  Most of the actual core  isn't replicated.  Hyperthreading is not 100% good -- that is why there is often a disable for it.  Hyperthreading at at most help a little - assuming a sane OS schduler, and can actually lose as much as 50% of the CPU.

 

The main thing that hyperthreading helps with is stuff like memory wait states, but if the application is written efficiently, then the read-ahead/etc will take care of most of it.

 

John

 

 

I think you are misunderstanding. Hyperthreading has to do with states of the thread, if a thread is on a halt state, hyperthreading allows another tread to use the same core. Also, when a core is working on a thread, there are times when the core isn't being used. Hyperthreading allows the core to be used at those time with another thread. So, yes it is useful.

[Nenon]

26 minutes ago, John Dyson said:

With so many cores -- no reason to enable hyperthreading in normal user situations

I use AMD Ryzen, so there is no such thing as hyperthreading. But I did play with SMT on/off and various CPU isolation settings and have settled on the settings that work best in my system.

 

 

[mansr]

10 minutes ago, Nenon said:

I use AMD Ryzen, so there is no such thing as hyperthreading. But I did play with SMT on/off and various CPU isolation settings and have settle on the settings that work best in my system.

SMT is hyperthreading.

[botrytis]

10 minutes ago, Nenon said:

I use AMD Ryzen, so there is no such thing as hyperthreading. But I did play with SMT on/off and various CPU isolation settings and have settle on the settings that work best in my system.

 

 

 

They have their own version of hyperthreading, which is SMT.

[mansr]

1 minute ago, botrytis said:

They have their own version of hyperthreading, which is SMT.

SMT is the generic name. Hyperthreading is the name of Intel's implementation. It can also be written as Hype-®-Threading.

[botrytis]

I am using AMD CPU's - one is a Ryzen 2600 - very nice chip.

[Nenon]

Do we really need to argue about that? Hyper-threading is an Intel proprietary technology and not available on my AMD Ryzen.

I did say that I tried SMT on/off. Let's move on... 

[clipper]

AudioPhil (Audiophile Optimizer) says that it's "very important" to disable, among other things, hyper-threading.

 

See page 5 of his Computer Audio Best Practices Guide (at https://www.highend-audiopc.com/PDF/computer_audio_best_practices_guide.pdf).

 

I agree because in my use cases, it sounds better to me with hyper-threading off.  I only turn on hyper-threading to get stutter-free upsampling to DSD512 (which I almost never do anymore).

 

 

[John Dyson]

4 hours ago, botrytis said:

 

I think you are misunderstanding. Hyperthreading has to do with states of the thread, if a thread is on a halt state, hyperthreading allows another tread to use the same core. Also, when a core is working on a thread, there are times when the core isn't being used. Hyperthreading allows the core to be used at those time with another thread. So, yes it is useful.

Hmmm...  I am not misunderstanding.  As far as the OS scheduler is concerned, a hyper-thread is the same as another CPU.   Except, a hyper thread does not imply the same performance improvment  as another CPU core, and is a 'lame' CPU that basically steals most resources from its' sibling hypethread -- both sharing a core.  (Some intel CPUs actually have 4 threads per core, but not desktop or normal server CPUs.)

 

The hyperthread ONLY has register and instruction scheduling on a per-hyperthread basis.  There are cases where two hyperthreads using a full core's resources will be scheduled instead of spread amongst totally idle cores.  This is especially bad for SIMD instructions -- which my software uses a lot of.  (Any well written DSP audio software will take full advantage of SIMD like my softoware does.)  When two threads are scheduled onto hyperthreads on the same core instead of onto other cores, the performance will suffer BADLY.   Blindly using hyperthreading is not always beneficial, and at most, there is SOMETIMES a 10% or so gain.

 

The most useful common case of benefit from hyperthreading is in memory/cache and other external-from-cpu resource waits.  When one hyperthread is in a memory wait or a special kind of wait loop, then the other hyperthread can take full advantage of the shared CPU core.  When both hyperthreads are actually runnable, the benefit is nil or even negative, because of the thrashing of resources -- uncontrollable by the OS.  Basically the hyperthreads can fall into a state of thrashing and not create any benefit, probably losing a percent or two of performance when over-scheduled.  (Probablems like local cache thrashing can happen when blindly over utilizing the hyperthreads.)

 

On well written, high performance software, the memory and resource waits don't happen as often as one might think, and the OS scheduler, being blind to the actual thread activity, can make bad decisions WRT scheduling and slow down the total system by up to 50%.   That kind of slowdown actually can happen on my software that has 100% utilization of the SIMD math sections of the CPU.  There is only ONE such usable SIMD resource for both hyperthreads -- scheduling both hyperthreads of a single core, if other cores are avaialbe is where the hyperthreading can effectively be deadly for performance.

 

On normal intel CPUS, two hyperthreads share most of a cpu CORE.  The CORE is the full CPU, and the hyperthread is mostly just context.  The performance boost of using hyperthreads is in the 10% range, but there can be a bit of a realtime performance improvement, but not well bounded.

 

Normally, you always want to enable all of the CPUs and CPU cores, but hyperthreading (the two threads sharing a single core) definitely needs to be optional because the OS and even the CPU at the instruction level are blind to the threading, so good hyperthreading decisions couldn't be made up until the most recent CPUS.

 

On the other hand, for power savings, it might be useful to disable full cores, but that isn't as beneficial as it might seem because the cores and most importantly, the SIMD math portions of the CPU do power down themselves.

 

John