Immature Cyrix processor and Microsoft’s banana treatment
Problems with the Cyrix 6×86’s cache under Windows NT have forced Microsoft to more or less high-handedly reconfigure the processor. Then it works just ticking over, at least in current versions.
There’s no doubt that the Cyrix 6×86 processor still has considerable difficulties in a lot of board designs. Its enormous energy consumption causes a lot of trouble in many boards. Furthermore, it has bigger problems than the Pentium with reflections on the CPU bus, especially if such big trouble makers like a Coast socket come into play. In the last issue of c’t we figured out with which CPU steppings and clock rates it sometimes begins to flounder, on account of the Chaintec IFM 586 board. Cyrix has distributed appropriate application notes to the board makers in order to suppress the disturbing reflections with help of suitable damping resistors.
In a board designed for the Cyrix processor we nevertheless had to realise that — other than the Pentium in the same board — it didn’t make it through several days of continuous operation running Windows 95 without crashing.
Cyrix has been unable to give a reason for the system crashes we experienced. Both the Cyrix vice president Steve Tobak and applications engineer Graham Jackson, responsible for European operations, declared that they don’t know about a processor bug — there are rumours of infrequent cache allocation errors.
Switched off
The American computer magazine Byte reports that the processor instabilities have lead Microsoft to simply switch off the 6×86 cache’s write back mode in the final release of Windows NT 4.0. According to Byte the result is a 30% decrease in the performance of Windows NT. More or less, this means a knockout.After all, it is supposed to earn its merits above all under Windows 95, but who’ll trust it there when it can only proceed at half speed under NT? In addition to that, an American survey showed that a good 25% of 6×86 users want to use Windows NT.
It’s quite possible, that the problems at Microsoft may have been caused only by the reflections mentionend above, since they may be noticeable only with write back cache enabled. With version 2.7 of the processor, coming on to the market now, Cyrix doesn’t just promise a few extra percent of performance (the return stack was switched off previously), but also fewer reflection problems. According to Cyrix version 2.7 can run properly under Windows NT without being slowed down. The Texan «midget», fighting for survival with its three percent market share, obviously couldn’t achieve any more from Microsoft.
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 6×86 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 6×86 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.
