mpe wrote on 2020-02-03, 22:19:

OK Mission accomplished. I soldered in the extra header, installed 1 MBit TAG chips and it is now working! Looks like the jumper […]
Show full quote

OK Mission accomplished. I soldered in the extra header, installed 1 MBit TAG chips and it is now working! Looks like the jumper needs to be permanently in place,

DSC_5295.jpg

ctcm is confused with anything >512k. However, cachechk and speedsys confirm the cache. The speedsys graph is a little unusual:

2048.jpg
IMG_4964.jpg

The only DOS app showing some improvement over 1024k is Quake (20.1fps vs 19.8fps). The rest seems to comfortably fit in the 1M cache already. (DOOM +1 realtick, pcpbench + 0.1fps, ...) I think I will need to better benchmarks that use larger data set, likely in Windows.

Will spent a little bit more time on this board. Currently have "faster" cache setting and 2T write cycles. This is the same as 256k/512k/1024k, but I still believe that with genuine <15ns SRAM chips I should be able to run this at full speed and beat even a 75 MHz mb...

Awesome upgrade, old hardware maxed out 😀
I am a bit surprised, that you used the cheap 10ns chips instead of the probably correct labelled 15ns chips.

In the scenario that you have this much cache one would wonder the effect if you could map half of it as base ram

CoffeeOne wrote on 2020-02-04, 23:24:

I am a bit surprised, that you used the cheap 10ns chips instead of the probably correct labelled 15ns chips.

I didn't know they were fakes. Then how could I know 15ns aren't just re-labelled 20ns parts 😀 ?

You can't really tell these days...

rmay635703 wrote on 2020-02-04, 23:59:

In the scenario that you have this much cache one would wonder the effect if you could map half of it as base ram

Oh yeah - or 640k .. That would be cool!

That's awesome - I have the same board.
The upgrade to 2MiB cache will be an interesting project.
I use 16KiB 12ns tags for my board and 32KiB srams for the banks resulting in 0.5MiB - all BIOS settings max'd out.

mpe wrote on 2020-02-03, 22:19:

The only DOS app showing some improvement over 1024k is Quake (20.1fps vs 19.8fps). The rest seems to comfortably fit in the 1M cache already. (DOOM +1 realtick, pcpbench + 0.1fps, ...) I think I will need to better benchmarks that use larger data set, likely in Windows.

Are you still planning on running some Windows benchmarks? I'm quite curious to see some Windows game and synthetic benchmarks, especially if you can run the full offerings of cache from 256k up to 2 M. If you have a P133 socket 4 overdrive, that would make it even more interesting.

Yes. I plan to publish full tests incl. Winstone 95. The only problem I have is that single-bank configurations can't sustain 3-2-2-2 timings in Windows at 66 MHz. So I need to recapture tests with more conservative timings, at 60/120 MHz or only consider dual-bank configs.

Also I don't know about any synthetic tests that can capture cache size increase. Synthetic benchmarks tests tend to have very small code size/data set and easily fit into L1 cache let alone L2.

I found Quake 320x200 DOS to be almost perfect CPU/L2/MEM benchmark in DOS and Winstone 95 works well in Windows. Both see modest improvements when going from 1024k or 2048k L2.

Yes. I do have PODP5v133.

Ahhh, super, you have the PODP5V133! Looking forward to this.

Do not all the boards being tested have double-banked cache? If not, I'd run them each with double-banked cache using the fastest stable timings.

Yes. Will need to redo the tests with PODP5V133 and use smaller chips in dual-bank mode to have consistent timing.

Most Socket4/5 motherboards have a single bank L2 cache.

The SiS501 is rather an exception. Also UMC8891 could have dual-banked cache, but that's not a very common chipset. This allows using slower SRAM chips.

Technically, when you use 512k pipelined-burst COAST module on Triton, it is also a dual-bank configuration. However, unlike async cache, the dual-bank PB is actually a bit slower as the back-back burst cycle becomes 3-1-1-1-2-1-1-1 instead of 3-1-1-1-1-1-1-1 because an extra wait-state need to inserted for bank turnaround. However, increased cache efficiency when using 512k should easily win any such penalty back.

