Recommendations to budget

[Dlaw]

I run IXTU's stress test program with 3DMark Firestrike or Unigine Heaven at the same time. Heaven's a little easier to use for this purpose, because it loops. Firestrike is a cooler demo IMO though.

That will definitely let you know if there's any problems. So long as it runs for 30 minutes or so, you can rule out any type of hardware defect.

 

[afpTeam]

Early results

I took a slightly different direction to establish baseline and forward testing.

Using Intel's IETU to store default and changes.
Adjusted bios to match the RAM speed, latency and voltage.

First tests at 4.4 ghz were established by matching all 4 cores to same frequency
Fixed Core voltage at 1.299 static
Wattage limiters at 150 watts which was 10% over what it took to sustain the bench in IETU.
Cache frequency is 1:1 with cores
Core temps and cpu running about 47C low, 81C High, but noticed early in the runs temps would touch 91C.

Results on bench showed about a 10% increase over nominal on all factors agreeing for temps, watts, fan demand etc.
Considered relatively good start point, 99% utilization seemed solid.

Once the process was established and saved I moved to the CPU-Z stress test model with IETU and taskmanager still running.

Initial test run at 5 minutes looked good, but noticed gradual drift dropping off on CPU utilization.
By the time 20 minutes passed, temps were down to 75-77C and utilization was dropping off as low as 80%
Returning to the bench test I ended up at 82% of the standard 4.0 ghz bench value in CPU-Z reference.

At between 30 and 60 minutes the apps became unresponsive to mouse clicks and attempting to close the apps resulted in a sudden restart.

At first I thought I was seeing cache congestion but it looks more like thermal soaking is eventually triggering toward some other form of throttling or simply failure mode unidentified as yet. Throughout duration the stats showed 4.4 Ghz triggering, 4 cores active, however the bench retest in IETU still read 1081 as before despite taking twice as long to complete. The IETU appears to be unreliable in benching at least, in this current condition. Wattage consumption never exceeded 100 during the loss of utilization, no indication of hot spots, spikes or other instability in control values. Fan speed tapered off with temp demand moving from a highest of 1900 RPM down to 1600 once utilization bottomed out around 75%, temps holding around 80C.

No Thermal throttling was reported by IETU during any tests good or bad.

Any ideas what might cause a gradual decay of CPU utilization during stress?

I'm finding little information generalized on Google regarding this somewhat if-ish output "utilization" so I really can't know where to go to solve for it strategically yet.

Thanks as always.

Mike

 

[afpTeam]

Decay in utilization falling off ending in instability

I could have been more descript in my last posting title...

The problem explained in the last post suggests there is some manner of loss in frequency generation happening gradually beyond 10 minutes stress testing.

If not for the fact the system eventually destabilizes in the OS, I would assume an undetected throttling some where, but in this case it just seems the entire system is degrading in performance.

Has anyone else experienced a non-descript loss of frequency / utilization on this combination 4790K with ASRock Z97 Extreme6 or have suggestions on further analysis?

Thanks again,

Mike

 

[Dlaw]

First thing I notice is that you keep saying "bench". You want to be using IXTU's stress test, not benchmark, to confirm stability. The benchmark isn't nearly as stressful.


Did you run a full system stress at stock to confirm that you don't have any defective parts, like I suggested? If not, you really should to rule that out.

So you're trying at 4.4GHz, correct? Are you changing the settings in UEFI or IXTU? Software overclocking is unreliable, it's always best to change settings in BIOS/UEFI. Having said that, 4400 should be easily attainable with a 212Evo, since that's the default turbo clock.

 

[afpTeam]

Thanks Dlaw,

Let me ask one particular question first... Do you advocate fixed voltage and controls or do you favor dynamic scaling be left in the hands of OS/BIOS? The concern for me is to avoid a dynamic config that can inadvertently permit damage if the OS were to loop on high demand error at run time and drive the processor into max sustained as permitted on auto-scaling.

=======

I initially ran IXTU's stress test program with Unigine Heaven stress 30 minutes out of the box and saw no problems. I even ran two copies of Unigine same time, still no problems at stock settings. The cooler is MORE than adequate on these relatively low demand stress test models, honestly.

