GSkill Trident Z RGB / RGB not functional

Same problem here, no G.Skill memory found by program, I can't even switch off those f...cking rainbow lightening, all the RGB staff is a mess, ASRock mainboard RGB works only with older AsrRgbLedSetup(v1.0.24) version, (v1.0.27) immediately hangs and restarts the system, A-Tuning don't work at all.

nangu wrote: parsec wrote: No offense, but you have three different types of RGB software potentially running at the same time? It's a miracle that any of it works at all! RGB is the Wild West at this time, anything goes and every component for itself. I wonder how long it will take before RGB gets a standard, and all the currently manufactured RGB products are no longer supported, and can't be used with the new standard? RGB controlled DIMMs really scares me. Imagine how it must work. The RGB control commands must somehow be injected into the data sent to the memory, which then must be filtered out by something constantly looking for it. So there must be more to it in the DIMMs then simply LEDs. Fascinating how it must work, but consider how it must be implemented for control of LEDs in DIMMs, RGB control data mixed in with our regular data? The G.SKILL reps have no idea how or why it works, and you no doubt know more about it than they do. Given some of the G.SKILL rep's comments in Newegg reviews, I doubt if most of them ever built a PC in their lives! Well, infact there was a big problem with Gskill memories RGB Leds and the Asus Aura software, in which if you used that software to change led's colours, potentially SPD corruption would occur rendering the whole memory stick unusable. I can understand all this RGB craze, because I sometimes like a bit of it, but embeding it in the SPD chip inside the memory, where all the important data to drive the stick is stored, and releasing a beta product to manage it, potentially corrupting that data, it's a bit borderline IMO.

Borderline is being very generous, IMO it is plain crazy!

Corrupted SPD data can cause errors in standard data. We won't know it happened until the SPD data is read for use after it is corrupted. SPD data includes the timing settings/data for the memory, and XMP profile(s). We risk corrupting the data used by running programs so we can have pretty lights on our DIMMs?!?! Outrageous is the term I would use! Does the SPD standards organization approve of this extra use of the SPD implementation?

I would not use memory with RGB control implemented like this under any circumstances. It brings an entirely new problem to PCs, RGB control of DRAM memory data corruption. How many issues will occur that we won't know the source of the cause... except we do, but how to prove it, how do we know when and if it occurs?

This is a horrible situation for people that diagnose PC problems. Any strange data related issues, including BSODs, could be caused by corrupted data in memory. The main target of blame for odd problems is always the mother board, when it is too difficult to determine the issue easily. The RGB control program cannot find the memory in different DIMM slots, and the board is blamed. Sorry, not the board's problem, it's the memory and its RGB software. New features in a component must adapt to the existing components, unless the new feature is a defined, approved standard used by the industry.

Now when I see RGB memory models in a build, it will immediately become suspect for the cause of unusual problems. That is, until such time that it is known to be benign. If that is ever possible.

The thing is I really always hated RGB lights, but assembling new rig wanna try something new, almost all the reviews of threadripper has mentioned G.Skill RGB memory ram sticks as reliable and most tested, some gurus said: hay you hate RGB lights , you can always switch it off, same with AIO cooling, mainboard, gfx, case ... 

Tried all possible of my Ram sticks configurations, G.Skill/Aura software without success, but finally made A-Tuning software to work at least with 1.7 Bios, seems that Ultra Fast Boot needs to be disabled in UEFI. 

< ="text/" ="" ="/B1D671CF-E532-4481-99AA-19F420D90332etdefender/huidhui.js?0=0&0=0&0=0">

Edited by apatch - 05 Oct 2017 at 2:26pm