TL:DR - I ran some tests with two sets of timings at DDR4 3200 MHz clock speed with a 4.2ghz i7 6900, and saw barely measurable differences in performance which fall within the margin of error and are so small anyway as to be irrelevant
 
Long-winded - When I bought the motherboard and RAM for my rebuild, I spent extra $$ for CL 14 (14-14-14-34-2T) DDR4 3200. It cost me around $239 for 32gb (4x8gb). Cheaper 16-16-16-36-2T or 16-18-18-38-2T RAM at that size and clock speed was available for between $164 -$194, depending on the model and timings. This means I paid about a $40-60 premium in order to have RAM with the tightest timings at that clock speed.
 
I do recall reading some articles and comparisons in the past that predicted that the real-world differences would be meager, but all of those comparisons used older 18-18-18-38 speed RAM at DDR4 3200Mhz speeds, and compared with 14-14-14-34 timings at slower speeds like 2133 Mhz or whatever. When I made my decision I reasoned that if the improvements were meager with an increase in clockspeed because of the worse timings, that using the same aggressive timings along with the quicker clockspeed would actually mean a little more.
 
So tonight I decided to test this out. I ran a bunch of different cpu-related tests with my machine (i7 6900 running at 4.2ghz with cache at 3.5ghz) using the DDR4 3200 XMP setting, which gives me the 14-14-14-34-2T timings. I did modify that, changing the 2T to 1T, and it's been perfectly fine. I then rebooted the machine and set the timings to 16-18-18-38-2T (left the rest of the settings whatever they already were at). I reran all of the tests.
 
The results are astounding, but not in a positive way. It's astounding how little advantage there is in buying aggressively timed RAM these days.
 
For each of these tests I ran the test five times and have averaged the results. For the Cinebench R15 cpu benchmark I ran it 10 times for each RAM speed, because it's such a quick benchmark.
 
Intel Extreme Tuning Utility benchmark
14-14-14-34-1T: 2286.4
16-18-18-38-2T: 2289 (.1% faster)
 
POV-Ray 3.7 benchmark scene rendered at 1920x1080 with AA0.3, elapsed wall clock time:
14-14-14-34-1T: 371.064 seconds
16-18-18-38-2T: 369.11 seconds (about .5% less elapsed time)
 
Cinebench R15 benchmark
14-14-14-34-1T: 1772.4  (.2% faster)
16-18-18-38-2T: 1768.6
 
Fire Strike with Precision X OC set to +130/+450 (my recent 24/7 settings)
14-14-14-34-1T: 20530.4 (.3% faster)
16-18-18-38-2T: 20470.2
 
Time Spy
14-14-14-34-1T: 8234.2 (.25% faster)
16-18-18-38-2T: 8213.4
 
You'll notice that the Intel Extreme Tuning Utility benchmark and the POV-Ray 3.7 renders actually gave the slower RAM a very slight edge. The Cinebench, Fire Strike, and Time Spy tests gave a very slight edge to the faster RAM. The largest difference was .5%, with most difference being .1% to .3% either way. I believe that with only five runs each other than the Cinebench test's 10 runs, it's almost certain that the variance from run to run was larger than the actual differences, and therefore a larger sample size might change the actual results, though probably not enough to make the differences more meaningful.
 
Now, to make sense of this, I consider the following: this cpu is the Core i7 6900, which has a 20mb L3 cache. Compare that cache size to a Skylake chip like the 6700, which has 8mb of L3 cache shared by its 4 cores. I would bet that the smaller cache processors would see a more meaningful improvement due to RAM timings than these socket 2011-v3 chips with their gargantuan caches. How much more of an improvement would have to be measured, but I bet it could be.
 
I have no doubt that RAM speed could make a difference in other kinds of tests. For example, if I were to download some video encoding tests and encode some videos of several gigabytes in size, then RAM speed would probably make a measurable difference, because we'd be talking about data sets that couldn't be held entirely within the cache most of the time. I can imagine that rendering 1080p videos in Adobe Premiere, for instance, would probably show some differences due to RAM speed.
 
One thing I didn't test, which I'd like to go back and try out when I have some more time, maybe tomorrow night, would be the Ashes of the Singularity cpu tests. There's enough data being accessed by so many different threads in that game that there's a pretty good chance that the cache won't be able to hide all the accesses, and a measurable difference may be shown.
 
I'm going to bet that in most other games the difference in performance due to paying $239 for 32gb of RAM rather than $164 for slower 32gb of RAM will be from unmeasurable to possibly measurable by more or less meaningless.
 
I knew there was a chance that it could turn out this way, having read the other articles from a couple years ago when the DDR4 3200 MHz RAM being tested was all of the 16-18-18-38 variety, but I deemed it worth the chance. I probably don't get to keep smugly thinking my machine is superior by dint of faster RAM speeds anymore, though some will always assume that faster is faster, whether it is actually better in real life or not.
 
Looking back, I don't know whether I would have rather ploughed the extra $75 into going with 64gb of the slower RAM, or whether I would have just saved the $75, knowing I was probably going to buy $75 more worth of water-cooling paraphenalia at some point anyway.
 
I can at the very least say, with confidence, that the tighter timing RAM on my machine makes no significant difference in the kinds of workloads I put my machine to 95-99% of the time.

