Mr. Fox

https://hwbot.org/submission/5187340 | https://www.3dmark.com/3dm/88212231

https://hwbot.org/submission/5187322_ | https://www.3dmark.com/3dm/88182771

https://hwbot.org/submission/5187315_ | https://www.3dmark.com/3dm/88209742

I hadn't done any benching for a while. Figured I probably should scratch that itch. https://hwbot.org/submission/5187310 | https://www.3dmark.com/3dm/88209265

They have what they have. I don't dislike the white, or this color. I avoid light-colored hats (and other clothing) because I can't avoid staining them with my grimy way of life, LOL. Hats and caps, especially, start looking rough quickly for me. I generally wear them out in the sun, so they end up with a sweat stain across the part covering my forehead. It only takes a day or two in the Arizona blast furnace to look kind of nasty. Even though they are machine washable, they never look the same again after washing. This should not affect everyone else though. Only sharing why black (or dark colors) are better suited to my needs. I really like that design though. It looks very good.

I watched that video right after Steve released it. It was an excellent video and I am very sad that we have lost EVGA in the graphics card space. With a couple of rare exceptions, every desktop graphics card that I have purchased since the time ATi was acquired by AMD has been made by EVGA. I feel lost without them as my go-to GPU provider. I have low confidence in the product quality and warranty with other brands. Whenever possible, I choose EVGA for my components because their warranty and customer service is unmatched. Their competitors almost universally have a lousy warranty / RMA process. Their chief competitor in the enthusiast space has an atrocious and painful warranty support program that takes weeks to run its course and sometimes with unacceptable outcomes. That has never been my experience with EVGA.

Love the black shirt. Would go for a cap in black. The white looks nice, but it wouldn't after a day or two. White never stays nice and clean for me. I like the graphic on the cap a lot. Good stuff.

We don't know what we don't know right now. But, something is certainly not right. That is too many nearly simultaneous failures. The frequency seems too high to be coincidental regardless of what the underlying cause is determined to be. I don't think the exact cause has been determined. The only thing consistent between GPUs in an extremely strange frequency of identical failures was the driver version. That was actually brought out in the video. Nothing else could be identified (yet) and they are asking for info to help identify both cause and frequency. That said, I do not rule it out as a possibility. We have seen numerous examples of NVIDIA doing things with drivers, including making small adjustments to firmware without disclosing it in release notes. For example, overclock blocking and removing access to voltage controls. This actually just happened with Maxwell GPUs. If you are running the latest drivers on a 980 Ti, you will likely find you can no longer overvolt or undervolt the GPU. I can still remember severely throttling on Kepler SLI systems I owned that was 100% triggered by nasty GeFarts drivers. It never got fixed. NVIDIA did not care. They were selling Maxwell. The only solution was to use an outdated driver if you wanted SLI performance, or buy two new Maxwell GPUs. Those were deliberate acts on NVIDIA's part, but accidents and unintended consequences can also occur. The fractured die can result from extreme overheating or a freakishly high voltage spike, so it is possible (although maybe remote) that physical damage can result from a driver update, especially if it is carrying a special payload of "extras" in the package. Purely speculation now, but not outside the realm of possibility... AMD might have released something in the December driver that was designed to push 7900 XTX performance to make it more competitive against 4080 and 4090 that had unforseen consequences for their last generation GPUs.

Hard to know for sure if it is heat related or something else. Probably not if heat has always been a challenge. Kind of scary though whatever the issue is. It can't be a coincidence that suddenly that many dead GPUs show up in a single repair shop with the same problem and all using the same driver. That's way too many to be a coincidence.

This is what I am referring to, in case you haven't already seen it. By dead I mean non-functional with the GPU core and some of the circuitry destroyed.

This has been a really bad couple of years for GPUs. Crypto-scalping Post-crypto scalping Supply/demand manipulation Unlaunched inferior version of the 4080 NVIDIA 12+4 pin connectors burning Misrepresentations of 7900 XT/XTX performance Continued manipulation/suppression of 4090/7900 XTX supply Relaunched 4070 Ti (the inferior 4080) grossly overpriced Defective AMD vapor chambers AMD drivers killing last-gen GPUs I likely forgot about something that should be on the list.

Wow, congrats on the accomplishment. I bet you have played Cyberpunk more hours than I have played all games in the aggregate for the past 5 years. I don't remember the last time I hit 100% achievements. I think I can count on one hand how many titles I have actually played through to the end during that time span, and a couple of them are the same title. I usually end up losing interest before finishing.

/img/logo.png Mr. Fox`s Memory Frequency score: 4100 MHz with a DDR5 SDRAM HWBOT.ORG The DDR5 SDRAM @ 8200MHzscores getScoreFormatted in the Memory Frequency benchmark. Mr. Foxranks #56 worldwide and #56 in the hardware class. Find out more at HWBOT.

/img/logo.png Mr. Fox`s AIDA64 - Memory Read score: 134496 points with a DDR5 SDRAM HWBOT.ORG The DDR5 SDRAM @ 8200MHzscores getScoreFormatted in the AIDA64 - Memory Read benchmark. Mr. Foxranks #12 worldwide and #6 in the hardware class. Find out more at HWBOT.

