The cachechk cannot detect cache mode (WT/WB)

What makes you think your system is underperforming?

On my MB-8433/40UUC which has working write-back L1 and L2, if you run cachechk -w the write speed is reported as the speed of the L1 cache.
On this board, if you run cachechk -w the write speed is the speed of RAM.
In addition, it's visible in Speedsys, where the "write" graph is a straight line almost as fast as L1 on the MB-8433/40UUC, and is a straight line as slow as reading from RAM on the M912.
If someone else has M912+5x86-160 it would be easy to compare numbers.

mpe wrote on 2020-09-17, 23:08:

The cachechk cannot detect cache mode (WT/WB)

What makes you think your system is underperforming?

You may be right that I was drawing too many conclusions the first time around.
However, I just re-checked. Cachechk -w reports 16 us/KB across the board on my MB-8433/40UUC while it reports 26 us/KB across the board for the M912. This is despite the fact the former is at 33 MHz and the latter at 40 MHz.
So, what gives with the slow write speeds? Maybe the L2 is stuck in write-through?

Again. You cannot detect cache write policy in cachechk. The only way to detect cache in wb mode is to measure latency after experiencing a write cache hit.
Cachechk write test measures duration of data transfers increasing in size. Those are guaranteed to be cache misses. Every write results in a write-back cycle. So this test is basically measuring write speed to RAM irrespectively of the cache mode actually used. That's why you see 16 or so across the board.

Cache in write-through mode, depending on implementation, isn't slower in a test like this. In fact quite the opposite. Write-back typically performs better in real-world tests where you have a significant proportion on cache hits.

Not sure how a tuned M912 compare against other motherboards. My 5x8 160/40 MHz on MSI4144 (a SiS 496 board) produces 7/15/21 reads and 13 write in cachechk. and 7/13/24-11 @ 150/50 MHz (which is typically faster than 160/40).

Thanks for the follow up.
I was inspired by this thread Identify 486 L1 WT or WB Cache? and the discussion of the shape of the speedsys to re-jumper the CPU as WT instead of WB and I did see performance change to be worse overall. WT vs. WB seemed to affect moves vs. writes, one would get better while the other got worse. So I was wrong about L1 being WT. It is properly working as WB.

However, I still believe the L2 is stuck as WT. I notice the BIOS setup has no option to control the L2 cache policy. I've looked at a bunch of 498 BIOSes and see that none of them have one either -- except one, which is an ECS UM4980 Phoenix BIOS. I wonder if there are multiple revisions of the UMC 498 chipset.

I'd like to hear from anyone else experimenting with L2 in WT vs. WB on a 498 board. Surely there are lots of us on here?

You can use a tool like ctcm.exe to find out the write cache mode.

Measuring of the benefit of more advanced cache coherency mode by simple cache/RAM benchmark is tricky though. Due to reasons mentioned above most RAM tests will show the same or slightly worse results at writes when the WB L1 or L2 mode is enabled. Especially on a relatively slow 486 CPU. So popular tools like cachechk or speedsys are not the best for that.

The purpose of WB cache is to reduce latency when having a hit not to improve write speed. Whether the extra overhead of WB is worth it depends on how effectively the CPU use the extra cycles saved by not having to wait during write cache hit. You best bet is to try something like Quake fps or another real-word application-oriented test.