20ns is kinda slow, but might work in a 33MHz system. With slower cache one has to set a higher-latency access in the BIOS (usually 3 instead of 2 cycles) and that affects the performance way more than going from 128k to 256k (on a 386 anyway).
Plus it's worth mentioning that, depending on how the chipset manages the cache, 256k might require slower timings anyway, or way faster chips. For example my own 386DX40 system will not run stable with 15ns SRAMs, I'd need to find 12ns or maybe even 10ns for the tag - but those are very rare chips at 5V.

TL;DR:
- cache latency 2 is considerably better than 3
- 256k is better than 128k but only if it doesn't require going to latency 3 for stability
- at 40MHz the 20ns SRAM chips usually won't work at latency 2 even at 128k

As for chipsets with built-in cache, I've never seen one of those (though I'm not saying they don't exist). But I've read about one that had the tag implemented internally, still required the extra main cache SRAMs to work though. Obviously the tag has a size limit and cannot be changed now so that also limits the amount of total cache but the upside is lower latency which doesn't depend on the mobo quality. Still, a good mobo with 12/15ns chips can probably match it.

Baoran wrote on 2020-02-01, 09:40:

Since there is such big difference, it brings up another question. If you look at system requirements for old games and they mention 386, do they mean 386 with or without motherboard cache?

That's an interesting question, indeed! 😀 I guess they do assume some small amount of cache to be present, at least,
considering that my old PC repair books from 1990 onwards do mention correct cache configuration in some extra chapters thoroughly.

Baoran wrote on 2020-02-01, 09:40:

Since there is such big difference, it brings up another question. If you look at system requirements for old games and they mention 386, do they mean 386 with or without motherboard cache?

No one really cared about CPU performance back then.

386 meant that you were supposed to have a 386 class CPU. Not any specific speed. just a 386. SX, DX. With cache or not. 16 MHz SX or 40 MHz DX. Often even this was a soft requirement to stop a bulk 8086 and 80286 users complaining about speed as 386 PCs were usually faster.

Usually there were only two factors defining compatibility of a game in early 90's (and those were usually hard requirements):

1. Size (and type) of RAM (like 640K or 1MB EMS)
2. Type of (not speed) graphic adapter. E.g. (VGA, EGA, CGA)

A little later it was common to have a hard requirement about 386 CPU. This meant support for 32bit instructions due to using memory extender. That was a hard requirement too.

Nothing more than that. It was not until much later when the speed started to matter. There were exceptions though.

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

No one really cared about CPU performance back then. […]
Show full quote

No one really cared about CPU performance back then.

386 meant that you were supposed to have a 386 class CPU. Not any specific speed. just a 386. SX, DX. With cache or not. 16 MHz SX or 40 MHz DX. Often even this was a soft requirement to stop a bulk 8086 and 80286 users complaining about speed as 386 PCs were usually faster.

Usually there were only two factors defining compatibility of a game in early 90's (and those were usually hard requirements):

1. Size (and type) of RAM (like 640K or 1MB EMS)
2. Type of (not speed) graphic adapter. E.g. (VGA, EGA, CGA)

A little later it was common to have a hard requirement about 386 CPU. This meant support for 32bit instructions due to using memory extender. That was a hard requirement too.

Nothing more than that. It was not until much later when the speed started to matter. There were exceptions though.

After looking up system requirements online, I guess I can understand that.
Like for example original wing commander only required 640Kb of ram and 8088/8086. I wonder if you could really play through the whole game on a system like that...

I am sure some did.

People were much less sensitive to framerates of moving graphics than they are now.

In early games it was all about just getting the colour graphics somehow rendered on screen. If it was moving at 5-10fps it was a plus.

Baoran wrote on 2020-02-03, 15:21:

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

No one really cared about CPU performance back then. […]
Show full quote

No one really cared about CPU performance back then.

386 meant that you were supposed to have a 386 class CPU. Not any specific speed. just a 386. SX, DX. With cache or not. 16 MHz SX or 40 MHz DX. Often even this was a soft requirement to stop a bulk 8086 and 80286 users complaining about speed as 386 PCs were usually faster.

Usually there were only two factors defining compatibility of a game in early 90's (and those were usually hard requirements):

1. Size (and type) of RAM (like 640K or 1MB EMS)
2. Type of (not speed) graphic adapter. E.g. (VGA, EGA, CGA)

A little later it was common to have a hard requirement about 386 CPU. This meant support for 32bit instructions due to using memory extender. That was a hard requirement too.

Nothing more than that. It was not until much later when the speed started to matter. There were exceptions though.

After looking up system requirements online, I guess I can understand that.
Like for example original wing commander only required 640Kb of ram and 8088/8086. I wonder if you could really play through the whole game on a system like that...

That's interesting. I assumed it supports VCPI and requires a 286, thus.
Anyway, the box's sticker says "RECOM'D: 12Mhz or higher [..]" and ICBM/PC & 100% COMPATIBLS.
Which likely is a hint to a 286. Turbo XTs rather were 7.xx, 8 or 16MHz.

Edit: Text edited and a few typos fixed.

If it used the VCPI then it would surely need a 386?

