GIGABYTE 2080 Super Gaming OC
Price Paid: $190
Black Screen when using
Current Project Cost: $469
Reported Issue by the seller:” For Parts GIGABYTE GeForce RTX 2080 Super GAMING OC 8GB GDDR6 Graphics Card. Card will run for 10-15 minutes will then black screen and fans will go to 100%. Parts Only!”
Card number 1 was a massive failure on my part, so I really needed a win for Card 2. You get what’s available in the world of broken cards, but you know when you hear the phrase, if it’s too good to be true, it is? Well, that wasn’t the case with this card. Now let me preface this with it could have been a much worse issue, but when it comes to a card going to a black screen and the fans pushing to 100%, it’s usually a power delivery issue to the card itself over the 12v rail. Also, for those who don’t know what that sounds like, here is a small video of what it sounds like
When this card arrived, I was super stoked as the card didn’t appear to have been opened, which meant that there was a high likelihood that the previous owner didn’t screw up anything internally, so with that being known, it was time to test out the issue to see if we could replicate.
So right off the bat, I noticed something off, aside from the jank-ness of my test bench. The 8 Pin 12-volt connector had a real hard time getting fully inserted into the port, and I’m not sure if it’s from the stiffness of the cable itself or if there is a bent Molex pin internally. Either way, I confirmed that there was a potential issue with the power when the screen told me to plug in the additional power cables
I really like how graphics cards provide this information nowadays and tell you that it’s not getting enough power. Super Helpful. So continuing on, I turned off the test bench, pushed in that 2-pin section of the 8-pin further in, started back up, and the system booted! Doing a quick Nvidia-smi command on the Debian bench, it came up with the correct information. So far, so good.
At this point, I wanted to replicate the issue the prior owner was getting, so I rebooted into the Windows OS and started up the Unigine Heaven benchmark. Not even a minute into the benchmark, the screen went black, and fans went straight to 100%. This was interesting as it never started the fans before the crash, which made me think it’s possible that turning on the fan at a lower idle temperature was asking too much of the power delivery without tripping the issue.
I started to think maybe it wouldn’t be a bad idea to slightly under voltage this bad boy and have a slightly less powerful core but still a more stable run. Upon reboot, I opened my favorite clock modifier tool, MSI Afterburner(https://www.msi.com/Landing/afterburner/graphics-cards). Mainly because it has an excellent tool that will test the GPU to safely determine the power curve for overclocking, but if the standard clock is too high for the power to be stable, it will suggest less. To my surprise, it came back and said the core clock could be increased and still be stable, opposite from what I was expecting. It’s bizarre when you factor in that a GPU-intensive benchmark would black screen and fans to 100% in less than 5 minutes. So, when in doubt, read the logs. Which, when reviewing the crash of one of the benchmarks, was interesting too.
Logging Start - Time: 17:24 / GPU Temp: 41C / GPU Usage: 2% /Memory Usage: 405 mb/ Fan Speed: 0
Haven benchmark Start - Time: 17:26 / GPU Temp: 50C/ GPU Usage: 37%/Memory Usage: 7750.992 MB/ Fan Speed: 0
Last Good Read before crash - 17:27/ GPU Temp: 63C/ GPU usage: 67% / Memory Usage: 7750.992MB / Fan Speed 1397
This was curious as the GPU usage during this test never actually made it past 91%, and our core clock peaked at 101 only twice, but the “power percent” metric was at “1.043” throughout the whole test. For those who don’t usually look at these metrics, that’s abnormally high for low GPU core usage. Kind of odd, which could be the card is having issues with receiving power to the core, so it’s drawing more, but really, I need a more predictive test to check. So now, instead of using Heaven to test, I wanted to check using MSI’s Kombuster, which gives you small but resource-intensive rendered scenes. I booted up FURMARK-DONUT-1700MB for the first test, which yielded yet another wild result. I figured we would see the same results as the Heaven test, but this bad boy ran, and not only did it run, it ran for a full 20 minutes with no issues.
Looking over the logs in this test, our power percent metric only hit 1.0 twice avg being more in the 0.8 range, AND our average GPU usage was 98%, with an average temperature of around 65 degrees Celsius. Much higher than the Heaven benchmark. So really, what the fuck is going on? Deciding to test my confusion, I booted back up Heaven right after I saw Kombuster had been running fine for 20 minutes, and the damn thing completed the benchmark. Not only did it complete, but it did really well.
Being tired and unsure of what was going on, I decided to put down the testing for a day and told myself I’d return to it the next day. Doing just that, I booted back up and attempted to run Heaven, and yet again, it just straight up crashed. So again, I shut down, booted back into MSI Kombuster, and ran the FURMARK-DONUT-1700MB preset, and yet again, the bad boy ran for a full 20 minutes with no issue. So, I stopped the benchmark booted back up Heaven, and it ran fine. So basically, this card needs a fluffer to get going, and once it does, it works fine.
Knowing the card was just really picky and needed a little motivation to get the gears spinning, I decided I wasn’t going to open the card and potentially screw up something internally. Instead, I wanted to test what it would be used for, hash cracking.
So booting back into the Debian host, I ran the Hashcat benchmark and had a watcher running on the Nvidia-smi. Throughout the model, the usage stayed relatively low for what it’s doing and stayed around a temperature of 60C, but no crash on any Linux CLI benchmarking.
We will test the card a bit more with an actual Hashcracking campaign with the RockYou-2021 password file, but from how it looks, it will be okay. The results from the benchmark on Windows password types (what we will mainly use Junkrat for, let’s be realistic here) aren’t bad either.
-----------------------
* Hash-Mode 1000 (NTLM)
-----------------------
Speed.#1.........: 74636.1 MH/s (20.79ms) @ Accel:256 Loops:1024 Thr:128 Vec:8
---------------------
* Hash-Mode 3000 (LM)
---------------------
Speed.#1.........: 38300.4 MH/s (20.80ms) @ Accel:128 Loops:1024 Thr:128 Vec:1
--------------------------------------------
* Hash-Mode 5500 (NetNTLMv1 / NetNTLMv1+ESS)
--------------------------------------------
Speed.#1.........: 39996.4 MH/s (78.86ms) @ Accel:128 Loops:1024 Thr:512 Vec:2
----------------------------
* Hash-Mode 5600 (NetNTLMv2)
----------------------------
Speed.#1.........: 2929.2 MH/s (68.40ms) @ Accel:16 Loops:1024 Thr:256 Vec:1
----------------------------
So that’s that; I think we can say I got away with murder on this card, and I’m excited about the result. I’ll probably revisit the power delivery issue later once we get more working cards, but for now, just like in programming If it works, don’t fix it.
Comments