Cyric CPU's

[Mike Bilow]

Richard Royston wrote in a message to Mike Bilow:

 RR> Do you have any recomendations/experience with systems using
 RR> Cyrix CPU's?

Yes, extensively.

 RR> There's an article in the Dec 96 issue of Unix Review that 
 RR> reports that WinNT needs to disable the write back cache and 
 RR> use write through cache instead, in order to run on Cyrix CPU's 
 RR> without crashing.  Any information or pointers to information 
 RR> would be appreciated.

I'll tell you exactly what is going on, and then you can make up your own mind.
First, the Cyrix 5x86 and similar processors are perfectly fine, and the
compatibility problems are only relevant to the Cyrix 6x86.  Second, only the
higher speed 6x86 processors have problems, and the slower ones usually work
correctly in most cases.

The problems with the Cyrix 6x86 are technically the fault of motherboard cache
logic, but it runs the cache with much tighter tolerances required than any
Pentium and this causes trouble even on motherboards which are nominally
certified for use with the 6x86.  Even with a very high quality motherboard
such as Asus or Tyan, you will find that tolerances are so tight that some
motherboards off the production line will work and others will not.  (No Intel
motherboard will support the 6x86, not surprisingly.)

It is important to understand that the 6x86 is optimized for 16-bit code and is
effectively tuned to run Windows 95.  This is a very reasonable marketing
decision since Windows 95 is what most people run and nearly all widely used
benchmark tests measure performance under it.  However, if you buy the
6x86-P166+ (which is actually clocked at 133 MHz) expecting to see performance
comparable to a 166 MHz Pentium, which is what benchmarks would measure
(accurately) under Windows 95, then you will be sorely disappointed under a
32-bit operating system.

We first discovered this in connection with OS/2, which does I/O much faster
than Windows NT.  If we allowed an OS/2 machine with the 6x86-P166+ to run
without implicating the DMA subsystem by doing something such as accessing the
hard drive, then it would run fine for as long as we tested.  However, if you
tried real world processing, the machine would be seriously unreliable.  Note
that we had to push the machine a bit to get it to fail, running disk-intensive
tasks and forcing memory overcommitment so that the swap file would be used,
but under these circumstances the machine would hang because of a cache fault
about twice a day.

I found a public domain OS/2 "device driver" which "fixed" the 6x86 problem on
an FTP site somewhere in Germany.  I disassembled it and found that what it
actually did was hook the timer tick and send a signal every so often to
forcibly invalidate the cache.  Although it did make OS/2 perfectly reliable on
the 6x86, I would not consider it to be a proper solution.

This experience motivated some rather extensive research into the 6x86, which
is how I learned that it was optimized for 16-bit code, and really for the
specific piece of 16-bit code called Windows 95.  I would actively avoid the
6x86 for any 32-bit operating system, whether OS/2, Linux, or Windows NT.  I
also have little confidence that a future upgrade to Windows 95 -- such as
eliminating the mutex semaphore on I/O -- will not break the 6x86.
 
-- Mike