Q & A Repository

Subject: Re: Wang VS 12000 request

Posted By: Thomas Junker
Date: 11/10/97 at 3:17 p.m.

In Response To: SNEAK ATTACKS ON THE VS (Thomas Junker)

[The correspondent to whom this is a reply turned out to bea "Pre-Sales Engineer" for the company that was trying to sell the VS site on moving to unix]

Subject: Re: Wang VS 12000 request

Date: Mon, 10 Nov 1997 15:17:53 -0500

On 10 Nov 97 at 13:53, xxxx wrote:

> I have a client that has asked my company to produce
> performance benchmark comparisons between his existing
> VS 12000 System and the latest Unix systems, like Sun,
> IBM, HP.

Why? The fact that he has a VS12000 (which one, by the way? There are three: 12450, 12550 and 12650) is an arbitrary. He could just as easily have a VS7380 (2/3 the CPU speed of a 12650) or a VS7310 (1/5 the speed of a 12650) and be asking for the same benchmark comparison.

> He wants to get rid of the VS 12000, and go to high
> end Unix boxes.

There you have it. The "benchmark" is being sought as a justification for a strategy already decided or at least already prejudged. That's an egregiously bad way to run a business.

On a more general level your client has what amounts to a desire to move from an easy to manage platform with a rock-solid database and OS-level rollback and rollforward recovery to one which is an administrative nightmare and for which any number of truly badly written client server applications are available at exorbitant prices. Unix systems have no native file systems capable of supporting even relatively simple application packages, so every package requires its own underlying (and often third- or fourth-party) file system, which systems range from OK to awful.

It seems to me your client is caught up in an IS fashion trend. He should be made aware that not all VS migrations succeed, and some have crashed and burned with loss of careers. This is because the work being done by the VS is often grossly underestimated, the value of stable and debugged applications is grossly underestimated, and the predictability of unix systems to handle large apps and large user populations is overestimated. By and large VS systems run very smoothly for the complexity and magnitude of work they do. They make what they do seem simple, whereas many of the same tasks on other platforms require more admin, a more confusing array of software components, and far more third-party subsystems and components.

