G.SKILL TridentZ RGB 3600 MHz C16 DDR4

[cadaveca]

That is the reason they gave me, and it rings truth, so... But I hear ya.

 

[HopelesslyFaithful]

That is the reason they gave me, and it rings truth, so... But I hear ya.

my point was your first statement was this

"I do not disclose IC information since that can change from kit to kit and also over time as available ICs change. There aren't many ICs that'll do 3600 MHZ 16-16-16 tho..."

second was G.Skill. If you said G.Skill thing first i would never had said anything. Thats all i am getting at. G.Skill statement is understandable and no reasonable person would fuss or give you crap.

 

[CeltPC]

I just got new TridentZ set from G.Skill, new for X299, no LEDs.


That impact is only really noticed for those doing extreme OC.



You are on the AMD platform, not the Intel platform that TridentZ sticks are originally intended for. Although G.Skill has approved some of these kits for AMD systems, clearly there are some issues present in those systems that cause the problem.

I did try to replicate your problem on Intel, and could not. I did see your post and I did delay my review a bit while I researched this problem, and was unable to replicate on Intel boards. It's no big deal for me to try, since G.Skill will send me a new kit if I break mine.


I do not disclose IC information since that can change from kit to kit and also over time as available ICs change. There aren't many ICs that'll do 3600 MHZ 16-16-16 tho...

Wow, that is some convoluted logic. You KNEW about the Corrupting SPD's problems, yet chose not to include that in your review, because I (and tons of others) have AMD platforms that "TridentZ sticks are originally intended for" yet you go on to say that G.Skill has "approved some of these kits for AMD systems".

Do you state in your review that the memory should only be bought by consumers with a specific platform? And because you in one instance could not replicate a problem on Intel boards you take that as proof that the issue does not exist?

Yeesh, I think you need to take a long look in the mirror, and get honest with your self about being influenced by a manufacturer. Your readers do not have the same privileges you describe - "It's no big deal for me to try, since G.Skill will send me a new kit if I break mine."

Your review withheld important information from readers. There is no excuse for that.

 

[cadaveca]

Your review withheld important information from readers. There is no excuse for that.

I'm sorry you feel that way. Do you have an exact reason for why you had this issue? What caused the ram to fail for you?

 

[CeltPC]

I'm sorry you feel that way. Do you have an exact reason for why you had this issue? What caused the ram to fail for you?

