TAG(s) should be the fastest chips on the mobo. 15ns or even 12ns if you want stable 40MHz operation at 0WS (*), especially with banked cache (usually 256k though).

(*) What is 0WS is mobo-dependent. It can even be different timings if cache is enabled or disabled.

Thanks for the reply. I would love to get the system stable at 0ws. The bios options are 0,1,2 for dram wait states and 1 has been rock solid, but would love to get it down to 0.

I had forgotten, but i had made a post about the same board when i was upgrading the cache from 64k to 128k here..

Need help with cache upgrade 386

I still have the 64k chips, i could try to put that back in and see if 0ws is stable with that. Also looks like the last post in that old thread said M5M5188BP was a compatible chip, but i don't see any on ebay currently in -15ns

Swapped the cache out for the 64k config that was originally in the board and it has the same lockup @ 0WS on boot

Do note that none of these chips are new and some might have worked hard for a long time by now. DRAMs are known to degrade - usually the older, DIP packaged ones but then we are only slowly approaching the required lifetime (and usage) for newer stuff to notice any changes. In other words, just because it says 60ns on the sticks doesn't mean they can still handle that speed reliably.

As for the TAGs, does your mobo has a separate setting for cache timings? Some do. It's usually not a good idea to trade 1WS on cache to get 1WS on RAM but if such setting is possible do try it. That would at least confirm if the cache is the culprit, or is it just masking some other issue with the RAMs . Disable slow refresh if you have it set as well.

lowlytech wrote on 2024-05-04, 21:30:

I still have the 64k chips, i could try to put that back in and see if 0ws is stable with that. Also looks like the last post in that old thread said M5M5188BP was a compatible chip, but i don't see any on ebay currently in -15ns

Any 16K x 4 fast CMOS SRAM chip in DIP22 should be compatible. This also applies to the HM6288 (the number printed on the main board). There also are DIP24 chips, but they obviously won't fit. For example, the CY7C164 fits, but the CY7C166 (which I found on ebay) doesn't. Using multiple x4 chips for the tag RAM was very common on 386 boards. Whether you need 2, 3 or 4 of them might depend on cache size, desired cacheable area and the requirement for a dirty tag bit. Obviously, your board has room for 4 chips, but only two of them populated. I'm afraid that this might mean the chipset supports write-back support (possibly it does not support write-through). If the board operates in write-back mode with two chips only, this would mean an "always dirty" configuration which is the worst cache configuration in most real-life use cases, having lower performance than write-through. I'm perfectly able to design a micro-benchmark in which "write-back always dirty" beats write-through, but there are very few applications that have a similar memory access pattern than the hypthetical micro-benchmark I think about. So: If your board supports write-back and write-through, with only two tag chips, write-back is very likely in the dreaded "always dirty" mode, and you are better off choosing write-through.

Here are a few screenshots of the BIOS and advanced BIOS options.

Also a picture of speedsys with 1 WS and cache enabled (128k) vs 0 WS and cache disabled yielded a little over double the bandwidth on the memory test.

lowlytech wrote on 2024-05-05, 18:38:

Here are a few screenshots of the BIOS and advanced BIOS options. […]
Show full quote

Here are a few screenshots of the BIOS and advanced BIOS options.

Also a picture of speedsys with 1 WS and cache enabled (128k) vs 0 WS and cache disabled yielded a little over double the bandwidth on the memory test.

20240505_131916.jpg
20240505_131942.jpg
20240505_132320.jpg
20240505_132611.jpg

This memory bandwidth showing of speedsys is BS. Better compare the cache and memory values, that are given in the next phase.

CoffeeOne wrote on 2024-05-05, 20:04:

lowlytech wrote on 2024-05-05, 18:38:

Here are a few screenshots of the BIOS and advanced BIOS options. […]
Show full quote

Here are a few screenshots of the BIOS and advanced BIOS options.

Also a picture of speedsys with 1 WS and cache enabled (128k) vs 0 WS and cache disabled yielded a little over double the bandwidth on the memory test.

20240505_131916.jpg
20240505_131942.jpg
20240505_132320.jpg
20240505_132611.jpg

This memory bandwidth showing of speedsys is BS. Better compare the cache and memory values, that are given in the next phase.

Thanks for the info, didn't know that was an inaccurate test. So your talking about at the end where you press M or whatever it was to see a memory summary?

lowlytech wrote on 2024-05-05, 20:07:

CoffeeOne wrote on 2024-05-05, 20:04:

lowlytech wrote on 2024-05-05, 18:38:

Here are a few screenshots of the BIOS and advanced BIOS options. […]
Show full quote

Here are a few screenshots of the BIOS and advanced BIOS options.

Also a picture of speedsys with 1 WS and cache enabled (128k) vs 0 WS and cache disabled yielded a little over double the bandwidth on the memory test.

20240505_131916.jpg
20240505_131942.jpg
20240505_132320.jpg
20240505_132611.jpg

This memory bandwidth showing of speedsys is BS. Better compare the cache and memory values, that are given in the next phase.

Thanks for the info, didn't know that was an inaccurate test. So your talking about at the end where you press M or whatever it was to see a memory summary?

Yes. After running the CPU memory benchmark, there is also the summary with M.

With cache enabled and 1 ws

Cache off and 0 ws

Frankly I find the bandwidth values produced by Speedsys to be of little value. Just the fact that memory moves are way faster than reads and writes tells me it's not tested properly - at the very least not for 386. That's yet another issue after the CPU score being lower on 386+387 vs pure 386.

CACHECHK values are much more reliable. I run it with -x5 -z which takes longer but since I do all my tests test this way I have everything at the same reference point. Note this only tests read speed, for write you need -w but AFAIR that replaces some of the read tests with write tests so it's better to do a separate run for write speed if it's of interest. Here's what it looks like on a 386DX-40 mobo with 128k cache that I use for various experiments:

CACHECHK V7 11/23/98 Copyright (c) 1995-98 by Ray Van Tassle. (-h for help)
CMOS reports: conv_mem= 640K, ext_mem= 7,168K, Total RAM= 7,808K
386 Clocked at 39.1 MHz
Reading from memory.
MegaByte#: --------- Memory Access Block sizes (KB)-----
1 2 4 8 16 32 64 128 256 512 1024 2048 4096 <-- KB
0: 39 39 39 39 39 39 39 39 61 61 -- -- -- us/KB
1: 39 39 39 39 39 39 39 39 61 61 61 61 61 us/KB
2 3 4 5 6 7 <--- same as above.

Extra tests----
Wrt 41 41 41 41 41 41 41 41 41 41 41 41 41<-Writing
Reading at different byte offsets, at megabyte #1. Byte offset of...
0= 39 39 39 39 39 39 40 39 62 61 61 61 61 us/KB
1= 78 78 78 79 79 79 79 79 103 103 103 103 103 us/KB
2= 78 78 79 79 79 80 79 79 103 103 103 103 103 us/KB
3= 78 78 78 79 79 79 79 79 103 103 103 103 103 us/KB
4= 39 39 39 39 39 39 39 40 61 61 61 61 61 us/KB
8= 39 39 39 40 39 39 39 40 61 61 61 61 61 us/KB
12= 39 39 39 39 39 39 39 40 61 61 61 61 61 us/KB
This machine seems to have one cache!? [reading]
!! cache is 128KB-- 28.0 MB/s 37.5 ns/byte (156%)
>>>> If you think you do have L2 cache, you might have FAKE CACHE chips! <<<<
5.6 clks
Hmmm. It looks like RAM at megabyte #1 is REALLY slow!
Hmmm. It looks like RAM at megabyte #2 is REALLY slow!
Hmmm. It looks like RAM at megabyte #3 is REALLY slow!
Hmmm. It looks like RAM at megabyte #4 is REALLY slow!
Hmmm. It looks like RAM at megabyte #5 is REALLY slow!
Hmmm. It looks like RAM at megabyte #6 is REALLY slow!
Hmmm. It looks like RAM at megabyte #7 is REALLY slow!
Main memory speed -- 17.9 MB/s 58.6 ns/byte (100%) [reading] 8.7 clks
Effective RAM access time (read ) is 117ns (a RAM bank is 2 bytes wide).
Effective RAM access time (write) is 78ns (a RAM bank is 2 bytes wide).
386 Clocked at 39.1 MHz. Cache ENABLED.
Options: -t0 -z

As for the BIOS, try disabling Fast Cache Read Hit and Fast Cache Write Hit, that will obviously degrade performance but perhaps will fix the stability issue. If so try re-enabling them one by one. BTW clocking ISA at 40/3 is rather hardcore, this shouldn't affect RAM tests but can cause problems with VGA or HDD corruption.

