Soyo 4SAW2: Why So Slow?

Continuing to go through my junk pile, I unearthed a Soyo SY-4SAW2 motherboard. This is a late 1995 vintage 486 ISA/VLB/PCI motherboard with a SiS 85C496/497 chipset. It’s a classic Baby AT board with an AT keyboard connector, although it does support PS/2 mice (which is rather nice).

Soyo 4SAW2 Board

The board works well enough, but somehow it’s just… slow. SYSINFO from Norton Utilities 8.0 shows a score of 131 with an Intel DX4 processor running at 100MHz (33.3MHz x 3). At 75MHz (25MHz x 3), the same processor scores only 99.2. Other benchmarks fare similarly.

Yet the exact same CPU plugged into an Alaris Cougar ISA/VLB board, about a year older and using an OPTi chipset, scores 197.5 at 100MHz and 148.9 at 75MHz in SYSINFO. (And in case someone asks how I ran a 3.3V DX4 processor in the 5V-only Cougar board, I used an AMD voltage converter.) That is, the Intel DX4 processor running at 75MHz in the Alaris board scores better than when running at 100MHz in the Soyo board. Something is clearly amiss.

I tried several different 486 processors, SX and DX, AMD and Intel, with the same results. In the old Cougar board, the performance reported by SYSINFO is exactly what one would expect and in line with the built-in result for a 33MHz 486 (the way SYSINFO measures performance depends very little on memory speed and largely reflects the CPU microarchitecture and operating frequency). In the newer Soyo, every processor was slower than it ought to be.

The results didn’t change when I borrowed memory from the Alaris board and plugged it into the Soyo. The results didn’t budge. I tried tweaking the BIOS settings on the Soyo, but the best I could do was to prevent the system from booting. As long as it worked, there was no change. I should add that apart from being slow, the Soyo board is quite stable, so it doesn’t look like it’s somehow damaged.

To add insult to injury, the Soyo board actually uses 15ns L2 cache chips, while the Alaris only has 20ns (in both cases 256K). If anything, the Soyo ought to be faster!

My problem is that I don’t really know what to expect from the Soyo 4SAW2. Is my unit somehow bad? Is it set up incorrectly? (I verified the entire bazillion of jumpers on the Soyo and couldn’t find anything fishy.) Or is the SiS chipset simply junk? Based on my experience with SiS graphics chips, that’s what I’d more or less expect, but such expectations can be wrong.


I compared the two boards using the SPEEDSYS benchmark (version 4.78). The first highly suspicious thing is that the same ISA SVGA graphics adapter which achieves 3771 KB/s bandwidth on the Alaris board somehow only gets up to 1392 KB/s on the Soyo.

The story is the same with disk transfers—the same CF card can read at 5.5 MB/s on the Alaris, but only 2.9 MB/s on the Soyo. What gives?

The differences are most obvious in the memory benchmark. The L1 cache read performance is about the same in both cases, around 93 MB/s. But writes differ greatly, 31 MB/s on the Alaris vs. 20 MB/s on the Soyo (this is write-through cache so the CPU itself doesn’t matter too much).

For L2 cache accesses, the Alaris runs at almost 51 MB/s read and 31 MB/s write, while the Soyo can only get up to 35 MB/s read and 20 MB/s write. That’s with the Soyo having supposedly faster cache chips.

For main memory, the Alaris achieves 16 MB/s read and 32 MB/s write, while the Soyo can only do measly 9 MB/s reads and 21 MB/s writes. The poor read performance on the Soyo is the most striking.

The considerably lower memory bandwidth probably explains why all the other benchmarks lag… but why is the memory so slow? It’s not the memory modules themselves, as they perform just fine in the Cougar board.

What’s Going On?

If anyone has any hints, I’d be grateful. Since I only have a single 4SAW2 board and don’t have any other board with the same chipset, I can’t tell if the results are an outlier or if that’s what’s expected. And if the results are not expected, what can be done to improve them?


Update: The mysteriously poor performance was caused by… an unconnected (open) turbo switch! The fact that I’ve not built a 486 system in nearly 20 years is clearly showing.

As luck would have it, I initially only tested the board with older Intel and AMD DX4 processors where the turbo switch does not affect the CPU core frequency. Later on I tried Cyrix core processors (of IBM and TI manufacture) where the turbo switch does halve the measured frequency and the effect is thus much more obvious.

If I’m extrapolating from the SiS 496/497 datasheet and the SY-4SAW2 manual correctly, the turbo switch is implemented as a bus hold, at least for the write-through Intel/AMD DX4 processors. What that means is that memory (bus) accesses are slowed down, but the CPU core is not stopped. L1 cache reads and instruction execution are just as fast with or without turbo. For those CPUs, the turbo switch is useless because it only mildly slows down execution.

