VOGONS


First post, by viper32cm

User metadata
Rank Member
Rank
Member

How much does a Socket 5 processor benefit from the presence of motherboard cache? My recollection is that not all systems of that vintage had motherboard cache (e.g., a lot of Packard Bells) but the ones that did had 256KB.

Reply 1 of 14, by dionb

User metadata
Rank l33t++
Rank
l33t++

No cache wasn't so much a thing of that vintage but of a particular - bottom feeder - market segment. It started as soon as motherboard cache started going mainstream in later 386 era and continued until even Intel got into the game later (briefly) with the Covington Celeron.

As for So5 and cache, it depends which cache. Early So5 used asynch cache, which was better than nothing, but gave at best a few percent better memory performance. Later So5 started using PLB cache, which dramatically improved preformance, with up to 20% higher memory scores and - depending on the application - high single digit to low double digit percentage improvement in application performance.

Because PLB was so useful, but also so expensive, So5 was the era of the COAST slot, allowing boards to ship with cheap asynch (or no L2 cache at all) but to advertise "PLB-ready".

As for the amount, it depended on chipset, some supported up to 1MB (officially; 2MB might be possible unofficially on some SiS chipsets), but except in a very small set of applications, performance didn't scale much past 512kB and the ubiquitous 256kB gave you most of that boost already.

Reply 2 of 14, by mpe

User metadata
Rank Oldbie
Rank
Oldbie

The Pentium architecture with its relatively modest L1 size and wide cache line desperately needs at least some L2 cache. Otherwise the performance drops quite a lot (20% or more depending on the app). This is primarily due to pipeline stalls when experiencing internal cache miss (because of high RAM latency). The timings are also super important too as vast majority of transfers are burst transfers to fill the internal cache. That's why modern synchronous designs with reduced burst latencies work so well. Just having different cache timings can move performance one or two CPU classes up or down. That's how important it is.

When Intel introduced Triton chipset one of its propositions marketed to vendors, like Packard Bell, was that it allowed for cheaper cacheless systems. In those system the missing expensive L2 cache was meant to be compensated by reduced RAM latencies (EDO RAM). This didn't really work out.

I tried to measure the impact of cache size and found that although you get diminishing results as you grow size, with the right application the performance still improves:

Blog|NexGen 586|S4

Reply 3 of 14, by ph4nt0m

User metadata
Rank Member
Rank
Member

SRAM was still expensive when Socket 5 was in production. Many mainboards had DIP sockets for cache memory and could take up to 2Mb. Later models switched from async SRAM in DIP sockets to pipelined burst SRAM in PQFP chips. The usual configuration was 256Kb soldered to mainboard and additional 256Kb installable on a COAST module. Although there were boards with no cache soldered and just a COAST slot. PBSRAM is faster, x-1-1-1 vs. x-2-2-2 timings at 66MHz.

My Active Sales on CPU-World

Reply 4 of 14, by viper32cm

User metadata
Rank Member
Rank
Member
mpe wrote on 2020-04-22, 07:17:

When Intel introduced Triton chipset one of its propositions marketed to vendors, like Packard Bell, was that it allowed for cheaper cacheless systems. In those system the missing expensive L2 cache was meant to be compensated by reduced RAM latencies (EDO RAM). This didn't really work out.

My old Packard Bell system is the reason I asked the question. I'm trying to create a bit of a tribute (through better) system. My memory and research all basically confirm that PB omitted L2 cache from my computer. The system I'm using as the basis for my new build has a 256kb COAST module, but it is asynch cache.

And as for the RAM in those old PB systems. No way did I have EDO ram. FPM all the way. And no cache. It didn't really matter when the computer was new and everything was DOS and Win 3.11, but add in Windows 95 and games that needed low-end Pentium hardware . . . well, it sucked.

Reply 5 of 14, by dionb

User metadata
Rank l33t++
Rank
l33t++
viper32cm wrote on 2020-04-22, 17:15:
mpe wrote on 2020-04-22, 07:17:

When Intel introduced Triton chipset one of its propositions marketed to vendors, like Packard Bell, was that it allowed for cheaper cacheless systems. In those system the missing expensive L2 cache was meant to be compensated by reduced RAM latencies (EDO RAM). This didn't really work out.

My old Packard Bell system is the reason I asked the question. I'm trying to create a bit of a tribute (through better) system. My memory and research all basically confirm that PB omitted L2 cache from my computer. The system I'm using as the basis for my new build has a 256kb COAST module, but it is asynch cache.

And as for the RAM in those old PB systems. No way did I have EDO ram. FPM all the way. And no cache. It didn't really matter when the computer was new and everything was DOS and Win 3.11, but add in Windows 95 and games that needed low-end Pentium hardware . . . well, it sucked.

Packard Bell with a COAST slot? Sounds like the PB640 aka "Thousand Oaks", a pretty decent Intel OEM board in LPX form factor. They shipped with EDO, not FP, but regardless, FP vs EDO didn't make as much difference as oft touted, async vs PLB cache is a much bigger jump. Replace that 256kB COAST with a 256kB or 512kB PLB one and you will notice the difference.

