You're not running a high-traffic database server. I can't see how you're exceedingg the PC's PCIe channel limits, except by running meaningless disk benchmarks. They're not useful because your PC doesn't behave that way under normal load.
When playing a game, it transitions from loading a lot of game data which eventually gets cached in memory, to switching to heavy GPU calls. After that you don't get much I/O, and it's all the GPU working up the PCIe bus by transferring model/texture data from memory.
I don't have a CPU affected by TSX, but if someone does and can show me some credible benchmarks with it on/off and provide some background on the topic, I'll add it into the guide if it's a tweak worth using.
Hello Hellbovine, my suggestion was wrong. I tested it on e3 1226 without opening any programs, and there was no change in the scores before and after opening. I confirmed that it supports tsx and viewed it in cpu-z, deleted files in pe and changed the registry.
Sincerely thank you for your contribution.
In case I use nvme SSD, I saw something about the number of PCIe lanes on the processor/chipset and if the power used for this second SSD would lack other components that could cause congestion. I don't understand the subject either. so you would have to make a calculation based on each processor. I use a "gamer" notebook.
In fact the correct answer is what you say, you need to know the number of PCIe lines on your CPU (unrelated to Windows usage)
If your devices exceed this number, then it will "disable" other devices (see the different options in bios)
For example, with a CPU with 44 PCIe lines, you can put 2 graphics cards (2 x 16 lines), 2 SSDs NVMe (2 x 4 lines), that gives you 40 lines used out of 44
Also note that some motherboard manufacturer wire their M2 (NVMe) port on the chipset, which is less efficient than those of the CPU
The case on motherboards with many M2 ports
But it's valid for a desktop that you “build” yourself, on a laptop (or desktop bought at the store) if you have the slot for 1 or 2 SSDs, then it's good, it's designed for
meanwhile we are getting fewer and fewer sata ports. best motherboard i got for sata ports is an old A88x FM2+ with 8 onboard without an additional controller. for me thats 1 port for the os ssd, 3 ports for optical drives and 4 for storage hdds.
On my dual SSD setup (W10 22H2), I tested a previous question today of, "Does using multiple disk drives affect performance?"
The basic premise that has been touted over time, is that people should install Windows on C: drive and then other software, such as video games, on D: drive. This is for a few reasons, whether for possible performance benefits, or for people with many games/movies that need a cheaper and larger drive to store those files on, etcetera. It is a common scenario, but I have never seen any real testing done on it, so I did it myself. It took about 2 hours to run all the tests and then analyze the data, based on 85 gigabytes of disk activity.
LATENCY TESTS
These tests used LatencyMon and CrystalDiskMark in combination to record the data below.
- Ran both tools, with a single 5 gigabyte test on C: drive for a baseline.
- Ran both tools, with a simultaneous 5 gigabyte double test on C: drive.
- Ran both tools, with a single 5 gigabyte test on D: drive for a baseline.
- Ran both tools, with a simultaneous 5 gigabyte double test on D: drive.
- Ran both tools, with a simultaneous 5 gigabyte test split between C: and D: drive.
The results showed that latency increases significantly under double workloads, which is expected, because more work for the processor always results in increased latency. The important aspect of this test though, was to see if latency gets better or worse when heavy workloads are put on the Windows drive, a spare drive, or split between drives, and there was no statistical difference between those.
GAMING TESTS
These tests used UnigineValley and CrystalDiskMark in combination to record the data below.
- Ran UnigineValley without CrystalDiskMark, for a baseline.
- Ran both tools, with a staggered 5 gigabyte triple test on C: drive.
- Ran both tools, with a staggered 5 gigabyte triple test on D: drive.
- Ran both tools, with a staggered 5 gigabyte triple test split between C: and D: drive.
To clarify the staggered meaning, I launched the UnigineValley benchmark and then immediately ran the 1st CrystalDiskMark test. 30 seconds later, I start the 2nd CrystalDiskMark test, while the other was still running. 30 more seconds after that, I start the 3rd CrystalDiskMark test, while the previous ones are still active. The staggering method ensures that each benchmark had intense reading and writing operations occuring at the same time, in order to help exasperate any struggles of the computer.
When it came time to do the test on both C: and D: drive for the mixed comparison, I had the 1st CrystalDiskMark test running on C: drive, while the 2nd and 3rd CrystalDiskMark tests were ran on D: drive, to help show if splitting disk activity would affect anything.
The UnigineValley testing ended up duplicating the same outcomes I was seeing from LatencyMon and the advanced CrystalDiskMark text file results, but that is simply too much data to write up and discuss, so I attached the UnigineValley benchmarks instead, because those are super easy and fast for everyone to read, serving as a terrific visual summary of this post.
The UnigineValley_Baseline result:
FPS 83.7, Score 3502, Min FPS 27.3, Max FPS 126.3
The UngineValley_C_Triple result:
FPS 80.8, Score 3380, Min FPS 25.4, Max FPS 116.8
The UngineValley_D_Triple result:
FPS 80.8, Score 3381, Min FPS 25.2, Max FPS 117.3
The UngineValley_Mixed_Triple result:
FPS 80.1, Score 3351, Min FPS 25.0, Max FPS 119.4
The results are all well within the standard 3% benchmarking margin of each other, meaning the main scenarios show statistically identical performance, signifying that it does not matter if I put all the work on the Windows drive, spare drive, or split it. Ultimately, the computer still does the same amount of work in total, taxing the processor and other hardware as if there was only one drive installed.
In conclusion, using multiple SSD drives, and probably all other forms of non-mechanical drives, does not result in performance increases or decreases. With that being said, the part I am unsure about is how mechanical drives would fair in this series of tests, and that would be worth investigating for anyone that has a setup relying on those, because HDD technology differs from drives without mechanical arms.
i wouldnt even bother testing hdd's because everyone knows they are slow compared to solid state drives.
know your hardware and accept any limitations.
On my dual SSD setup (W10 22H2), I tested a previous question today of, "Does using multiple disk drives affect performance?"
The basic premise that has been touted over time, is that people should install Windows on C: drive and then other software, such as video games, on D: drive. This is for a few reasons, whether for possible performance benefits, or for people with many games/movies that need a cheaper and larger drive to store those files on, etcetera. It is a common scenario, but I have never seen any real testing done on it, so I did it myself. It took about 2 hours to run all the tests and then analyze the data, based on 85 gigabytes of disk activity.
LATENCY TESTS
These tests used LatencyMon and CrystalDiskMark in combination to record the data below.
- Ran both tools, with a single 5 gigabyte test on C: drive for a baseline.
- Ran both tools, with a simultaneous 5 gigabyte double test on C: drive.
- Ran both tools, with a single 5 gigabyte test on D: drive for a baseline.
- Ran both tools, with a simultaneous 5 gigabyte double test on D: drive.
- Ran both tools, with a simultaneous 5 gigabyte test split between C: and D: drive.
The results showed that latency increases significantly under double workloads, which is expected, because more work for the processor always results in increased latency. The important aspect of this test though, was to see if latency gets better or worse when heavy workloads are put on the Windows drive, a spare drive, or split between drives, and there was no statistical difference between those.
GAMING TESTS
These tests used UnigineValley and CrystalDiskMark in combination to record the data below.
- Ran UnigineValley without CrystalDiskMark, for a baseline.
- Ran both tools, with a staggered 5 gigabyte triple test on C: drive.
- Ran both tools, with a staggered 5 gigabyte triple test on D: drive.
- Ran both tools, with a staggered 5 gigabyte triple test split between C: and D: drive.
To clarify the staggered meaning, I launched the UnigineValley benchmark and then immediately ran the 1st CrystalDiskMark test. 30 seconds later, I start the 2nd CrystalDiskMark test, while the other was still running. 30 more seconds after that, I start the 3rd CrystalDiskMark test, while the previous ones are still active. The staggering method ensures that each benchmark had intense reading and writing operations occuring at the same time, in order to help exasperate any struggles of the computer.
When it came time to do the test on both C: and D: drive for the mixed comparison, I had the 1st CrystalDiskMark test running on C: drive, while the 2nd and 3rd CrystalDiskMark tests were ran on D: drive, to help show if splitting disk activity would affect anything.
The UnigineValley testing ended up duplicating the same outcomes I was seeing from LatencyMon and the advanced CrystalDiskMark text file results, but that is simply too much data to write up and discuss, so I attached the UnigineValley benchmarks instead, because those are super easy and fast for everyone to read, serving as a terrific visual summary of this post.
The UnigineValley_Baseline result:
FPS 83.7, Score 3502, Min FPS 27.3, Max FPS 126.3
The UngineValley_C_Triple result:
FPS 80.8, Score 3380, Min FPS 25.4, Max FPS 116.8
The UngineValley_D_Triple result:
FPS 80.8, Score 3381, Min FPS 25.2, Max FPS 117.3
The UngineValley_Mixed_Triple result:
FPS 80.1, Score 3351, Min FPS 25.0, Max FPS 119.4
The results are all well within the standard 3% benchmarking margin of each other, meaning the main scenarios show statistically identical performance, signifying that it does not matter if I put all the work on the Windows drive, spare drive, or split it. Ultimately, the computer still does the same amount of work in total, taxing the processor and other hardware as if there was only one drive installed.
In conclusion, using multiple SSD drives, and probably all other forms of non-mechanical drives, does not result in performance increases or decreases. With that being said, the part I am unsure about is how mechanical drives would fair in this series of tests, and that would be worth investigating for anyone that has a setup relying on those, because HDD technology differs from drives without mechanical arms.
You'll need to edit your quote to only show me the text that lead you to that conclusion, so I know what specific detail needs clarification. With SSD and above, it just doesn't matter where you install stuff, the CPU is going to be the bottleneck regardless of whether the data is coming from C: drive, D: drive, or a mix of both. This may be different for HDD though, since those become the main bottleneck when in use.
Driver signing does not impact system performance, it only affects whether Windows will trust it for loading.
An unsigned driver can be caused by several reasons:
- Driver file was never signed. This is very common for hand-modded drivers.
- Driver's signing certificate has expired.
- Certificate Authority (CA) which issued the signing cert has revoked it, or MS has banned it from the CRL.
Windows will always load unsigned drivers if you disable SecureBoot and enable test-signing mode. Test-signing mode cannot be used together with Virtualization Based Security (VBS) or any kernel-based security features which require all boot code & drivers to be properly signed.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