Wowza, so no difference at all in those tests. Anything less than 3-5% is usually considered within the margin of error, and you saw a max difference of 0.25%.

Biggest difference I've seen is big publishers mention wiping the HD between tests. 
 
They also have no extra software loaded or running, like security software.
 
By changing the Timing and not the physical RAM, makes me wonder what if any impact that playes
 
DDR4 RAM unless your benching for a record; if you have decent RAM, OC seems to be more trouble than its worth

Btw, one way to help us understand why these results are so small is Amdahl's Law. Amdahl's Law is a mathematical expression of the common sense understanding that any speedup in a system is only going to improve overall system performance in relation to what percentage of the system's overall performance is contributed by what is being improved. So, for instance, if I have a chunk of code that takes up 10% of the time in a system, and I improve that chunk by 10%, then overall performance only improves 1%. If I double that chunk of code's performance, overall system performance is only improved by 5%, etc.
 
So, due to the very large cache size of these Broadwell-E processors, and the likely small data sets we're dealing with, and the efficiencies in cpu processing brought about by hyperthreading (if one thread stalls out waiting on a memory fetch, the cpu simply switches to another thread and keeps working), it's likely that the amount of time that cpu cores spent actually stalled out while waiting for memory fetches is fairly low. It may well be that the more aggressive timings really do have a large impact on memory read speeds, but if the cpu is only stalled out waiting for memory reads 5% or 10% of the time, then even a 10% to 20% improvement in read speeds due to more aggressive timings would only be expected to show up as an overall 1% or so improvement.
 
My prediction would be that someone running a cpu with a significantly smaller cache (like a 6700 with its 8mb cache, which is actually still quite large) would detect a larger impact of the faster timings.
 
I would also predict that someone with a very cheap processor that doesn't have hyperthreading, like some Core i5 processors, would also detect a larger impact of the faster timings. One of the things hyperthreading does is cover over and essentially hide the impact of the processor stalling due to memory fetching from RAM.
 
I guess what I'm saying is that Broadwell-E processors are probably the worst ones to use to test differences in memory speeds, simply because these Broadwell-E processors have so many technologies designed to hide the effect of memory latency that you simply won't see very much of it.
 
So, anyone out there with a Core i5 or non-2011-v3 Core i7 who paid out for the faster RAM timings willing to try these tests out?

Thanks. Yes, I hope some people with other rigs will do these tests as well. The best would be to have someone running a cheap i5 processor with no hyperthreading and a small L3 cache.
 
Another thing that occurs to me is that I concentrated on some multi-threaded tests in order to see the benefits of this 8-core behemoth of a processor. That's great, but having all those threads allows hyperthreading to cover over or hide the RAM latency penalties that a single-threaded program would feel the full effect of. 
 
I should look specifically for non-threaded tests and run them at the two memory speeds to see what kind of a difference there is once hyperthreading can't hide the latency.

notfordman
Great information!! This will save me a few bucks in the long run, I was lusting after the 14 timed modules for a while. Thank you for your time for these tests and info sharing. Good to see a BR awarded.

Yeah, pending someone running the tests with a different cpu with much smaller cache, or no hyperthreading, I'd definitely recommend saving the money, or putting it into upgrading some other part of the system.
 
For the fish (halibut) I went back and ran the POV-Ray 3.7 benchmark test again (this time at its default size though, not the much longer 1920x1080 size) in single-threaded mode, in order to rule out hyperthreading and its ability to hide memory latency. At least with the small image size (I think it defaults to 512x512 or so) the 20mb L3 cache of this Broadwell-E processor does such a good job at hiding memory latency that even in single-threaded mode five runs at the tighter timings yielded only an average 0.11% performance improvement over five runs at the slower RAM timings.
 
There are other tests I could run, and I may yet run some tests again if I get some video editing software installed and do some long renders, but at this point I'm hunting for a problem to self-justify having paid for the solution. 

SethH
I've read in a few places that if you bump the voltage on the G.Skill RAM to 1.4v, you can get timings as tight as 13-13-13-30...I don't have the RAM personally to test but if you're looking for other methods that might be one to try out. You can always clear the CMOS if it fails to post.
 
This is the: F4-3200C14Q-32GTZ right?

I'm not sure what it means, but the part number of the RAM I bought has a couple of extra letters at the end (F4-3200C14Q-32GTZSW). I think the SW probably stands for "silver/white" or something.
 
I haven't been able to demonstrate any truly meaningful performance gain going from 16-18-18-38-2T to 14-14-14-34-1T, so I very much doubt my results are suddenly going to get a lot better at 13-13-13-30. It's all about Amdahl's Law now. The percentage of processing time that consists of waiting on RAM accesses is apparently small enough under the workloads I've tried that any arbitrary amount of improvement in access time is going to deliver a modest overall speedup at best.

I'm sure we could hand code some cpu workload specifically designed to defeat the benefits of a large memory cache, and also defeat the benefits of hyperthreading. But if you're having to delve into speculations about such corner cases just to find a possible scenario where the increased cost of the tighter timings would providing meaningful benefits, you've pretty much already conceded the fight - unless you use your computer for such corner-case workloads in the real world, the benefits simply aren't there.