Thanks Deunan for the info and baseline to test against. I ran with 128K cache enabled and 1ws and got this..

CACHECHK V7 11/23/98 Copyright (c) 1995-98 by Ray Van Tassle. (-h for help)
CMOS reports: conv_mem= 640K, ext_mem= 7,424K, Total RAM= 8,064K
386 Clocked at 39.0 MHz
Reading from memory.
MegaByte#: --------- Memory Access Block sizes (KB)-----
1 2 4 8 16 32 64 128 256 512 1024 2048 4096 <-- KB
0: 39 39 39 39 39 39 39 39 90 90 -- -- -- us/KB
2: 39 39 39 39 39 40 40 40 90 90 90 90 90 us/KB
3 4 5 <--- same as above.
6: 39 39 39 39 39 40 40 39 90 90 90 90 -- us/KB
7: 39 39 39 39 39 40 40 40 90 90 90 -- -- us/KB
8: 39 39 39 39 39 40 40 39 90 -- -- -- -- us/KB

Extra tests----
Wrt 47 47 47 47 47 47 47 47 47 47 47 47 47<-Writing
Reading at different byte offsets, at megabyte #2. Byte offset of...
0= 39 39 39 39 39 40 40 40 90 90 90 90 90 us/KB
1= 79 79 79 79 79 79 80 79 128 128 128 128 128 us/KB
2= 79 79 79 79 79 79 79 79 129 128 128 128 128 us/KB
3= 79 79 79 79 80 79 79 80 128 128 128 128 128 us/KB
4= 39 40 39 39 39 40 40 40 90 90 90 90 90 us/KB
8= 39 39 39 39 40 40 40 40 90 90 90 90 90 us/KB
12= 39 39 39 40 39 40 40 40 90 90 90 90 90 us/KB
This machine seems to have one cache!? [reading]
!! cache is 128KB-- 27.9 MB/s 37.6 ns/byte (228%)
>>>> If you think you do have L2 cache, you might have FAKE CACHE chips! <<<<
5.6 clks
Main memory speed -- 12.2 MB/s 85.8 ns/byte (100%) [reading] 12.8 clks
Effective RAM access time (read ) is 171ns (a RAM bank is 2 bytes wide).
Effective RAM access time (write) is 89ns (a RAM bank is 2 bytes wide).
386 Clocked at 39.0 MHz. Cache ENABLED.
Options: -t0 -z

Disabling cache and enabling 0ws resulted in this..

CACHECHK V7 11/23/98 Copyright (c) 1995-98 by Ray Van Tassle. (-h for help)
CMOS reports: conv_mem= 640K, ext_mem= 7,424K, Total RAM= 8,064K
386 Clocked at 39.0 MHz
Reading from memory.
MegaByte#: --------- Memory Access Block sizes (KB)-----
1 2 4 8 16 32 64 128 256 512 1024 2048 4096 <-- KB
0: 54 54 54 54 54 54 54 54 54 54 -- -- -- us/KB
2: 54 54 54 54 54 54 54 54 54 54 54 54 54 us/KB
3 4 5 6 7 8 <--- same as above.

Extra tests----
Wrt 33 33 33 33 33 33 33 33 34 33 33 33 33<-Writing
Reading at different byte offsets, at megabyte #2. Byte offset of...
0= 54 54 54 54 54 54 54 54 54 54 54 54 54 us/KB
1= 113 113 113 113 113 113 113 113 113 113 113 113 113 us/KB
2= 113 113 113 114 113 113 113 113 113 113 113 113 113 us/KB
3= 114 113 113 113 113 113 113 113 113 113 113 113 113 us/KB
4= 54 54 54 54 54 54 54 54 54 54 54 54 54 us/KB
8= 54 54 54 54 54 54 54 54 54 54 54 54 54 us/KB
12= 54 54 54 54 54 54 54 54 54 54 54 54 54 us/KB
This machine does not seem to have any cache.
Main memory speed -- 20.4 MB/s 51.3 ns/byte (100%) [reading] 7.6 clks
Effective RAM access time (read ) is 102ns (a RAM bank is 2 bytes wide).
Effective RAM access time (write) is 63ns (a RAM bank is 2 bytes wide).
386 Clocked at 39.0 MHz. Cache ENABLED.
Options: -t0 -z