> I think we all know that the latest Unix Systems far outperform
> the VS 12000 in all categories (CPU speed, memory capacity,
> multiple processors, I/O, physical footprint, MTBF, internal &
> external disk capacity, etc.

That's not a relevant comparison. The VS12000 (all three of them) have been superceded by the VS16000 and are no longer offered. The VS16000 will be replaced in 1998 by the VS18000, already in engineering and running in the software simulations that precede chip fabrication.

The VS16850 is 1.5 times the speed of the VS12650 (and I don't know that your client even has a 12650). The VS18XXX will be almost 2.0 times the speed of the VS16850. It will use the CP18 processor, fabricated with .25-micron technology, fully pipelined and capable of executing most instructions in one microcycle. It is essentially a modern RISC chip.

> ...CPU speed...

Unfortunately I have never seen any comparable benchmarks. It seems that while a lot of people wish to presume that the VS is no longer a player, few to none of those people have ever taken the time or trouble to actually benchmark comparable systems.

> ...memory capacity...

VS12000 and 16000 (and subsequent) models handle up to 512mb of main memory. I don't know if the limit will be raised when the VS18XXX comes out. Most VS tasks function quite happily in 8mb or less of user virtual address space. The latest OS raises total task VAS from 16mb to 64mb.

Unix systems *require* far more memory to do the same job. I know of a company that replaced a rock-solid app that ran on a 64mb VS with a client/server system running on an AIX RS/6000 loaded with 1gb of RAM and multiprocessors. The IBM system never has more than 200-something users and sometimes has response time problems. TheVS also had response time problems but was only 1/3 the speed of the current VS16850 and had only 1/8 the RAM the current model supports. The new files are a large multiple of the old file sizes because the app running on the IBM system uses a brain-dead database system that doesn't even store records in compressed format. The VS does record compression at the hardware and OS level. In addition the VS was burdened with slow 1980's SMD disks while the IBM system has a sophisticated EMC RAID subsystem. So they replaced a 6-figure system with a 7-figure system and have comparable performance and a very flaky app. Go figure.

> ...multiple processors...

You have me there. Wang had 4-way MP running years ago and ran their Engineering systems on it for 1-2 years, but at the time the customer base was spectacularly uninterested, so it was never released. I've been needling Wang Engineering to consider taking MP back off the shelf. They also have a Virtual Machine OS that can run the VS OS and Wang unix on the same machine. Some customers swear by it, though it is not widely deployed.

> ...I/O...

I'm not sure what you mean by I/O. The VS has a very high I/O bandwidth. The 100mbit/sec FDDI RSF is a very narrow pipe for a large VS, which passes something like 3 or 4gbits/sec across its system bus.

Of course many VS customers still have older disk subsystems and such, which make for poor comparisons. Unix boxes typically do async telecommunications much better than VS systems, but they also impose the burden of that async processing directly on the CPU. In the traditionally async terminal world of unix we now see the amusing evolution to the emulation of block-mode terminals using async protocols because most new client/server apps that use telnet clients really need to treat screen I/O as if it were in block mode. We therefore see unix systems imposing block mode emulation directly on the CPU while Wang VS systems have done block mode screen IO in outboard microprocessor-based controllers since 1977.

VS systems also have a 100mpbs FDDI Resource Sharing Facility that allows them to function in clusters, coupled at the OS level. Using RSF the OS supports shared system access to disks, file operations across the link, distributed databases with two-phase commit, etc.

> ...physical footprint...

I suspect your client has a VS12550, which is an upgrade in a VS10000 cabinet. The VS10000 cabinet is very large because it was the physical platform designed for multiprocessing and had to provide the processor and I/O controller space as well as backpanel connectivity and power supply. Subsequent "large-cabinet" VS systems have about a 30" x 30" footprint. The small cabinet VS6230T, suitable for populations in the 100-250 user range, has about a 10" x 18" footprint. I have one sitting on my desk as I type this message.

> ...MTBF...

I know of no basis for that. In my experience VS CPU, memory and IO controller failures are extremely rare. All current models of VS have error-correcting memory, to boot. Wang itself offers RAID 7 and disk mirroring options. You may be right, but most of the VS failures I have seen have had to do with peripherals, especially SMD disks kept running far past their design lifetime.

> ...internal & external disk capacity...

Huh? Is 9gb large enough for a physical disk drive? Is terabyte size large enough for a RAID 7 subsystem? It sounds like we're trying to compare the VS of the 1980's with the very latest unix platforms. Par for the course, I guess, in the get-rid-of-the-Wang game. I'd just like *someone*, *somewhere*, just *once*, to explain to me the logic of the common management view that the VS is something to get rid of. Mind you, these are often the same management types who buy into 7-figure client/server apps that would fail as Computer Science term projects, or who refuse to spend six figures to keep their VS system up to date and instead run out and spend $10-15 million on a new system that doesn't work. I have to think that when the asylums were emptied a few years back a lot of the former inmates found high-level corporate management positions.

The standard SCSI controller for large-cabinet VS models supports two SCSI chains and does caching beyond what the drives themselves do. Large cabinet VS systems typically have 15 I/O controller slots.

> , etc.

What is included in etc?

> Any chance you can lead me to any sources of VS 12000
> information that may help me.

As I said, all three VS12000 models have been superceded. Here are some comparitive VS benchmark figures that will give you a picture of how the high-end VS models stack up against each other:

VS Model   Rating   Year   

--------   ------   ----   

VS12450     1950    1993   Slow by today's standards   

VS12550     2400    1992   12000 upgrade in 10000 cabinet   

VS12650     2475    1993   Good for up to about 500 users*   

VS16750     2475    1995   VS16K equivalent of VS12650   

VS16850     3700    1995   Good for up to about 700 users*   

VS18???     7000    1998?  Should be good for 1200+ users*   

   

*user population running COBOL apps as is typical in VS systems.   

 BASIC object code is less efficient, so fewer users.   

 Database (PACE, etc) typically generate more CPU load, so fewer   

  users.

If you would like to develop some ad hoc benchmarks to compare VS and other systems on such bases as integer calcs, float calcs, string manipulations, I may be able to help on the VS side.

Regards,

Thomas Junker

Messages In This Thread

Q & A Repository is maintained by Thomas Junker with WebBBS 5.00.