Thanks, Brother. I hope you had a nice Christmas and New Year.

OK, I think I got this dialed in now for my 24/7 overclock. It's so easy to run these generic green A-die sticks at 8000 MT/s. It's ludicrous in light of how many retail kits I RMA'd with RGB rainbow vomit and sloppy loose gamerkidz XMP profiles that cost double, were pure garbage and would barely even boot at speeds like this. Consumers are getting screwed real hard.

My generic naked green A-die sticks arrived today from AliExpress. Seem to be working well, so I will put the jackets and water block from the M-die on them this weekend.

I am finding v2.05 to be pretty decent now. My generic green Hynix A-die modules from China should be here late this week. My M-die modules definitely work better, so I am eager to see how those modules run. The memory I used in making this video are the Sabrent modules that I did the ExtremeHW review on. They are bench stable at 7200, which is pretty impressive for M-die.

Mr. Fox`s AIDA64 - Memory Read score: 129455 points with a DDR5 SDRAM HWBOT.ORG The DDR5 SDRAM @ 8000MHzscores getScoreFormatted in the AIDA64 - Memory Read benchmark. Mr. Foxranks #14 worldwide and #7 in the hardware class. Find out more at HWBOT.

I spoke too soon. Not ready for prime time, but it will be great when they correct a few mistakes. https://forums.evga.com/FindPost/3588974

Well, there is a firmware update out for the Z690 Dark Kingpin mobo, and I have to say it's looking pretty sweet. Has some nice extreme memory OC profiles from Vince (Kingpin) and Luumi. I have generic green M-die and I never dreamed it could run 7800. It couldn't with the previous firmware versions. This is not optimized or stable. Right after I flashed it I grabbed at 7800 profile from Vince in the menu, saved the settings and *BOOM* it ran. Going to be tuning it up so it is stable. Not too shabby for sticks I paid $80 each for, not even part of a kit.

I forgot to document... even this application functions correctly on the Z690 Dark. Per-core or all-core CPU frequency can be adjusted on the fly. This is broken on the Z690 ASUS mobo.

Overclocked benching and gaming is what I do that requires (or produces the desire) to monitor frequency. I always overclock everything that can be overclocked. I have been a Mint fan for longer than I can say and I have used Mint the most. I used it almost exclusively for many years. Sometimes I experiment, but I always come back to Mint. I recently started playing with KDE and found some things about it (aesthetically) that I liked, some I didn't. I am definitely not in love with it. I have used it less than 6 months. I like any desktop environment with a GUI/shell that closely resembles the classic Windows Vista/7 environment. I dislike any GUI/shell that does not. Cinnamon and Plasma are the closest thing to a classic Windows desktop. I tried the latest Mint on the ASUS system and no dice. Still broken. I installed the latest available 6.* kernel and still no dice. I think I like ASUS less with every product generation. I have had more issues with their garbage being broken or failing than any brand other than AMD. ASUS used to sell well-made, reliable high-quality products but they are approaching the failure rate of AMD in my experience. Below is an example of a newer CPU, same chipset, things functioning correctly using kernel 5.19.0-23-generic. I think pointing the finger at ASUS is appropriate.

I think you are both correct. It does seems to be an ASUS-specific firmware issue. Everything functioned correctly with the 12900KS on the Z690 Dark Kingpin mobo and the 13900K currently installed in it has no issues like the ASUS mobo does. Thank you both for the replies. Since my previous post I installed openSUSE Tumbleweek with kernel 6.0.8-1 and several things changed, some better and others worse. I am planning to try Linux Mint "cutting edge" distro to see if it is better. Mint has always been one of my favorite distros anyway.

This is the system I am struggling to make viable on Linux. I think it may be something bugged in the ACPI implementation by the dumb-dumbs at ASUS on the Strix ZX690-E. I cannot get the CPU turbo clocks to display correctly in any desirable monitoring tools. CPU-X shows the 12900KS clocks to a fixed 5.4GHz (correct) under load, still not correct at idle, but all of the "normal" things I use show either a fixed 3.4GHz (c-states disabled) or a fixed 4.1GHz (c-states enabled). I have tried KDE, POP!_OS and ZorinOS and all have the same issue. I have tried passing a variety of kernel parameters in GRUB. I have installed different packages intended for monitoring clock speeds and it is hit or miss. The couple that actually work correctly are worthless to me because they are CLI stuff I can't use the way I want to. I also wonder if it is something with the 12900KS not being recognized properly like a 12900K and 13900K. At any rate, this is a classic example of a thing that make noobs believe that Linux is not a viable replacement for Windows, and on this system it probably isn't solely for this reason. I would not embrace Linux if this were an example of normal, but I have used it enough to know it is an exception (albeit a more common problem than desired).