Sorry for the details at length. I'm trying to re-state the process I followed, until I have a more standard process I can work from.

So far, changes to configuration have been done "mostly" in IXTU, except that RAM settings were matched in UEFI to match the specs of the RAM you specified, for speed and latency, making sure BIOS knew the RAM speed accurately. I also put the fans into Max speed setting after seeing the utilization fall off, which didn't seem to make a lot of difference. Fan speeds still seem to hover around 1800 RPM, (capable of 2000), even with bios set for max fan and Win10 performance settings on Max processor.

I did notice a peculiar side effect in that the processor in auto-scaled mode did NOT return back to it's lowest voltages after the stress test until I restarted Win10. It tends to hover around 75 watts after testing which is not a problem, but then after restart before any other appz, it's closer to 35-40 watts. I attribute this to residual OS supports remaining active after application runtime stress tests, which possibly after X minutes might have dropped back on its own as support OS dropped out any residual apps. Others on the web have reported similar sustained higher levels on this hardware combination so it may simply be OS-centric fluff, not substantially a concern at 75 watts either way.

Yes, I understand the difference between bench and stress. The reason you see me differentiate is that once I saw degradation after stepping up the clock for 30 minutes, I would re-check the benchmark immediately after the performance would bottom out around 80% utilization. in IXTU the bench took nearly twice as long after stress soaking but then reported the same crisp readings it had before stress testing. This lead me to believe IXTU wasn't fully integrating possibly as the bench test in IXTU was reporting inaccurately while CPU-Z confirmed sustained loss below standard. Ditto, application level tuning is hit n miss, understood.

By comparison, CPU-Z was reporting the static voltage cofig I set at 1.299 to reflect about a 10% benefit at 4.4 ghz until again running stress tests and once again in cpu-z it would also fall off same as IXTU indicating the losses were confirming in both. The following bench test in cpu-z reported the heat soaked system was only capable of some 80% of standard non-modified, despite the settings for 4.4 ghz set in IXTU while still hot immediately after the stress tests. Frequency dropped to around 4.27 during degradation while voltage remained 1.299. This told me the system was "remaining" degraded after the stress test ended, pointing to either a sustained thermal de-regulation or thermal loss of performance due to real current limiting, whichever might be the case. It is possible thermal limiting dynamics are in effect but that IXTU is failing to report it.

I did verify my bios version is at 1.7 apparently the current rev level.

I have not overlaid the frequency and voltage changes made in IXTU via UEFI as yet, given the UEFI interface is far more detailed, concerned I might make a setup error possibly and do damage.

