All Bananas

Strange

For sure, there may be some more bugs in the Cyrix processor, which can lead to a crash under certain circumstances. It's just strange that with the number of known bugs in the various versions of the Pentium, Microsoft never thought it would be necessary to switch off the cache on the Intel chip with newer "builds" of NT - although that would have been at least appropriate as well from time to time.

Along with a lot of other errors (100 are currently known) the Pentium also had to fight with reflections, amongst other things, which could lead to cache inconsistencies (with the P5, error 12, see c't 7/95, page 186). Here, a reflected address could overwrite a so-called snoop address. Recommended solution: switch of the cache. Or errors in the branch prediction, which appeared with a certain access pattern under Windows NT (though very rarely). Solution: switch off branch prediction. And so on. The Pentium was, and is, only completely safe against crashes when everything is completely turned off. The same applies for the new E0 step, for which over 30 - mostly quite harmless - errata are known. Anyhow, Intel views eight of those as requiring correction for the next step.

Cyrix could learn a thing or two about Intel's willingness to publicise errors - though Intel needed the FDIV disaster before they were willing to do so.

To check just how much influence the write back cache has on performance, it has to be switched back on, something which isn't really trivial under Windows NT. You need direct access to the protected CR0 register, which is relatively easy to manage using a special VxD driver though (Cyrix claims a software solution is being "developed"...).

With write back cache enabled, there weren't any crashes with the selected test ensemble: Asus P/I P55TP4N, Quantum 1280A IDE, Elsa Winner 2000pro/x, Soundblaster, NE2000 and 32 MBytes EDO RAM. By the way, that's the same hardware environment as in the P54CTB test, so you can compare the results (here BAPCo32 with Windows NT, there with Windows 95). That's why the system clock rate was set to just 60 MHz.

The result of BAPCo under NT is impressive; with activated write back the performance goes up 46% from 98 to 144! Seen the other way round, that's the same as a reduction of 32% without write back, the value that Byte reported.

Question Mark

Why should an operating system play around with the processor configuration? After all, that's the original job of the ROM setup. And if you do that, then you should provide the user with the opportunity to play around with it. Nothing could be said against providing a window showing the risks and side effects of certain processors. But to simply slow down a manufacturer's processor on the sly does influence the competition rather blatently. Are two big monopolies in bed with each other here, in order to exclude unpopular trouble makers?

Translation by Matthew Parkes

Copyright by Verlag Heinz Heise GmbH & Co KG
This article is published with the expressed consent of the Verlag Heinz Heise

On Wednesday October 30, 1996 at 17:52 hours, xxx@cyrix.com wrote:

I'm responding about your phone call to tech support regarding NT 4.0 and promised a reply when a solution has been reached.

The Problem with NT 4.0:

Cyrix 6x86 processor systems worked fine in the beta versions of NT 4.0, Microsoft promised a certain release date, but kept pushing it further and further back. Finally when they came out with the final release, during testing, they had TWO Cyrix Platforms (motherboards) to test, one was an Asustek P55TVP4, the other was unknown to tech support. According to Microsoft, "one of the platforms failed our NT 4 test suite consistently with the internal cache in write-back mode and revision 2.6 or earlier of the CPU"...

It is now common knowledge, and even NOW states in the Asustek motherboard manuals that the motherboard requires a 2.7 or later Cyrix CPU. But I don't think Microsoft knew that at the time, so they basically applied that as a general rule for ALL Cyrix 6x86 systems. Rev 2.7 parts have been out of a while. This chip revision doesn't fix anything significant except the "bus noise/speed path" problems with that ASUS motherboard. Because Microsoft was on a tight schedule to release 4.0, they inserted a detect sequence to look for certain revisions of the chip, and if it finds it, the software DISABLES the internal cache via a CPU register, causing a 15% performance hit. Of course, when you reboot or reset your computer and boot up under any other operating system, the internal cache mode resets back to the default full-performance write-back mode.

I've heard that NT 4.11 will be out very soon (probably in about a month) and the detect/cripple sequence should be taken out of the code, and all system problems resolved by then. Cyrix has ceased testing on the software patch, because all it does at the present is reenable the internal cache via an icon. We have tried this on 57 motherboards, and have been unable to duplicate the problem in ANY applications, so there appearantly is no issue, except the fact that all the current NT 4.0 users with 2.6 or earlier parts have a slower system because is the cripple routine Microsoft's code.So what about the mean time? If you absolutely cannot wait for the release of 4.11 and HAVE to have 100% performance now, it is pretty common knowledge by the trade presses that Cyrix is offering an exchange via Steve Tobak's (vice-president of Cyrix) comment in PC Week Sept.