Adding graphs with performance results. Not easy to capture as some cache configuration (single-banked ones) are non-stable at specific settings with the cache chips I have. However, I managed to capture results after some trying & chip swapping.

These were all captured with PODP5V133 overdrive CPU.

DOOM / Winstone 95 results show the expected "reverse hockey stick". Most benefit is realised by having any sort of cache. Then you get diminishing improvements as you increase the size.

Quake shows a slightly different picture. The performance scales with cache size quite nicely and even at 2048k doesn't seem to be slowing that much:

I also measured more aggresive timings with 60 MHz bus. Like 3-1-1-1 or 4-1-1-1. But those were generally not stable except for few tests. Anyway, it looks like cache timing is more important than size. It is even more important than the clock as in my tests well tuned P120 MHz can beat average P133. I still need to find perfect SRAM chips for this board.

These charts are epic. I've never seen a 256K-2M cache test like this before. I saved the charts in case I can't find the thread later on. Any chance you can also do 128K, mostly for Quake. I'm surprised at how linear the response was with Quake, whereas DOOM seems more asymptotic.

Yeah, timings are most important. An issue I've come across is that using more cache, esp. the max a chipset can handle, sometimes requires slower timings for stability. So there is a sweet spot somewhere.

Thanks. My board doesn't have a setting for 128k. The chipset supports it (even a non-interleaved 64k). I suppose I should be able to find out settings. However, I don't have enough (16) fast 8kx8 SRAM chips. Just setting by jumpers don't work. The board seems to be doing some active size detection as I found.

I suppose I should be able to fool it by using 32kx8 and isolating high address pins with an electrical tape 😀 Will see..

feipoa wrote on 2020-04-16, 10:51:

These charts are epic. I've never seen a 256K-2M cache test like this before. I saved the charts in case I can't find the thread later on. Any chance you can also do 128K, mostly for Quake. I'm surprised at how linear the response was with Quake, whereas DOOM seems more asymptotic.

Yeah, timings are most important. An issue I've come across is that using more cache, esp. the max a chipset can handle, sometimes requires slower timings for stability. So there is a sweet spot somewhere.

Speaking of epic charts .. Did you ever consider doing similar in the 486 comparison? 🤣

lol, no! That would make for WAY too many variables. I have thought about doing a 64k, 128k, 256k, 512k, 1024k comparison though. I remember reading that 64k to 128k and 128k to 256k are supposed to yield a large performance benefit, and I want to see it charted.

I would like to redo all 486 benchmarks though, include more 486 chips, as well as 486 chips on 386 motherboards, and try to split the results more 50:50 with synthetics and games. There's so much to do before work can start on that though.

I have a torso of results from my MSI-4144 with Am5x86 @160, but still not enough to draw graphs. The board can do 128k-1024k.

I expect the effect of cache size will be less pronounced on a 486. The cache line size is half-size of Pentium which could improve efficiency of smaller sizes? Similarly I expect the impact of burst timing to be lower for the same reason.

It is not without surprise that in absolute numbers Doom framerates of 150/160 MHz 486 are roughly comparable to Pentium 133. Just shows how bad the DOOM is as a benchmark 😀

Super awesome thread! I am also a proud new owner of an ECS SI5PI AIO rev1.1 😀

I'm still waiting on my CPU to arrive. But, I've already performed the JP12 mod.

I was noticing that this board has an AMIKEY-2. From my experience, this chip supports PS/2. Also, this board looks to have solder pads for PS/2 keyboard and mouse:

All of the componentry looks to be in place:

Has anyone tested PS/2 with this board yet?

-Brian

It's not just AMIKEY-2 that supports the PS/2 mouse. Just about every 8042 I've seen made after 1990 seems to support it.

feipoa wrote on 2020-04-16, 12:34:

🤣, no! That would make for WAY too many variables. I have thought about doing a 64k, 128k, 256k, 512k, 1024k comparison though. I remember reading that 64k to 128k and 128k to 256k are supposed to yield a large performance benefit, and I want to see it charted.

I would like to redo all 486 benchmarks though, include more 486 chips, as well as 486 chips on 386 motherboards, and try to split the results more 50:50 with synthetics and games. There's so much to do before work can start on that though.

Yeah, that seems like a lot of work .. And it seems a LOT of effort has already been put in 😀