My first concern to the risk of damage is that I understand remaining in dynamic mode for voltage and amperage while over clocking can invite a run-a-way condition that puts the system at risk if there were a runtime event or OS error that maxed out the system by some cause. Accordingly I set the current and wattage values at reasonable levels (not 1000 amps, OMG), and fixed the volts at 1.299 permitting up to 150 watts and 150 amps where amps still seems potentially high, but then again this is shared current on dozens of pins to the processor, (still far more conservative than IXTU's stated 1000 amps). In the end these wattage and amperage fixed limitations acted NO DIFFERENT than the default settings of 1000, so it may be simply that IXTU is not configuring bios accurately.

The problem between CPU-Z and HWmonitor, I don't know exactly what to look for in analyzing the cause / effect for lost utilization just yet.

I can and will try to overlay the IXTU configuration directly to bios via UEFI configs and see if that helps, but I'm afraid by shutting off the auto scaling features to static voltage and current controls, the processor is failing to sustain up-tick sufficiently to account for latent heat accumulation suggested by the 10 minute plus duration it takes to see degradation show up and the fact it remains AFTER turning off stress test, until the system has cooled back down 10-15 minutes. After cooling off, performance again shows crisp until degradation again occurs in subsequent test runs, consistently. The stated temps at the point of degradation fall off from momentary max peak of 90C, closer to around 70C sustained, so if thermal override was occurring it should be permitting utilization to climb back up again and "oscillate" during stress testing, which it does not until several minutes of cool down, like it's "latching up" de-regulation until temps are below a certain threshold.


Do you happen to have a UEFI configuration setting that would be known to permit static operation around 45 or 46 ghz on the spec set hardware you suggested? I feel really inept trying to cipher all the many config settings in UEFI and definitely don't want to toast this processor or mobo by poking at trial and error.

Thanks again,

Mike

 

[Dlaw]

Thanks Dlaw,

Let me ask one particular question first... Do you advocate fixed voltage and controls or do you favor dynamic scaling be left in the hands of OS/BIOS? The concern for me is to avoid a dynamic config that can inadvertently permit damage if the OS were to loop on high demand error at run time and drive the processor into max sustained as permitted on auto-scaling.

While you're trying to dial in the overclock, it's usually best to turn off all of the power saving features, so a fixed voltage and clock speed is attained. Once you find your max stable overclock, you can usually turn power saving back on.
=======

I initially ran IXTU's stress test program with Unigine Heaven stress 30 minutes out of the box and saw no problems. I even ran two copies of Unigine same time, still no problems at stock settings. The cooler is MORE than adequate on these relatively low demand stress test models, honestly.

Sorry for the details at length. I'm trying to re-state the process I followed, until I have a more standard process I can work from.

So far, changes to configuration have been done "mostly" in IXTU, except that RAM settings were matched in UEFI to match the specs of the RAM you specified, for speed and latency, making sure BIOS knew the RAM speed accurately. I also put the fans into Max speed setting after seeing the utilization fall off, which didn't seem to make a lot of difference. Fan speeds still seem to hover around 1800 RPM, (capable of 2000), even with bios set for max fan and Win10 performance settings on Max processor.

It's likely that the reason you are dealing with instability is because you're using software to overclock.

I did notice a peculiar side effect in that the processor in auto-scaled mode did NOT return back to it's lowest voltages after the stress test until I restarted Win10. It tends to hover around 75 watts after testing which is not a problem, but then after restart before any other appz, it's closer to 35-40 watts. I attribute this to residual OS supports remaining active after application runtime stress tests, which possibly after X minutes might have dropped back on its own as support OS dropped out any residual apps. Others on the web have reported similar sustained higher levels on this hardware combination so it may simply be OS-centric fluff, not substantially a concern at 75 watts either way.

Actually, this is due to setting a static voltage/frequency. Because you're using software to overclock, the overclock only takes effect when the software is enabled. If you were overclocking in UEFI, it would stay at max speed/voltage all the time (until you re-enabled the power saving features).

Yes, I understand the difference between bench and stress. The reason you see me differentiate is that once I saw degradation after stepping up the clock for 30 minutes, I would re-check the benchmark immediately after the performance would bottom out around 80% utilization. in IXTU the bench took nearly twice as long after stress soaking but then reported the same crisp readings it had before stress testing. This lead me to believe IXTU wasn't fully integrating possibly as the bench test in IXTU was reporting inaccurately while CPU-Z confirmed sustained loss below standard. Ditto, application level tuning is hit n miss, understood.

By comparison, CPU-Z was reporting the static voltage cofig I set at 1.299 to reflect about a 10% benefit at 4.4 ghz until again running stress tests and once again in cpu-z it would also fall off same as IXTU indicating the losses were confirming in both. The following bench test in cpu-z reported the heat soaked system was only capable of some 80% of standard non-modified, despite the settings for 4.4 ghz set in IXTU while still hot immediately after the stress tests. Frequency dropped to around 4.27 during degradation while voltage remained 1.299. This told me the system was "remaining" degraded after the stress test ended, pointing to either a sustained thermal de-regulation or thermal loss of performance due to real current limiting, whichever might be the case. It is possible thermal limiting dynamics are in effect but that IXTU is failing to report it.

I did verify my bios version is at 1.7 apparently the current rev level.

I have not overlaid the frequency and voltage changes made in IXTU via UEFI as yet, given the UEFI interface is far more detailed, concerned I might make a setup error possibly and do damage.

Actually, the EXT6 has one of the easiest UEFI/BIOS I've ever used. Most everything is clearly labeled, and since it's one of the best bang/buck Z97 boards, you should have no issues finding stuff on Google.

My first concern to the risk of damage is that I understand remaining in dynamic mode for voltage and amperage while over clocking can invite a run-a-way condition that puts the system at risk if there were a runtime event or OS error that maxed out the system by some cause. Accordingly I set the current and wattage values at reasonable levels (not 1000 amps, OMG), and fixed the volts at 1.299 permitting up to 150 watts and 150 amps where amps still seems potentially high, but then again this is shared current on dozens of pins to the processor, (still far more conservative than IXTU's stated 1000 amps). In the end these wattage and amperage fixed limitations acted NO DIFFERENT than the default settings of 1000, so it may be simply that IXTU is not configuring bios accurately.

The problem between CPU-Z and HWmonitor, I don't know exactly what to look for in analyzing the cause / effect for lost utilization just yet.

I can and will try to overlay the IXTU configuration directly to bios via UEFI configs and see if that helps, but I'm afraid by shutting off the auto scaling features to static voltage and current controls, the processor is failing to sustain up-tick sufficiently to account for latent heat accumulation suggested by the 10 minute plus duration it takes to see degradation show up and the fact it remains AFTER turning off stress test, until the system has cooled back down 10-15 minutes. After cooling off, performance again shows crisp until degradation again occurs in subsequent test runs, consistently. The stated temps at the point of degradation fall off from momentary max peak of 90C, closer to around 70C sustained, so if thermal override was occurring it should be permitting utilization to climb back up again and "oscillate" during stress testing, which it does not until several minutes of cool down, like it's "latching up" de-regulation until temps are below a certain threshold.


Do you happen to have a UEFI configuration setting that would be known to permit static operation around 45 or 46 ghz on the spec set hardware you suggested? I feel really inept trying to cipher all the many config settings in UEFI and definitely don't want to toast this processor or mobo by poking at trial and error.

Thanks again,

Mike

As far as settings are concerned, there's really no way to simply transfer settings from one machine to another. Each system is different, and what works for me might not for you.

Since we're trying stock turbo clocks, try this:

Restart the computer, and download Intel Burn Test, to rule out issues with IXTU. Then, open HWMonitor, and run IBT for around 10 minutes. From there, write down your max VCore reading in HWMonitor, restart to UEFI and plug that voltage in for VCore, and change your frequency to 4400. See what happens.

 

[caddi daddi]

a few notes on what I am reading.
a tune itself will become unstable, I do use it because I bench, at first sign of being unstable that is the first thing i check by removing it.
you have set your ram manually, this is good, but I have found that with 16 gigs of ram i need to add about .05 to the dram voltage, if your ram spec is 1.5 volts, raise it to 1.55 volts, I have found that a slight amount of instability can cause a purring kitten rig to turn into a cranky pig.
on my 4790K/asrock extreme9 build I find that about 1.3 vcore is about all it likes loading it hard for many hours so for long calculations I just accept what clock that allows, in my case that's about 4.8, yours will differ.

don't overclock anything till you get the entire build stable at stock, if it wont do it at default it sure wont do it overclocked.
clock one thing at a time, cpu first, only one adjustment at a time and if it works, write it down.

 

[afpTeam]

Stable is a nice place to be

Thanks all,

OK I "get it", back to basics first with core bios only for tuning.

I reconfirmed defaults have no issues on simple benchmarks acting fairly vanilla on all accounts (but first overlooked stress testing defaults).

Turns out either CPU-Z or HWmonitor, suffers a memory leak in Win 10 currently, something I overlooked in the utilization degradation, just happened to catch my eye while retesting. This of course consumed RAM and stuck the system in 100% file cache mode.

Although I've had some issues with IXTU instability at run-time on occasion, using it simply for bench and stress has worked out ok, with values set in BIOS. Temps holding below 92C on brief spikes, worst case, seems safe enough given not much real world will push any duration there.

BIOS settings are mostly adaptive except for Current, Voltage and Wattage limiters being fixed at 130 each and RAM speed being set by auto-profile for the 2300 spec indicated by the RAM set specs.

I hour stress test at average 4.45 ghz / cache at 4.2 running nicely so far, 1 hour plus IXTU stress testing.

Running Unigine over top of IXTU made no appreciable difference but did sharpen the temp variations to a bit finer granularity steady at 88-92C, with fans at 100% (and quiet) according to SpeedFan 4.51. All cores are matched and tacking around 4.47 ghz average core speed, assuming the lower cache setting is damping it from 4.6 most the time. Temperature rules for now, GOOD starting point for future tests if needed. Might try to lower voltages in the future if cache speed could come up a click or two.

Thanks again for all the suggestions.

Mike

 

[Dlaw]

Very cool, AFP. Glad to hear your issues are resolved.

 

[afpTeam]

First CRISIS by power grid fail

Hi,

Not sure if I was to start a new thread, since the custom system background data is in this thread. Please advise if so and I'll remove this post after following instructions, thank you.

This system has run pretty much flawlessly for months. Today we had a hard power failure that cycled four times as the Grid tried to stay alive before going to full failure. Despite having set the bios power failure mode to stay OFF, the system attempted to reboot with each subsequent power event. I did notice on the first restart attempt, Win10 indicated "update in progress" which of course met with the very next power cycle seconds later. And again, again, then power stayed at full grid outtage.

Once power was restored at my generator, the system boots, passes through the boot options prompt then moves to a flashing cursor upper left corner and stops. MOBO external pilot light solid, red drive light goes quiet, off.

After rebooting to UEFI setup page, I noticed there is an option of Boot failure guard, set to three, so I assume a failure guard must have triggered.

The configuration looks like I recall it being left last for moderate overclock, but I don't see a saved configuration. I tried to save the current HDD config 1 but it seems not to save it.

After an exit from BIOS config, it simply returns back to flashing cursor on the HDMI main monitor, other two monitors indicate No Signal, so the graphics card seems not to be initializing by what seems it cannot or isn't trying to boot from HDD.

Any suggestions greatly appreciated. As well as this system has run, I've had very little reason to learn more of any recovery procedures, so I hope I'm just unaware of a reset method to let bios proceed to drive boot. My original OS Win 10 is on a USB stick but so far the only boot option I see is HDD. ??

Thanks much for any suggestions.

Mike

 

[Dlaw]

Power failures are never good for computer equipment. My first reaction would have been to pull the plug from the wall, although I'm running an APC unit to try and control the current going to my rig as well as possible. In the future, if possible, definitely consider adding a battery backup for situations such as that. It's not foolproof, and I still always unplug my system if the power grid starts acting up while I'm home, but it's that little extra insurance.

So, it's quite possible that you're looking at hardware failure. My first recommendation would be to remove all of the drives from the system, install a spare drive, revert to optimized defaults in UEFI, and try to install Win10 on it. If the installation goes well, and your drivers and apps install and work, then I would install your other drives and check the SMART data on them with one of the various tools available to see if any of them are in dire straits, and backup data as necessary. If the installation doesn't go well, then we'll need to start diagnosing for failed components.

 

[afpTeam]

Power failures are never good [...] In the future, if possible, definitely consider adding a battery backup for situations such as that. It's not foolproof, [...]

Thanks Dlaw,

Indeed, it seems my UPS battery must have sulfated to it's end as the UPS was offline and system was in bypass. Cheap UPS and it wasn't integrated to the OS to learn it was unprotected. I recall doing a reset on it months ago, but I'm guessing it only silenced the audible alarm now after the fact.

The power failures happened so odd, I seemed first like a brown out recovering, but then the grid retries took over and bam, bam, two more times before I could react.

I don't understand why the "Off after power fail" BIOS didn't work. This is like a 5 cent fuse costing me major losses because something in the bios failed to operate correctly as if to wedge a penny in a fuse holder. I mean, who tests a power off sustained mode??? I've dealt with dozens of machines and have never seen that happen.​

Anyhow, I did get it to recognize an optical drive on USB as alternate boot, so maybe I can boot a recovery option from the Win10 USB and see if it can find the SDD or further the process before having to find / buy a SATA 3 HDD.

Thank you again,

Mike

 

[afpTeam]

By the way, is there a procedure to reset a BIOS Boot Failure Guard event? It doesn't show it detected one and I didn't find anything on the web on it's mode of action or means of resent. I did try disabling it and restarting, but it made no difference.

Thanks

 

[afpTeam]

Odd thing... I tried to save the UEFI setup profile and found that I can see all my files on the Partition #2 completely intact readable. Yet when I try to save the profile, it comes back telling me "Failed to save, try again". I've captured pictures of the bios config, but is it possible the system is trying to boot on Partition 1 and needs instead to boot partition #2 ? How can I configure it to try that?

Mike

 

[Dlaw]

Do you have a Linux live system that you could run that has GParted or similar, and see which partition is flagged as "boot"?

 

[afpTeam]

Do you have a Linux live system that you could run that has GParted or similar, and see which partition is flagged as "boot"?

Good thinking. I actually have some volatile data I want to capture before I continue.

I'll give a try.

 

[afpTeam]

Gparted info

I was able to get GParted on USB optical to run.

1. /dev/sda1, NTFS, System Reserved, 500.00 MiB, (used = 351.72 MiB), unused = 148.28 MiB, Boot Flag is set
2. /dev/sda2, NTFS, ! yellow alarm triangle, 237.98 GiB, -----------, ----------

3. in BIOS the partition I see with all my files on it is listed as Partition #2
4. Under storage options the SDD is listed as HDD ???

I tried resetting the SDD setting as SDD but it acted no different on boot re-try.

I have a thumb drive I'd like to save some recent unbacked data to if I can put a utility on that will read the drive as the partition 2 shows these files are there when I tell it to look for a saved bios file. Odd that it's seeing it as partition 2 but regardless, it IS READABLE from Bios at least. My concern is I don't want to touch the drive with an older Nix that may not interpret windows NFTFS correctly or corrupt the boot table, etc.

How can I read this file set and save some data off before moving ahead?
How can I reset the bios to default (simply disable the user OC performance selection?)
I have the original Win10 USB, but I really don't want to have windows do a repair for fear of losing the unbacked data.

Thanks again,

Mike

 

[Dlaw]

The yellow alarm triangle usually means that the filesystem is corrupt, probably from being written to while the power went out. You could try running:

mount -v-ro /dev/sda2 /mnt/xxx

If that doesn't work, it should give you an error at least hinting toward what's wrong with the filesystem.

As far as where to find "optimized defaults", that's usually in the tab where you save and exit.

 

[afpTeam]

Corrupted boot up fail [SOLVED] :)

Dlaw,

Thanks for last. I was just wrapping up clean up when your email came in.

Given time overnight, I was able to use "SystemRescueCD" on the USB optical to fire up a copy of its Gentoo live OS. I used this to mount a memorystick and saved off the few unbacked files by reading partition 2 where the file sets seem to reside, (assuming Partition 1 must be for boot and recovery by windows" Despite the condition of partition 2, gentoo did mount it during probe.

Windows original OS on thumb drive was unable to do a startup repair which inclined me to believe the issue was more on the BIOS side, fingers crossed.

Since the structure of the BIOS appeared intact and the corrupt partition was readable I took a gamble there must have been some kind of configuration parity error in the BIOS interface to the SDD. This MOBO has a dual backed BIOS A <> B by switch on the Mobo. I instructed BIOS to copy A to B (hoping the corruption didn't pass through), then powered down, switched to B and Voila !!! Back up and running, no loss found. Now I know I have a viable B copy saved as well.

I followed up by a clean restart before copying B > A and then powered down and switched back to A. All good, fired right up and away it went, solved.

Not sure of the concept of a parity error but fortunately the copy A > B first didn't cause a problem. I have now saved the User preferred performance set and saved out a .bin of the BIOS to the Partition 2 and memorystick toy.

Lot learned. SystemRescueCD is a nice tool and the file management saved my tail so it made good CYA.

Thanks again for your presence and suggestions. I think I mostly got lucky by taking time to salvage data first before making a risky attempt at recovery. I didn't have an adapter that would let me attach the SDD to a USB on another machine so it was SystemRescueCD or nada. SystemRescueCD also supports Samba, but some how I didn't get that to work and opted for the simpler USB memstick instead.

Regards,

Mike

 

[Dlaw]

I've found trying to access network locations (especially with write access) a pain in any Linux live system, though admittedly I mostly only use them for backup, recovery and partition editing. I'm not as proficient as you likely are.

Good deal, I'm glad you didn't suffer any hardware damage.

Might I suggest using SRCD to create a backup image of your C: drive (/dev/sda2)? It's pretty easy to setup, and only takes about 30 minutes or so.