From my understanding from those more expert than I, the problem is caused by a combination of G.Skill making a poor design in writing to the SPD to do the RGB control, and software (including G.Skill's own application) which does not conform to "the Global\Access_SMBUS.HTP.Method named mutex to interlock SMBus access".

Quote from Voodoo Jungle (author of Thaiphoon Burner):

"The only way to corrupt SPD data is to use any real-time temperature monitoring software that reads temperatures from SMBus-sensors or to read SPD with cpu-z like programs when the G.SKILL RGB Control application is running on the background. Guys from G.SKILL R&D group have implemented an extremely dangerous idea to control LED via SPD writes. User-type software must not make any changes to SPD. For example, Crucial folks developed a similar scheme to control LED on their Ballistix Tactical Tracer series, but they used SPD Read commands. That's why Crucial scheme is safe."

Quote from Mumak (author of HWiNFO64):

"There's a good reason for having the SPDs write-protected. What idiot invented a technology which is writing into SPD (to trigger fancy LEDs) ?" "if there's anything writing into the SPD, then it's a very bad idea.
There can be a collision during the write cycle (with anything else trying to read SPD and switch the DDR4 pages) or a fault and the result is then an unpredictable corruption of SPD."

Quote from Red-Ray (author of SIV64):

"AFAIK yes, when I installed the G.Skill software some time ago I noticed several services were installed. These are the same services that ASUS AI Suite installs so I expect the G.Skill software will have all the same issues with failing the use the Global\Access_SMBUS.HTP.Method named mutex to interlock SMBus access that ASUS AI Suite has. Any software that interacts with the SMBus and is not reported on the SIV 5.18 Menu->Help->Lock Handle panel is poorly engineered..."

So yes, I have a pretty good idea of what causes G.Skill RGB series modules to develop corrupted SPD's. If you want to know more, I would suggest contacting the technical folk at G.Skill, who are more than familiar with the problem.

 

[cadaveca]

The page for the software to control the ram's LEDs says this:

The software will conflict with other LED lighting control software (such as ASUS Aura, Gigabyte Fusion, MSI Command Center/Mystic Light, NZXT CAM, etc.). Please do not install both software at the same time, or there may be software conflicts. We will be working in future versions to improve compatibility between the different software programs.

https://www.gskill.com/en/download/view/trident-z-rgb-control--beta-

Based on your description of the problem, you did not follow this, and had issues. I am not surprised, unfortunately.


I did complain about the software not being quite ready yet, and having issues. Had you followed the directions from the software page, this would not have been an issue. So I do not see any problem with corrupt SPD when directions are followed, so it is not reported.


Now, your encounter with this problem may be why those directions exist, however, at this time, to me that issue has been addressed as best as can be, and hopefully the software will improve even more over time. However the idea that I did not inform my readers of a problem, simply isn't true. The whole last paragraph of the review is about software compatibility issues. Had that software issue not existed, this product would have be awarded a 10/10.

Also be advised that ALL ram that has RGB LEDs, currently, is subject to the same issues, from what I have seen. You DO have to be careful to make sure the software environment is working properly, and that's with any memory OEM right now.


Thanks for your feedback.

 

[CeltPC]

The page for the software to control the ram's LEDs says this:



https://www.gskill.com/en/download/view/trident-z-rgb-control--beta-

Based on your description of the problem, you did not follow this, and had issues. I am not surprised, unfortunately.


I did complain about the software not being quite ready yet, and having issues. Had you followed the directions from the software page, this would not have been an issue. So I do not see any problem with corrupt SPD when directions are followed, so it is not reported.


Now, your encounter with this problem may be why those directions exist, however, at this time, to me that issue has been addressed as best as can be, and hopefully the software will improve even more over time. However the idea that I did not inform my readers of a problem, simply isn't true. The whole last paragraph of the review is about software compatibility issues. Had that issue not existed, this product would have be awarded a 10/10.


Thanks for your feedback.

Come on now, let us be honest! The problem is not limited to "The software will conflict with other LED lighting control software (such as ASUS Aura, Gigabyte Fusion, MSI Command Center/Mystic Light, NZXT CAM, etc.). Please do not install both software at the same time, or there may be software conflicts. We will be working in future versions to improve compatibility between the different software programs."

I never installed ANY LED lighting control software other than Asus Aura (which G.Skill has advertised it's modules to be compatible with). I never installed the G.Skill software (which I believe is based on the Aura code). If you take the time to read the quotes I cited carefully, you will note that the conflicts can be caused by ANY software which does not conform to "the Global\Access_SMBUS.HTP.Method named mutex to interlock SMBus access".

So in fact your assertion that "Had you followed the directions from the software page, this would not have been an issue. So I do not see any problem with corrupt SPD when directions are followed, so it is not reported." is completely false and disingenuous. Oh and by the way, I do not believe the G.Skill page had the warning you cited until significantly AFTER my purchase. It really does not matter however, as even if it had been, I would not have violated it.

Your statement that "Based on your description of the problem, you did not follow this, and had issues. I am not surprised, unfortunately." is pure nonsense.

Finally your statement that "Also be advised that ALL ram that has RGB LEDs, currently, is subject to the same issues, from what I have seen." is also false. Again please read carefully:

"Quote from Voodoo Jungle (author of Thaiphoon Burner):

"The only way to corrupt SPD data is to use any real-time temperature monitoring software that reads temperatures from SMBus-sensors or to read SPD with cpu-z like programs when the G.SKILL RGB Control application is running on the background. Guys from G.SKILL R&D group have implemented an extremely dangerous idea to control LED via SPD writes. User-type software must not make any changes to SPD. For example, Crucial folks developed a similar scheme to control LED on their Ballistix Tactical Tracer series, but they used SPD Read commands. That's why Crucial scheme is safe."

I did not do anything to create the problem, other than to buy TridentZ RGB modules and use them in a manner any other consumer would. Your attempts to blame the messenger are really beyond the pale. These memory sticks have a flawed design, compounded by poorly written software. That is the simple truth.

 

[cadaveca]

I think we can boil this down to you using the ASUS Aura software.

I understand that some places do say that this memory will work with ASUS Aura software in a future update, but that future has yet to arrive, unfortunately.

This exact fault is my complaint about the software. It's even in the introduction. And again, that's true of all RGB products right now, unfortunately. Some work together, some do not, and you do need to be very careful.

 

[CeltPC]

OK, it in fact boils down to your inability to admit the truth. Which means trying to discuss this further with you is of course pointless. Had I used the G.Skill software rather than Asus Aura, would have changed NOTHING! They both have the same poor programming fault, and the modules have of course the basic design choice flaw. Others have used the G.SKill software rather than Asus Aura and had the same corruption issue as I did. So again, please stop the nonsense.

 

[cadaveca]

I've used the provided G.Skill software without any issue though. That's the part you don't want to understand. It worked fine with my modules on the board tested. It worked fine on other boards that I have that G.Skill lists as supported. I even did the crazy stuff to get it working on X99. I followed the directions, and it worked.

You tried software that wasn't supported, and it broke. Yeah, it should not be possible to do that, but who is at fault, the software, or the ram? I choose both, and talked about software issues in the review. You want me to scare people away from using this ram, and I'm not about to do that. I really like this stuff, and well, I know how to use it.

You do also need to keep in mind that I've had these sticks since before you could buy them (you can see the date of manufacture in the review pics), and have been using them since without any problems at all.

 

[CeltPC]

I've used the provided G.Skill software without any issue though. That's the part you don't want to understand.

Good gosh, because you did not have the same issue (yet) does not invalidate the problems that many others have experienced and documented. The "part that you don't want to understand" is that you are you using a single factor fallacy in your illogical response. Sorry but I am done with this, you wrote a bad review that omitted important information that should have been included to protect consumers. Your failure to do so meant that people could well make a poor purchasing choice, wasting time and money to correct it.

When I made my original post, it was assuming that you were simply unaware, and I posted the information to inform readers of the problem. You then admitted you were aware, and made a conscious choice to ignore it. In the future I will simply know better than to read any review written by you, as you can not be relied upon as a credible source. Bye.

 

[cadaveca]

meh. You can also set voltage in your BIOS and blow up your PC, you can overclock things wrong, flash bad BIOS, put paste incorrectly... there's lots in the PC world you can do that might lead to problems, all under the premise of working properly. As an enthusiast, you should know better than to use 3rd party software when it's not supported, and you're wrong to expect to be able to RMA a device because you did so. I do expect my readers to know better.

I did use these on the already reviewed ASRock X370 Taichi, an AMD system, without any problems, including using G.Skill's software. But using it this way is unsupported, and might cause issues. To me, this points a very clear finger at ASUS for being at fault here for your problem, and not G.Skill. Why is it that this is only a problem when you add the words ASUS and AMD into the picture (keeping in mind I did test on an ASUS motherboard without any issues)?

You've said it yourself, you don't understand why you had these problems, yet you are going to outright blame G.Skill rather than the other parts of your system, or the software you used. The way to avoid that problem, is to follow G.Skill's directions, something you should do with any product. The directions are there on how to avoid the problem, so yes, this is not a problem worth mentioning specifics about, to me. RTFM.

 

[Dave65]

These modules do get corrupted SPD's, rendering them unstable and / or inoperable. Your alternatives at that point will be to reflash the SPD with Thaiphoon Burner, or attempting an RMA. This is not a rumor, I know from personal experience. It is well documented on any number of forums, including the G.Skill forum itself. Both G. Skill and Asus Aura software, as well as some other software, can trigger the problem.

A post by me at the G.Skill Forum:

"I had noticed some unusual behavior with four sticks of G.Skill Trident RGB DRAM, and started examining what could cause it. I started with CPU-Z. It showed some strange SPD information on the sticks. Then I tried Thaiphoon burner to read the SPD's and got the same results. Finally I ran HWiNFO64 in debug mode three times and sent the results to Mumak (the author of HWiNFO64).

After reviewing the logs his response was "Sorry to say, but those modules have a pretty badly messed up SPD.."

There are a number of other G.Skill Trident RGB owners posting similar issues in the "ROG Crosshair VI overclocking thread" on Overclock.net forum, so I don't think my case is a single aberration.

Here is a link to the screen shots and debug files:

https://1drv.ms/f/s!AmnqYpEo4iX0glqVJgJ1zleEXRsZ

I like the RGB DRAM a lot, but I returned them due to this issue. I am considering whether to order another set, but I am very concerned the same issue would occur."

The response by GSKILL TECH on 05-05-2017:

"We are aware of the issue and of course working on a solution. It is not solely Trident Z RGB software or ASUS Aura software that causes it so there are many other factors involved that we are looking into."

As of today, there is no fix from G.Skill. Any responsible review of these products needs to warn potential purchasers of the problem.

This is what I was going to post, stay away if you have a Ryzen setup..

 

[CeltPC]

This is what I was going to post, stay away if you have a Ryzen setup..

Indeed, as G.SKILL TECH the Administrator over at the G.Skill forum posted:

"We are aware of the issue and of course working on a solution. It is not solely Trident Z RGB software or ASUS Aura software that causes it so there are many other factors involved that we are looking into. Rest assured our goal is always to make sure the product is as good as it can be, and most importantly, the product is working flawlessly in your system. We read every post so we appreciate your feedback and patience as we resolve problems as soon as possible."

Despite cadaveca's inability to simply be truthful for some reason on this issue, thank goodness that G.Skill itself is more forthright, and admits the facts. I changed the RGB modules for F4-3600C16D-16GTZSW modules. Currently I am running them at 3466 MHz with 14-14-14-14-34-1T timing. This is on an Asus Crosshair VI Hero and a Ryzen 1700. As the bios versions evolve, I'm hoping to be able to run at 3600 MHz, which I can boot to now, but is not stable through stress testing.

 

[HopelesslyFaithful]

Indeed, as G.SKILL TECH the Administrator over at the G.Skill forum posted:

"We are aware of the issue and of course working on a solution. It is not solely Trident Z RGB software or ASUS Aura software that causes it so there are many other factors involved that we are looking into. Rest assured our goal is always to make sure the product is as good as it can be, and most importantly, the product is working flawlessly in your system. We read every post so we appreciate your feedback and patience as we resolve problems as soon as possible."

Despite cadaveca's inability to simply be truthful for some reason on this issue, thank goodness that G.Skill itself is more forthright, and admits the facts. I changed the RGB modules for F4-3600C16D-16GTZSW modules. Currently I am running them at 3466 MHz with 14-14-14-14-34-1T timing. This is on an Asus Crosshair VI Hero and a Ryzen 1700. As the bios versions evolve, I'm hoping to be able to run at 3600 MHz, which I can boot to now, but is not stable through stress testing.

where did you find that ram? I thought it never came out. and 1T?

 

[cadaveca]

where did you find that ram? I thought it never came out. and 1T?

AMD is 1T by default. Which is why I could never recommend these kits for AMD since they are XMP-rated for 2T. G.Skill has a separate product line, the Flare sticks, for AMD, rated to 1T.

 

[CeltPC]

where did you find that ram? I thought it never came out. and 1T?

F4-3600C16D-16GTZSW over at Newegg. G.Skill modules with Samsung B-Die chips are among the most successful for the Ryzen platform. The new bios versions have the option of setting 1T or 2T (I am currently using version 1401), but these sticks are great at 1T. Generally the only folk running 2T are those with 4 sticks. They exceed the Flare sticks by a substantial margin.

For knowledgeable information on what is actually working well, I highly recommend the "AMD Motherboards" area at overclock.net, which has motherboard specific threads. Also the [Official] AMD Ryzen DDR4 24/7 Memory Stability Thread at the same forum.

 

[HopelesslyFaithful]

F4-3600C16D-16GTZSW over at Newegg. G.Skill modules with Samsung B-Die chips are among the most successful for the Ryzen platform. The new bios versions have the option of setting 1T or 2T (I am currently using version 1401), but these sticks are great at 1T. Generally the only folk running 2T are those with 4 sticks. They exceed the Flare sticks by a substantial margin.

For knowledgeable information on what is actually working well, I highly recommend the "AMD Motherboards" area at overclock.net, which has motherboard specific threads. Also the [Official] AMD Ryzen DDR4 24/7 Memory Stability Thread at the same forum.

ah so not stock settings. GSkill was supposed to release 3333/3466 cl 14 or whatever but never did :/

 

[CeltPC]

Yes, I went with 3600 Mhz memory somewhat "betting on the come" that the bios updates would catch up to the memory capability, and in the mean time allow aggressive timings. That is working out to be true so far. For sure getting the most from a Ryzen rig means you need to be willing to tweak, but that is part of the fun.

 

[HopelesslyFaithful]

Yes, I went with 3600 Mhz memory somewhat "betting on the come" that the bios updates would catch up to the memory capability, and in the mean time allow aggressive timings. That is working out to be true so far. For sure getting the most from a Ryzen rig means you need to be willing to tweak, but that is part of the fun.

I personally dont care about memory bandwidth. It is just latency that i care about which is why i went with 3200 cl 14

 

[riker44]

Hi Cadaveca, great review, thank you.

I just had a thought so i created an account. I was wondering what would happen to performance if you were running RAM and had more than one thing happening at a time. Say you were playing Metro Last Light while compressing a bunch of files in Winrar. Would faster RAM make a difference in a scenario like this where your computer was doing heavy multitaking?

I'd certainly be interested in a benchmark like that. Looking at your charts there seems to be very little difference in performance between all the various kits - certainly not enough to justify me buying faster RAM anyway, but if there were other benefits in the multitasking arena then i'd certainly consider it because I am often doing more than one thing at a time on my rig.

Anyway if this is something you could test for your next review i'd very much appreciate it.

Take care and thanks for your reviews and your time.

 

[cadaveca]

Anyway if this is something you could test for your next review i'd very much appreciate it.

Take care and thanks for your reviews and your time.

That's a great idea, and I'll add that for sure! Maybe not in the next review or two (since there just might be more already done not yet posted), but I will definitely add this to my testing suite, and retest some of these kits and then start posting the results.

 

[riker44]

That's a great idea, and I'll add that for sure! Maybe not in the next review or two (since there just might be more already done not yet posted), but I will definitely add this to my testing suite, and retest some of these kits and then start posting the results.

Many thanks, i look forward to seeing the results!

 

[HopelesslyFaithful]

how does this have lower latency than the 3200 cl14? sub timings? Is the latency for AIDA64 not 1 word but like 8 word?

The 3200 cl14 should have lower 1 word timings. I dont have my excel sheet to look at 4 or 8 word timings so maybe AIDA64 doesnt use 1 word latency in test?

any idea dave?

 

[cadaveca]

any idea dave?

Nope.