I tried disabling the fast read and write hits and it didn't change anything unfortunately. It seems like the /3 on the bus has been running okay, but time may tell for the hard drive corruption. Had to swap out several I/O cards til I found one that worked well enough at that speed. I also have the option to go down to /2 on the bus, but I haven't had any luck getting that stable. On a whim I set the divider up to 5 but that didn't help @ 0ws.

lowlytech wrote on 2024-05-06, 01:14:

I ran with 128K cache enabled and 1ws and got this..

Your mobo 0WS is faster than my mobo 0WS (54 vs 61) but I didn't disable the cache. Try 1WS RAM with cache disabled to see if you get closer to my 61, that would tell you there's an "offset" in the naming. I consider my mobo to be plenty fast for 386DX, anything faster would surely require good batch of RAMs for stable 40MHz operation. Even the ones I already have there were selected to pass memtest.

Anyway, RAM access being slower with cache enabled is a "feature" of many chipsets. OPTi for example adds about 2 cycles to RAM timings, this is so it can check the cache first. If it's a hit you get the data fast but for miss you have the extra cycles of penalty. There are chipsets out there that can do more concurrent access so the miss latency is lower, though how much WS can be shaved also depends on the mobo routing quality, RAM sticks, actual speed of the SRAMs (again just because someone branded them 15ns doesn't mean they actually are, there were fake chips back in '90 too).

BTW I can get 46 / 115 on OPTi mobo with 256k cache, that is rock solid but requires 3-x-x-x / 1WS (for write) cache timings. Trying 2-x-x-x / 0WS results in 40 / 110 but running Doom in a loop will eventually crash it, so it's not fully stable. I don't have 12ns chips to replace TAGs though so it's actually better to reduce cache to 128k on this mobo, tighter timings work OK with single cache bank. This is 386/486 mobo, these usually are slower than pure 386 mobos for memory access. I guess the 486 burst support was more important to implement fast than getting the absolute maximum out of CPU that's about to become obsolete.

If you're looking for 15ns DIP22 cache chips, there's one brand I know of "W22B65AK15". There's some on eBay but brace yourself for the price.

"Slow Refresh" in the BIOS should be enabled if you have it. It extends RAM refresh cycles. +5% performance increase

Deunan wrote on 2024-05-06, 08:51:

Your mobo 0WS is faster than my mobo 0WS (54 vs 61) but I didn't disable the cache. Try 1WS RAM with cache disabled to see if yo […]
Show full quote

lowlytech wrote on 2024-05-06, 01:14:

I ran with 128K cache enabled and 1ws and got this..

Your mobo 0WS is faster than my mobo 0WS (54 vs 61) but I didn't disable the cache. Try 1WS RAM with cache disabled to see if you get closer to my 61, that would tell you there's an "offset" in the naming. I consider my mobo to be plenty fast for 386DX, anything faster would surely require good batch of RAMs for stable 40MHz operation. Even the ones I already have there were selected to pass memtest.

Anyway, RAM access being slower with cache enabled is a "feature" of many chipsets. OPTi for example adds about 2 cycles to RAM timings, this is so it can check the cache first. If it's a hit you get the data fast but for miss you have the extra cycles of penalty. There are chipsets out there that can do more concurrent access so the miss latency is lower, though how much WS can be shaved also depends on the mobo routing quality, RAM sticks, actual speed of the SRAMs (again just because someone branded them 15ns doesn't mean they actually are, there were fake chips back in '90 too).

BTW I can get 46 / 115 on OPTi mobo with 256k cache, that is rock solid but requires 3-x-x-x / 1WS (for write) cache timings. Trying 2-x-x-x / 0WS results in 40 / 110 but running Doom in a loop will eventually crash it, so it's not fully stable. I don't have 12ns chips to replace TAGs though so it's actually better to reduce cache to 128k on this mobo, tighter timings work OK with single cache bank. This is 386/486 mobo, these usually are slower than pure 386 mobos for memory access. I guess the 486 burst support was more important to implement fast than getting the absolute maximum out of CPU that's about to become obsolete.

Ran cachechk with 1ws and cache off.

It looks like you have a UM481 board. I also ran into that issue where the memory has to be backed off from 0 WS to 1 WS in order to operate with cache enabled. I also suspect you have an "always dirty" configuration as mkarcher mentioned above. You can read more about it here UM481/UM491 "Always Dirty" modification HOWTO

Indeed you are correct, 481/482 umc. Looks like TK-82C390A-4S-D02A

I will read up on this dirty bit stuff. Really appreciate all the info and help with this guys.