For Cyrix 486 class CPUs, the turbo switch does halve the measured CPU frequency. It also quite noticeably affects performance. It’s not entirely clear how this is implemented, but it’s possible the STPCLK# (or really SUSP# for Cyrix 486s) signal is used to throttle the CPU clock.

Better Benchmark Results

With the turbo switch engaged, SYSINFO shows a score of 197.1 for a 100MHz Intel DX4 processor, well within the margin of error of the 197.5 score achieved on the Cougar board. Hooray! The rest isn’t quite as bright though, and confirms that the SiS chipset is not that great in terms of performance.

SPEEDSYS now shows video bandwidth as 1946 KB/s which is better than the previous 1392 KB/s but nowhere near the 3771 KB/s with the same card on the Alaris board. This is probably caused by the decoupled SiS 496/497 architecture where the ISA bus is attached to the southbridge, relatively far from the northbridge and the CPU, and behind a “slow link machine”.

Disk performance also increased, from 2.9 MB/s to 3.9 MB/s. Again that’s not as good as the 5.5 MB/s on the Alaris, but it is a sizable improvement. Both the Cougar and the 4SAW2 use a VL-Bus IDE controller and in theory there is no reason why the SiS chipset should be any slower. However, there might be some difference caused by the BIOS (MR BIOS vs. AWARD).

It’s worth mentioning that the SiS 496 northbridge multiplexes the (VLB) IDE pins with the PCI address pins. The consequence of this design is that IDE cycles block PCI cycles and vice versa. This arrangement obviously has a negative performance impact in certain scenarios.

And now for main memory bandwidth: from 9 MB/s reads and 21 MB/s writes, with the turbo switch engaged the performance goes up to 12 MB/s reads and 32 MB/s writes. This is still not quite as good as the 16 MB/s read and 32 MB/s write on the Cougar board, but it’s in the same ballpark.

The L2 cache bandwidth shows a similar story,  going from 35 MB/s read and 20 MB/s write to 51 MB/s read and 31 MB/s write, which more or less exactly matches the Alaris board.

All in all, the Soyo 4SAW2 is a decent if not great board… when the turbo switch is on.

This entry was posted in PC hardware. Bookmark the permalink.