I think it makes use of EMS (which could be available natively on 8086) but doesn't require it.

I have a 386DX-33 machine with 64k cache, is it worth it to upgrade to 128k?

https://www.mobygames.com/game/dos/wing-commander/techinfo
This is where I looked up that 8088/8086
I also have the original box with requirements sticker and it says:
IBM PC (5.25")
640k Minimum
Keyboard, mouse or joystick
EGA, VGA/MCGA
Supports sound cards including Roland & adlib.
Hard Disk & Faster Machine Recommended

So that sticker is even more confusing to me than the web page 😜
The game comes with 11 360k floppies

EvieSigma wrote on 2020-02-03, 16:53:

I have a 386DX-33 machine with 64k cache, is it worth it to upgrade to 128k?

If you can increase the cache size without increasing the cache memory waits, your system will be a tiny bit faster.

If you have to increase the cache memory waits to keep the system stable after increasing the cache size, you will likely have made your system a little slower.

But for the "Worth It" part, this is retro computing. Your return on investment isn't likely tied that closely to performance.

hardly depends on the Chipset.. Cache Mainboards are some times slower then uncached ones too..

i got 24mb/s memory speed on OPTI Chipset with DX25 without any Cache.
But my DX40 with Cache does only reach around 20Mb/s..

matze79 wrote on 2020-02-03, 19:16:

hardly depends on the Chipset.. Cache Mainboards are some times slower then uncached ones too..

i got 24mb/s memory speed on OPTI Chipset with DX25 without any Cache.
But my DX40 with Cache does only reach around 20Mb/s..

This is a common trap of benchmarking. The cached system could still be faster.

The way caching improves CPU performance is that it hides latencies of RAM. So rather than waiting 60 cycles to fetch the data from RAM it is better to retrieve it in just 20 cycles from the cache and spent the other 40 cycles that would be wasted on executing the code. With additional bonus that the next block of required data will be already there due to the burst cycle . Even if it means that sometimes in relatively less common case of a cache miss it would have been faster to go straight to the RAM.

So it is important to measure performance in a real world test rather than measuring sustained transfer speed of RAM using a micro benchmark.

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

This is a common trap of benchmarking. The cached system could still be faster.

Exactly, I was about to write the same but you explained it in a much better way than I could possibly do. It's not only about transfer rate numbers, it took me a while to understand what's really going on during my benchmarking era.

I did build my 386 system yesterday Early 90s 386 build as close to period correct as possible.
It has 128Kb of 20ns cache. The motherboard also has room for another 4 cache chips. I can run the system well with 0WS in bios. Would that likely change if I bought more same 20ns cache chips and added them there? Would I need to do anything about the tag chip? Would 256Kb cache matter when no more than 8Mb of ram?
Is there even any info online on what jumpers I would need to change if I added more cache?

Fast cache read hit, fast cache write hit and Fast page more dram were disabled by default in bios and I changed them to enabled even though I am not sure what they do exactly.

Baoran wrote on 2020-02-04, 02:28:

I can run the system well with 0WS in bios. Would that likely change if I bought more same 20ns cache chips and added them there?

This specific version of the BIOS is very limited in options, I see no options to set the cache read/write WS, just for the RAM.

Some 386 chipsets do not support 256kb cache even if they have sockets to accept it.
I think the Octek Jaguar IV is a good example of this. It has two banks of cache sockets and can accept 32kx8 SRAMs, but 128kb (in a single bank of four 32kx8 chips) is the max supported by the Headland chipset that the board uses.

It's best to check the chipset manual (if you can find it) and/or your motherboard manual before wasting your time. Generally speaking, if your 386 board uses a 486 chipset there is a good chance it can take 256kb as long as it has enough sockets.

Anonymous Coward wrote on 2020-02-04, 08:32:

Some 386 chipsets do not support 256kb cache even if they have sockets to accept it.
I think the Octek Jaguar IV is a good example of this. It has two banks of cache sockets and can accept 32kx8 SRAMs, but 128kb (in a single bank of four 32kx8 chips) is the max supported by the Headland chipset that the board uses.

It's best to check the chipset manual (if you can find it) and/or your motherboard manual before wasting your time. Generally speaking, if your 386 board uses a 486 chipset there is a good chance it can take 256kb as long as it has enough sockets.

I assume it uses 486 chipset because some version of the motherboard have bigger socket that accepts 486 cpu where the 387 socket is on mine FX-3000 motherboard thread
Those versions also have more options in the bios. I have not been able to find manual for it online though, so I don't know what jumpers I would have to change if I installed more cache

Baoran wrote on 2020-02-04, 09:07:

I have not been able to find manual for it online though, so I don't know what jumpers I would have to change if I installed more cache

I believe it's easy, the link to Phil's thread you just posted has the motherboard full of cache and you can see the configuration of W2-W9 jumpers. That should be enough 😉

Baoran wrote on 2020-02-04, 09:07:

I assume it uses 486 chipset because some version of the motherboard have bigger socket that accepts 486 cpu where the 387 socket is on mine

Cool. I actually can't see the pictures because I'm behind the Great Firewall of China.

I have a DX40 motherboard with cache, I should probably put it to use and benchmark it against my U5SX-33..