Most of the reason PB sucked was a bloated software load on install. That and aiming for the very bottom end of the market, with customers with vague, unrealistic expectations and nowhere near the budget to fulfil them. It's telling that in later NEC-owned PB days the hardware of PB and NEC systems was completely identical, but NEC sold at a premium and received positive reviews whereas PB systems with the same hardware and a different sticker were panned...

Reply 6 of 14, by auron

User metadata
Rank Oldbie
Rank
Oldbie

some more benchmarking data on this here: Let's benchmark our systems with caches disabled

ph4nt0m wrote on 2020-04-22, 12:24:

The usual configuration was 256Kb soldered to mainboard and additional 256Kb installable on a COAST module. Although there were boards with no cache soldered and just a COAST slot.

when looking at intel's 430FX socket 5 boards, which must have been high volume OEM favorites, on one hand there's the endeavour that had the option of COASt with either async cache or PLB available for that, or PLB soldered on, but going by pictures, the boards with PLB did not come with a COASt soldered on. the other was the zappa, which could have 256k of async cache soldered on, but apparently quite a high number of them came with no cache at all, and obviously no way to upgrade. the zappa board that i have came with a p75, 8mb 60ns FPM and no cache, presumably the original configuration going by the matching mid-'95 datecodes.

Last edited by auron on 2020-04-22, 19:05. Edited 1 time in total.

Reply 7 of 14, by mpe

User metadata
Rank Oldbie
Rank
Oldbie

The benefit of EDO cycle is actually bigger on a cache-less system. So at least in this respect the concept worked. However, any sort of L2 cache is still better.

Blog|NexGen 586|S4

Reply 8 of 14, by viper32cm

User metadata
Rank Member
Rank
Member
dionb wrote on 2020-04-22, 18:18:

Packard Bell with a COAST slot? Sounds like the PB640 aka "Thousand Oaks", a pretty decent Intel OEM board in LPX form factor. They shipped with EDO, not FP, but regardless, FP vs EDO didn't make as much difference as oft touted, async vs PLB cache is a much bigger jump. Replace that 256kB COAST with a 256kB or 512kB PLB one and you will notice the difference.

Most of the reason PB sucked was a bloated software load on install. That and aiming for the very bottom end of the market, with customers with vague, unrealistic expectations and nowhere near the budget to fulfil them. It's telling that in later NEC-owned PB days the hardware of PB and NEC systems was completely identical, but NEC sold at a premium and received positive reviews whereas PB systems with the same hardware and a different sticker were panned...

Sorry, I wasn't clear. The system I'm using the build my PB "tribute" is an old Zenith Z-Station GT. It's actually an early-Socket 7 system with an Opti Viper chipset. I bought it about three years ago and then replaced it last year, but I've decided I want something slower than a P233MMX, so this project sounded like a good idea.

My old PB had the PB600 motherboard. The spec for that computer includes 256kb of cache soldered on the board, but a lot of the systems (most?) shipped without cache on the board. I know mine did not have the cache.

Reply 9 of 14, by pentiumspeed

User metadata
Rank l33t
Rank
l33t

Suppose if new question this time now to add to this EDO vs 66MHz SDRAM on the TX or VX chipset.

Even with no cache, what's the impact using SDRAM instead of EDO?

Cheers,

Great Northern aka Canada.

Reply 10 of 14, by ph4nt0m

User metadata
Rank Member
Rank
Member
pentiumspeed wrote on 2020-04-23, 02:00:

Even with no cache, what's the impact using SDRAM instead of EDO?

It's noticeable. You have to get those early 32Mb SDRAM modules though.

My Active Sales on CPU-World

Reply 11 of 14, by dionb

User metadata
Rank l33t++
Rank
l33t++
pentiumspeed wrote on 2020-04-23, 02:00:

Suppose if new question this time now to add to this EDO vs 66MHz SDRAM on the TX or VX chipset.

Even with no cache, what's the impact using SDRAM instead of EDO?

Cheers,

Bit offtopic here as VX and TX are solidly So7, not So5.

Reply 12 of 14, by mpe

User metadata
Rank Oldbie
Rank
Oldbie
dionb wrote on 2020-04-23, 11:42:

Bit offtopic here as VX and TX are solidly So7, not So5.

True. If I wanted being nitpicky then please be aware than in its reference design the 430VX was presented as Socket 5 (Socket 7 ready) chipset:

Screenshot 2020-04-23 at 13.57.31.png
Filename
Screenshot 2020-04-23 at 13.57.31.png
File size
367.76 KiB
Views
674 views
File license
Public domain

Now I am motivated to find at least one Socket 5 VX board 😀

Blog|NexGen 586|S4

Reply 13 of 14, by dionb

User metadata
Rank l33t++
Rank
l33t++
mpe wrote on 2020-04-23, 13:07:
[...] […]
Show full quote

[...]

True. If I wanted being nitpicky then please be aware than in its reference design the 430VX was presented as Socket 5 (Socket 7 ready) chipset:

Screenshot 2020-04-23 at 13.57.31.png

Now I am motivated to find at least one Socket 5 VX board 😀

Argh, now I'm looking too 🙁 😜