...I am not sure which wait states? The programs are going to run in the cores and do the same things irrespective of HT. The same RAM accesses will accumulate due to the same processes arriving at the same ends. Those are time sliced to run concurrently. The HT mode utilises paralleled hardware to lessen the impact of swapping context. The only difference I am aware of is that waiting in one thread gives access to the HT sister LP and consumes wait states. This uses memory more effectively because the other LP is waiting.

In an event based compute platform we see waiting all the time since tasks are driven by events then drop back into idle time. This makes HT very effective In Windows.

On 2/8/2020 at 6:40 PM, SteveW said:

https://en.wikipedia.org/wiki/CAS_latency

More or less appears to say the same thing that frequency matters. You don't need your wheels spinning faster than the road going past. And unless you drive around all the time at 200mph, you can save fuel on a smaller engine.

No, what it says is that... it's not so simple.  Quoting from your link:

Because memory modules have multiple internal banks, and data can be output from one during access latency for another, the output pins can be kept 100% busy regardless of the CAS latency through pipelining; the maximum attainable bandwidth is determined solely by the clock speed.

Perhaps that's where you stopped reading?  Of course, the above is then followed by this:

Unfortunately, this maximum bandwidth can only be attained if the address of the data to be read is known long enough in advance; if the address of the data being accessed is not predictable, pipeline stalls can occur, resulting in a loss of bandwidth. For a completely unknown memory access (AKA Random access), the relevant latency is the time to close any open row, plus the time to open the desired row, followed by the CAS latency to read data from it. Due to spatial locality, however, it is common to access several words in the same row. In this case, the CAS latency alone determines the elapsed time.

So, as has been pointed out by others in this discussion, both memory speed and CAS Latency are critical variables to consider.  CPU throughput is also a critical variable in choosing a memory... the better a CPU performs, the faster the memory (speed and CAS Latency together) it can utilize.

Greg

You miss the point as well though. Because decreased latency is the decrease in strobe time Rob did the math and at the same data rate it becomes marginally more available rather than faster.

What you find is folk paying over the odds for decreased latency but with little real effect as the benchmarks quoted show clearly. That's what I am saying. I am not saying CL is useless and I am not saying you don't need it. And I am saying it's nice to have the expensive stuff if it is more reliable and it is longer lasting at the overclock. Instead it's better to work on how the simulator is set up and the CPU used correctly.

4 hours ago, lownslo said:

 

Perhaps that's where you stopped reading? 

 

No need for including rudeness. Looking for ways to make someone elses post appear to show disparity when it does not is quite usual amongst some AVSIM posters.

On 2/8/2020 at 10:35 AM, Rockliffe said:

Has anyone got any advice or opinions on Patriot Viper Steel 2x 16GB DDR4-3200 RAM? I'm upgrading my setup slowly and as I also fly DCS, upgrading the RAM will be the next step, followed by a new CPU. Thanks fellas.

So what was the outcome of the original question?

Such a direct question demands that someone perhaps owns it already. Otherwise the advice I read early in the discussion covered it to some degree.

I might add that if pairs are required I always get four rather than two since this also means that if one fails there's a good pair to use right away. Getting more may be worth it to one system, less so to another.

I understand very little of this, but I have had Hyper Threading turned off for several years due to advice from long ago. In this thread Rob and Steve seem to disagree on it's usefulness. So what is it? HT on, or HT off???

My PC specs:

    Cooler Master MasterCase 5 Pro chassis   
    ASUS ROG Strix Z270E Gaming system board
    Intel Core i7-7700K Processor 4.2GHz(unclocked)
    ASUS GeForce GTX 1080 Ti STRIX ROG Overclocked 11GB GDDR5X
    1000W Gold power supply with CableMod's ModFlex sleeving
    32GB G.Skill DDR4-3200 RAM
    Intel 600P Series 256GB M.2 SSD's in RAID 0 (512GB)
    2TB WD storage drive    
    16x Blu-ray DVD Burner Drive
    10/100/1000 Network
    802.11ac Wireless
    Bluetooth 4.1
    Microsoft Windows 10 Pro 64-bit 

Bruce

I just saw Steve's last post(we posted simultaneously). I guess I 'll try his suggested test. Actually my FSXSE is running extremely well and loading times are quite short with HT off.

 

Edited February 12, 20206 yr by brucets
Steve's simultaneous post

If any of you guys want to check the performance of HT vs non HT.

Set up a saved flight at an airport, reboot with HT off and load up right into the sim a few times, three times at least. Measure the time the sim takes to load up with 2, 3, 4 and so on cores.

Now repeat the test with HT enabled and see if the loading time decreases. If it does you know HT is worthwhile.

Edited February 12, 20206 yr by SteveW

...you have to run it a few times because of windows caching. Also after the reboot settles.

If you do go with HT ON then disable one of the core zero LPs which allocates the entire core to the main task and disable a few the other end. Like Gerard he ignores the worst cores. He says he can keep on using cores and load faster and faster. That might even be better with extreme scenery settings. But that overall is not such a good experience as leaving a few cores absent from the AM.

Edited February 12, 20206 yr by SteveW

HT can be a problem for some software alongside the sim if it doubles it's task count. If in doubt HT disable.

Another thing that can be done to help the main task is corral addon exe apps away from the first core. In P3D use the first core in any AM. With HT enabled use only one LP of core zero.

If you set the overclock high then the extra work done in less time with HT enabled may bring the temperature up too high. That's a mis-configuration from inexperienced.

Looking at fps is not the only picture since the fill in rate is a better concern than fps. Better linkage to the backend and improved fill-in rate will affect the fps slightly, even though the sim is better overall.

A full on Overclock will act differently to a Turbo Boost setup. Generally when demand is high the Turbo Boost setting will be as fast as it can go.

File and network I/O is very heavily multi-threaded in Windows so more cores and more LPs is what makes those things get a move on.

Rendering a movie to another format will take less time. But allowing the parallel back end of the sim all it want's can push out the resources it is waiting on.

Each PC and sim is set different and each user expectatiuon is different so it must be looked into on a per PC basis.

 

 11 hours ago, SteveW said:

You miss the point as well though. Because decreased latency is the decrease in strobe time Rob did the math and at the same data rate it becomes marginally more available rather than faster.

Actually, I understand just fine.  It's all explained quite well in your own reference link.  Specifically, the second paragraph I quoted on the previous page of this discussion.  I do find it curious, though, how your position and explanations are evolving in the above quote.  In your first post to this discussion you wrote:

On 2/8/2020 at 2:19 PM, SteveW said:

So long as latency is not too long the memory will work as fast as the locations can be cycled to. In effect even less latency doesn't factor since it won't be cycled to any earlier anyway. Speed is more important.

Emphasis mine.  Your own reference makes clear that the maximum attainable bandwidth is determined solely by speed only when the memory can be kept 100% busy (effective and efficient bandwidth saturation).  But other critical factors can hinder that 100% saturation and then CAS Latency can become the primary determinant of throughput.  In your rather convoluted quote I added at the top of this post you note that "decreased latency at the same data rate 'it' (assuming 'it' refers to data) becomes marginally more available rather than faster".  You were almost there except for the use of the word "marginally".  Again, it depends.  Your claim that decreased latency will only "marginally" increase the amount of data written assumes that the throughput is at or very near 100% saturation.  Oh, if only the world was that perfect!

Both speed and CAS latency are important... because both will impact throughput at different times and under different use conditions.

Greg