disabling cache - problems or cruel joke?

[pbyrpch168]

Hello

we've tried running a full set (all available 14 tests) with cache disabled.

Either this is bugged, or this is a cruel joke.

The small one with 8GB was canceled after it was apparent it would take a week or two at MINIMUM.

The large one with 32GB does not move at all. Not even in test 0. 0% after 15 minutes.

What's the point of this feature if one can never use it? You can't expect people to pay electricity full tilt for a year to test some RAM you need to use in at most a day or two.

Thanks for all info.

[David (PassMark)]

RAM access without a cache can be very very slow. This is just a hardware limitation.

I don't have exact figures for each hardware platform, but I would not be surprised if it was 10x slower. What hardware are you using?

We suggest leaving the cache on, as this is the way the CPU is always configured in real use.
(the exception to this might be if you suspect the CPU's cache is bad, but this is very rare)

[pbyrpch168]

Thank you for your reply.

The smaller one is a generic oem i3 with 1600, the i7 is a brand new 13th gen i7 with 3200.

10x is far too little. The small one was done in less than 3 hours, all tests with cache on, 4 passes. Without, this wasn't even past test 4 after a day and the later moving inversions are exponentially slower, so no point unless you want to burn a week or two.
The bigger one is also already finished with cache on, while it wouldn't even get to 1% on test 0. It seemed much much slower, way slower than the 4x you'd expect from the higher amount. (ignoring twice the speed)

I believed cache disabling would yield the most accurate result and wanted to get the "master report" passing these sticks.

I'd still like to know what you built this for. What's the use case? Someone who has exactly 1 RAM stick with 512M maybe so it doesn't take a lifetime?

[pbyrpch168]

>(the exception to this might be if you suspect the CPU's cache is bad, but this is very rare)

So how would one do this?
Even test 0 does not reach 1% within a reasonable timeframe on the 13th gen i7 32 3200. You can't expect users to let it run for months.
After trying again on the small one, even that would probably take more than a month due to the later tests being much slower. There is no progress for hours.

Is "cache disabling" just empty marketing so you can add another "premium" line, then?
Zero use-cases have been presented that can be achieved within a realistic timeframe.
32G aren't even a lot for the kind of users that would purchase the pro version.

I can't stress enough how much slower than 10x this is. From 45mins for all 14 tests to not even 1% on test 0 after an hour.

N.B.: It is not frozen - the time updates, albeit extremely sporadically.

[David (PassMark)]

We did a bit of testing today on Intel 13th Gen. We agree it is slower than expected (and slower than it was in the past, on older hardware, when the feature was initially added).

It might be that modern hardware really is super insanely slow without a cache, or it might be a coding issue, where the behaviour has changed with newer CPUs. For example, we think we are just disabling the data cache, but in fact doing something else (like disabling the instruction cache as well).

This is all very low level code. So not trivial.

We'll have a deeper look.

[David (PassMark)]

So it seems we are disabling all caching at the moment (instruction and data), as there was no option to do otherwise on older CPUs.
We are suspecting it might also be double bad when an integrated GPU is in use (i.e. shared memory, instead of having dedicated video memory) as even the screen updates are extremely slow.

We experimented with turning off caching for just the memory pages that contained the test data being written and read from RAM, but UEFI BIOS didn't like that when done in conjunction with multi-threading on some machines. Might be possible to make this work single threaded.

So it doesn't look like there is a easy solution. Meaning for the moment either don't use the feature, or be prepared for a very long wait.
(Note: it may be better on older hardware, we haven't fully tested when exactly it became so slow)

We have added it to our To Do list to come up with a better solution, if technically possible.

[pbyrpch168]

Thank you David. The technical details seem to be very esoteric - but at least now I know there's no point striving for the "perfect pass" using this feature. I was hell bent on letting it run at least once.

[pbyrpch168]

The small one that might have possibly finished in a few weeks was a haswell by the way (4th gen). Maybe that's helpful.