21 Responses to Soyo 4SAW2: Why So Slow?

  1. Peter Godwin says:

    It’s not a very satisfying answer, but I recall having and reading of similar issues around the same era. I personally owned a couple of 486 boards which had drastically different performance. I don’t recall specifics, but I’m almost certain they had the same chipset, same cache, etc and were even the same brand. No matter what I did, swapping memory, VLB graphics and IO boards it was always consistently slower.

    Likewise I recall reading reviews of the and noting big differences in performance between boards on the same configuration. I’ll have to see what I can find between and Googles collection. I distinctly remember one set of motherboard reviews in the UK PcPro around the time the Pentium MMX was released that also had large benchmark differences.

  2. Chris W. says:

    Ouch. Those memory bandwidth numbers are painful.

    UMC is generally regarded as having made the best all-around late-model 486 chipset, but the SiS 496/497 is actually one of the better ones and doesn’t fit the later perception of SiS as well…cheap shit. It shouldn’t be your issue.

    You may wish to try modding and updating the BIOS:

    I would direct you to Vogons anyway, they have a rather dedicated group of 486 enthusiasts and if anyone can help you out, it will be one of them (the user “Fepoia” has compiled his own database of 486 motherboards and evidently still uses a Cyrix 5×86 as his day-to-day box – dedication!)

  3. Calvin says:

    > sis

    yeah, it’s crap

  4. Michal Necasek says:

    From my own experience with more recent Pentium III systems I know that the chipset (440BX FTW!) and memory type (PC66 vs. PC100, CL2 vs. CL3) make a big difference. But here I don’t have enough data for comparison, and something just seems off. It could still be some BIOS setting, but I have no idea what. Hmm, I wonder if datasheets for the SiS chipset are available… there could be something in there.

  5. Peter says:

    The Asus PVI-486SP3 uses the same chipset. Perhaps some owns one and can do some benchmarks.

  6. Chris W. says:

    Bandwidth rates from CACHECHK on a ASUS-486PVISP3 w/ IntelDX4-100 16kB L1:

    L1 cache is 16KB — 103.6 MB/s 10.1 ns/byte (266%) (185%) 3.9 clks
    L2 cache is 256KB — 55.9 MB/s 18.8 ns/byte (143%) (100%) 7.2 clks
    Main memory speed — 38.9 MB/s 27.0 ns/byte (100%) [reading] 10.3 clks
    effective RAM access time (read) is 108ns
    Effective RAM access time (write) is 61ns

  7. Trowa Barton says:

    Could this be an issue of write through vs write back caching?

  8. Back when it was a new thing, I remember 486’s with PCI being incredibly slow, compared to the VL versions.

    The first PCI board I got was a dual Pentium board from Tyan, the tomcat if I remember correctly. Probably this one ( ). At any rate it had an intel chipset, and worked fine for NT 4.0 and Linux.

  9. Michal Necasek says:

    I’m not really disputing that, but… why should adding PCI support to a 486 make it slow? Having read through the SiS 496/497 datasheet, I could not identify anything that should make the chipset slow by design, or any reason why adding PCI would make it slower.

    I did see some reports of an open turbo switch slowing things down, but I’m fairly sure that is not my problem as everything detects the expected CPU frequency. I should soon get a few other CPUs to experiment with further, maybe that will reveal something. I also have to check if my board supports EDO RAM (at least some revisions of the chipset did) and if it does, I’ll have to see if that makes any difference.

  10. Chris W. says:


    PCI chipsets were hit and miss on the 486, often dependent on how the motherboard vendor chose to implement them. (In particular with respect to compatibility and performance of PCI bus-mastering) There were some vendors who cut corners and would bridge PCI to the VL Bus, which often crippled its performance and broke DMA. (You could also bridge VL to the PCI bus to have it on the board as well- I have no idea how well that works for the VLB card as I never tried it.)

    The other problem with PCI 486’s is that the PCI spec is often rather early and you can funky incompatibilities with more modern cards for reasons that aren’t always clear. (The original Intel Saturn boards, for instance, were – if memory serves – rather solid, but compatibility is pretty bad with any recent PCI cards).

    Reading that SiS datasheet I see it officially supported EDO RAM. The UMC 888x did as well. But I’ve never experienced (or seen evidence) of *any* benefit with EDO RAM on a 486 and it’s always perplexed me as to why that is.

  11. Michal Necasek says:

    FWIW, the SiS 496 seems to have a sensible architecture, with VL-Bus interfacing directly to the CPU (as one would expect) and PCI on a host bridge built into the “northbridge” (not behind VLB or anything). In theory it should be able to perform well. PCI bus masters should also be properly supported (in 3 out of 4 slots depending on board configuration).

    I have zero experience with the UMC 486 PCI chipset.

  12. Will says:

    I recall my father having an ICL Model 75 from about 1993 – 486dx 33mhz, 14mb of RAM. Bizarrely it was lightning-fast, even in 1999. No idea how that happened. Must be how they’re designed/built… or witchcraft.

  13. Stiletto says:

    Chris W. – looking for UMC official documentation on the UM8881F / UM8886 BTW 😉

  14. Michal Necasek says:

    No… it was the turbo switch. Can’t believe I missed it.

  15. Raijinzrael says:

    So it works fast now?

  16. Raijinzrael says:

    I didn’t see the update note before. Sorry.

  17. Michal Necasek says:

    No problem. And yes, it’s reasonably fast now. Not super fast but not so slow that I’d wonder what’s wrong 🙂

  18. Yuhong Bao says:

    “(The original Intel Saturn boards, for instance, were – if memory serves – rather solid, but compatibility is pretty bad with any recent PCI cards)”
    Not surprising, as Saturn was developed with the development of the original PCI 1.0 spec in 1991-1992, before the now-familiar slot connector even existed.

  19. Diego says:


    I have the same Soyo board with a very updated hardware configuration. I say this is “The Most Powerfull 486 In The World”, ehehe.

    It has an AMD 5×86-P75 133/160Mhz, 512KB 15ns L2 cache onboard, 256MB RAM EDO 60ns, graphics S3 Savage-4 32MB PCI with a Mpeg-2 card Real Magic Hollywood Plus, Sound Blaster 64 Gold, PCI USB 2.0 controller, and DVD + CD-RW optical drives.

    My problem is that I want to install Windows 2000 but I can’t do it because I haven’t the UM8886 IDE controller driver for Windows 2000 and is totally impossible to install without the driver. The computer works fine with Windows ME but I’d like to update it for squeeze every posibility of the software and hardware (Linux is not an option).

    Please, if you have the UM8886 IDE driver for Windows 2000, e-mail me to: [email protected]

    Thank you, and sorry for my poor english.

  20. Daniel says:

    Thanks a lot. I had the very same issue.
    Jumpered the Turbo Switch an there you go!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.