24 Oct
1999
24 Oct
'99
5:54 a.m.
Figure about 1992-93 for that model. I used to have accounts on one when I
was at DEC.
<Looks like the 6500 was about 13 VAX-11/780 MIPS. That would make it abou
<2x to 3x slower than a 486DX2/66.
Not even close. More like a stack of a dozen or more of the 486s. It
usually ran between 30-50 VT1200 Xwindows type terminals under VMS 5.5
plus the usual batch load and plain terminal user base. I doubt a
486dx/66 running linux could support 50-100 50 users running web browsers
that smoothly while providing print services to 4-6 laser printers.
Since the group had some 486dx/50s we could compare. The 486 was slower
for any IO despite the SCSI, could not multitask well and was known for
crashing (w3.11) something uncommon the VAX world.
Apples and oranges, the VAX especially the bigger models with the CI and
other high perf IO busses can easily pound PCI pentiums into the ground
for shear load.
A 6000-530 is 40" corperate cabs typically 3-4 of them more depending on
the disks. Compared to a 780 its small. Compared to a 3100 it's huge.
You would need a 16ft truck, lift gate or ramps. Power, basic system will
run off a wall outlet barely if modded for single phase.
OS, ultrix a BSD derivitive some like it, some hate it, it runs. VMS is
the other OS commonly run and current (V7.2) is avaiable under hobbiest
license and supports the SMP.
Allison
24 Oct
24 Oct
7:36 a.m.
New subject: IBM 5100
Well, it had to happen. There is the Basic version of the IBM 5100 up for
auction on ebay; the current price is $610 with 9 1/2 days to go. This will
be the first time I have seen the 5100 sold there, and it will be
interesting to see where the pricing goes!!! The URL is:
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=187128153
10:44 a.m.
On Sun, 24 Oct 1999, Allison J Parent wrote:
<Looks like the 6500 was about 13 VAX-11/780 MIPS.
That would make it about
<2x to 3x slower than a 486DX2/66.
Not even close. More like a stack of a dozen or more of the 486s. It
If you look at:
http://www.digital.com/timeline/1990-4.htm
It states: "The VAX 6500 processor delivered approximately 13 times the
power of a VAX-11/780 system, per processor."
To me, that means "13 MIPS". 13 MIPS is about 2 to almost 3 times slower
than a 486dx2/66.
But let's take a look at some Dhrystone 2.1 numbers I found:
CPU MIPS MIPS
System OS CPU (MHz) V1.1 V2.1
---------------------- ------------ ----------- ----- ------ ------
VAX 8650 4.3 BSD ----------- 18 6.3 6.2
cc -non_shared -DUNIX -O5 -ifo
80486DX2/66 Linux 2.0.0 80486DX2 66 29.3 26.9
gcc 2.7.2, gcc -DUNIX -O2
80486DX2/66 NetBSD 1.4.1 80486DX2 66 ---- 34.4
egcs -DUNIX -O2
For the Dhrystone 2.1 case, 26.9 / 6.2 = 4.33 --> dx2/66 is 4 1/3 times as
fast as the 8650. (Using the slower Linux numbers, too).
As a sanity check, look at http://www.digital.com/timeline/1984-3.htm
For the 8600, it states: "The VAX 8600, shown here during assembly, offered
up to 4.2 times the performance of the industry standard VAX-11/780... ".
Therefore, the 8600 was 4.2 MIPS. I can't find Dhrystone 2.1 numbers for
the 8650, but let's be generous, and assume that the 8650 was 1.5x as fast
as the 8600 (because the 785 was 1.5x the 780). That puts the 8650 at
6.3 MIPS, which is in rough agreement with the other Dhrystone number, above.
And, back of the envelope, the 6500 was 2x the 8650.
So, if it is not a typo on http://www.digital.com/timeline/1990-4.htm
then my original assertion is, indeed, correct: The 6500 is 2x to 3x slower
than a dx2/66. ( And the vax 6000-530 is even slower. )
I don't know what it is about collectors that somehow confuses their
memories of the past; maybe their internal core memories have suffered some
bit flips? ;-) (I have some old junk, too, so I consider myself in the
same camp...)
Fact is, these old machines were slow, noisy, hot, power-guzzling behemouths
compared with what we have today.
usually ran between 30-50 VT1200 Xwindows type
terminals under VMS 5.5
plus the usual batch load and plain terminal user base.
As you know, the vax would run the X -client- which, of course, is not
much of a load. And as for running 50 users, heck, at the VCF 3.0 there
was a guy showing an 8080 running timesharing on a bunch of terminals!
Therefore, to me, you have to measure the performance in some repeatable
way. Dhrystone is not the perfect benchmark (which is close to an oxymoron
anyway), but it is -a- benchmark for integer CPU performance.
for any IO despite the SCSI, could not multitask well
and was known for
crashing (w3.11) something uncommon the VAX world.
It's too bad that you had to run w3.11; I'm assuming you're running a real
OS on the dx2/66.
Apples and oranges, the VAX especially the bigger
models with the CI and
other high perf IO busses can easily pound PCI pentiums into the ground
for shear load.
Now, let's talk about busses. Just how fast -was- this CI? Let's compare
that with 66 MHz 64-bit PCI, which has 66e6 x 64 = 4,224,000,000 bits/sec
peak throughput. What was CI's throughput?
Allison
-Mike Cheponis
11:06 a.m.
Mike Cheponis wrote:
[stuff deleted]
Dunno; perhaps Allison does. Never was much of a VAX fan...
Best,
Chris
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
So, if it is not a typo on
http://www.digital.com/timeline/1990-4.htm
then my original assertion is, indeed, correct: The 6500 is 2x to 3x slower
than a dx2/66. ( And the vax 6000-530 is even slower. )
It looks to me like Allison was making an assertion about thruput in
a multiuser configuration. Thruput in a demand paged operating system
is generally bounded by I/O bandwidth, not CPU bandwidth, so the fact
that the 486 turns in better integer performance doesn't invalidate
her argument.
I don't know what it is about collectors that
somehow confuses their
memories of the past; maybe their internal core memories have suffered some
bit flips? ;-) (I have some old junk, too, so I consider myself in the
same camp...)
No confusion; there are simply different metrics for performance and she's
using a different one than you. You are both, in fact, correct. The 486
will outperform the VAX in integer performance, but the VAX has bundles
more bandwidth to disk than the 486 ever dreamed of.
Fact is, these old machines were slow, noisy, hot,
power-guzzling behemouths
compared with what we have today.
No argument there ;-)
[snip]
Therefore, to me, you have to measure the performance
in some repeatable
way. Dhrystone is not the perfect benchmark (which is close to an oxymoron
anyway), but it is -a- benchmark for integer CPU performance.
Right. To address Allison's argument you need to measure sustained and burst
bandwidth to disk.
[snip]
Apples and
oranges, the VAX especially the bigger models with the CI and
other high perf IO busses can easily pound PCI pentiums into the ground
for shear load.
Now, let's talk about busses. Just how fast -was- this CI? Let's compare
that with 66 MHz 64-bit PCI, which has 66e6 x 64 = 4,224,000,000 bits/sec
peak throughput. What was CI's throughput? 
11:46 a.m.
On Sun, 24 Oct 1999, Allison J Parent wrote:
Time for a short lecture in hardware architecture (you can tell
where I'm from :-)). Integer performance is a very misleading
measure of performance when you are talking about system
performance. Not even the supercomputing community uses
raw integer or floating point performance as a benchmark,
there are far too many other issues. For example, all except
the most recent PCs, there is only a single bus. This bus
must be used for all memory transfers, graphics, I/O, etc.
On a single user system, this is sometimes okay, but for
multiple users forget it. Most of the VAXes had multiple
busses, and each was dedicated to a particular function.
This meant that the combined throughput was considerably more
than any existing PC bus. One of the main problems with
all of the PC chips is the limited speed of the FSB. Its
no good having high integer performance if you can't get
the data in or out of the CPU.
I do a lot of high end graphics, both on PCs and SGIs.
Individually the components on the PCs are faster
than the corresponding components on the SGI. The old
195Mhz R10000 do match up to PIII processor speeds, and
I can buy PC graphics cards that have more raw graphics
power than an IR pipe. But, the overall system performance
of the SGI is at least 5x better than the best PC
configuration, and it can bury the PC on any app that
moves a lot of data. Large systems were designed and
built for throughput, so its quite possible that one
of these old systems could outrun a modern PC in high
throughput applications.
--
Dr. Mark Green mark(a)cs.ualberta.ca
Professor (780) 492-4584
Director, Research Institute for Multimedia Systems (RIMS)
Department of Computing Science (780) 492-1071 (FAX)
University of Alberta, Edmonton, Alberta, T6G 2H1, Canada
<Looks like the 6500 was about 13 VAX-11/780
MIPS. That would make it about
<2x to 3x slower than a 486DX2/66.
Not even close. More like a stack of a dozen or more of the 486s. It
If you look at:
http://www.digital.com/timeline/1990-4.htm
It states: "The VAX 6500 processor delivered approximately 13 times the
power of a VAX-11/780 system, per processor."
To me, that means "13 MIPS". 13 MIPS is about 2 to almost 3 times slower
than a 486dx2/66.
But let's take a look at some Dhrystone 2.1 numbers I found:
CPU MIPS MIPS
System OS CPU (MHz) V1.1 V2.1
---------------------- ------------ ----------- ----- ------ ------
VAX 8650 4.3 BSD ----------- 18 6.3 6.2
cc -non_shared -DUNIX -O5 -ifo
80486DX2/66 Linux 2.0.0 80486DX2 66 29.3 26.9
gcc 2.7.2, gcc -DUNIX -O2
80486DX2/66 NetBSD 1.4.1 80486DX2 66 ---- 34.4
egcs -DUNIX -O2
For the Dhrystone 2.1 case, 26.9 / 6.2 = 4.33 --> dx2/66 is 4 1/3 times as
fast as the 8650. (Using the slower Linux numbers, too).
As a sanity check, look at http://www.digital.com/timeline/1984-3.htm
For the 8600, it states: "The VAX 8600, shown here during assembly, offered
up to 4.2 times the performance of the industry standard VAX-11/780... ".
12:24 p.m.
Mark Green wrote:
Mike Cheponis wrote:
> Looks like the 6500 was about 13 VAX-11/780 MIPS. That would make it about
> 2x to 3x slower than a 486DX2/66.
Integer performance is a very misleading
measure of performance when you are talking about system performance.
My main belief is that nobody is going to keep a VAX anything running with
dozens of simultaneous users. So, if a VAX is to be something close
to "useful" today, it'll be in single-user mode. In that case, Integer
performance is very important.
Now, perhaps if we were to port Apache to the VAX, and used that I/O bandwidth
on multiple DS3s, well, that's great.
for example, all except
the most recent PCs, there is only a single bus. This bus
must be used for all memory transfers, graphics, I/O, etc.
On a single user system, this is sometimes okay, but for
multiple users forget it.
Hey, I'm not saying the original IBM PC was going to outperform the VAX 6500;
but a modern PC will crush any VAX in any application, IMHO, with equivalent
h/w attached.
Most of the VAXes had multiple
busses, and each was dedicated to a particular function.
What are:
1) The names of these busses?
2) Their uses?
3) Their peak and average throughputs?
I certainly know for a fact that UNIBUS performed very poorly. I don't have
data at my fingertips, but it seems to me it was around 10 Mb/s (that
megabits/sec) peak throughput. [I prefer measuring throughputs in bits/sec
since that normalizes across different bus widths.]
This meant that the combined throughput was
considerably more
than any existing PC bus.
I'm trying to get away from fuzzy terms like "considerably more" and get to
hard, cold numbers. Just -exactly- how fast were these things?
And, if you don't like Dhyrstone 2.1, then what benchmarks -can- we use?
One of the main problems with
all of the PC chips is the limited speed of the FSB. Its
no good having high integer performance if you can't get
the data in or out of the CPU.
Fast dual-port SRAM solves the problem, but commodity PCs aren't designed
that way. Also, the AGP bus uses mega-RAM to speed up PC graphics, for example.
I do a lot of high end graphics, both on PCs and SGIs.
of the SGI is at least 5x better than the best PC
configuration, and it can bury the PC on any app that moves a lot of data.
I appreciate the SGI vs PC datapoint, but what's the PC vs VAX datapoint?
Large systems were designed and built for throughput,
so its quite possible
that one of these old systems could outrun a modern PC in high throughput
applications.
OK, then what's the performance of a VAX running Apache vs a K7 running Apache?
-Mike Cheponis
3:05 p.m.
Mark Green wrote:
You've got to be kidding!!! Most VAXes out there are running large
multiuser systems. The VAX has not been out of production for
very long, and there are still a considerable number of systems
that are running on them. If you meant it in terms of dozens of
users being too small, I might agree. Many of these systems are
running more like hundreds of users.
Mike Cheponis wrote:
> Looks like the 6500 was about 13 VAX-11/780 MIPS. That would make it about
> 2x to 3x slower than a 486DX2/66.
Integer performance is a very misleading
measure of performance when you are talking about system performance.
My main belief is that nobody is going to keep a VAX anything running with
dozens of simultaneous users. So, if a VAX is to be something close
to "useful" today, it'll be in single-user mode. In that case, Integer
performance is very important.
Now, perhaps if we were to port Apache to the VAX, and
used that I/O bandwidth
on multiple DS3s, well, that's great.
The problems is equivalent hardware. You can't configure a PC
like a VAX, they are two different types of machines. A PC
is tuned for a single user, while a VAX is tuned for many users.
These are very different machine configurations, and even the latest
PC would have no hope of keeping up to a decade old VAX running
a large multiuser application. Many of the PC manufacturers
have tried to scale PCs to this level and they have all failed.
This is why companies like IBM, HP, SUN and SGI are still selling
big iron, and sales are increasing rapidly. There is a huge
demand for server style systems, and single bus systems like
the PC can't scale to the performance required.
for example, all except
the most recent PCs, there is only a single bus. This bus
must be used for all memory transfers, graphics, I/O, etc.
On a single user system, this is sometimes okay, but for
multiple users forget it.
Hey, I'm not saying the original IBM PC was going to outperform the VAX 6500;
but a modern PC will crush any VAX in any application, IMHO, with equivalent
h/w attached.
Most of the VAXes had multiple
busses, and each was dedicated to a particular function.
What are:
1) The names of these busses?
2) Their uses?
3) Their peak and average throughputs?
I certainly know for a fact that UNIBUS performed very poorly. I don't have
data at my fingertips, but it seems to me it was around 10 Mb/s (that
megabits/sec) peak throughput. [I prefer measuring throughputs in bits/sec
since that normalizes across different bus widths.]
The UNIBUS was only on the early VAXes, and it was there to
support legacy peripherals. This meant you didn't need to
buy a whole new set of peripheral when you upgraded to a
VAX. Remember that the early VAXes also had PDP11 compatibility
mode, so you could move your existing applications over to
them with conversion.
And, if you don't like Dhyrstone 2.1, then what benchmarks -can- we use?
Each application area has their own set of benchmarks that
reflect their use of the machine. For example, a lot of the
supercomputer centers use fluid dynamics programs to evaluate
machines, since that's what takes up most of their cycles. We
take a two pronged approach to graphics performance. One is
to run some standard visualization and measure frame rate (this
ties us to the real world). Second is to run a set of programs
that measure individual aspects of the graphics pipeline,
such as transformation rate (as a function of vertices/polygon),
fill rates, lighting rates, texture rates, along with
where the pipeline blocks. This give us a pretty good picture
of the display, and how we will need to generate code to
drive it.
One of the main problems with
all of the PC chips is the limited speed of the FSB. Its
no good having high integer performance if you can't get
the data in or out of the CPU.
Fast dual-port SRAM solves the problem, but commodity PCs aren't designed
that way. Also, the AGP bus uses mega-RAM to speed up PC graphics, for example.
5:56 p.m.
>Mark Green wrote:
>
>>Mike Cheponis wrote:
>>>Looks like the 6500 was about 13 VAX-11/780 MIPS. That would make it about
>>>2x to 3x slower than a 486DX2/66.
>>Integer performance is a very misleading
>>measure of performance when you are talking about system performance.
>My main belief is that nobody is going to keep a
VAX anything running with
>dozens of simultaneous users. So, if a VAX is to be something close
>to "useful" today, it'll be in single-user mode. In that case, Integer
>performance is very important.
You've got to be kidding!!! Most VAXes out there
are running large
multiuser systems. The VAX has not been out of production for
very long, and there are still a considerable number of systems
that are running on them. If you meant it in terms of dozens of
users being too small, I might agree. Many of these systems are
running more like hundreds of users.
That's fascinating. Take obsolete hardware and architecture (vax), and
keep them running! I guess I will never cease to be amazed at the weird
things people do. Heck, I heard the other day that people are -still-
running 1401 emulation mode under a VM/360 simulator on their modern h/w!
>Now, perhaps if we were to port Apache to the VAX,
and used that I/O bandwidth
>on multiple DS3s, well, that's great.
The problems is equivalent hardware. You can't
configure a PC
like a VAX, they are two different types of machines. A PC
is tuned for a single user, while a VAX is tuned for many users.
Amen! Thank you!
I think all the flamage back and forth needs to accept this, and I think
Chuck first brought it up. That's right!
Remember, I was just making the observation that the integer performance of
the vax 8650 is worse than a dx2-66. I think single-user; I run single-user
machines. The future is single-user with vast network-accessed databases.
These are very different machine configurations, and
even the latest
PC would have no hope of keeping up to a decade old VAX running
a large multiuser application.
Again, with -equivalent hardware- it certainly would.
Many of the PC manufacturers
have tried to scale PCs to this level and they have all failed.
This is why companies like IBM, HP, SUN and SGI are still selling
big iron, and sales are increasing rapidly. There is a huge
demand for server style systems, and single bus systems like
the PC can't scale to the performance required.
What you failed to mention is that sgi is -only- selling NT these days,
having given up on Big Iron. Also, the market sizes for IBM, HP, and Sun's
"big iron" exist specifically to be those back-room servers that can do lots
of disk I/Os per second (the web, eh?).
I fully agree that computer systems designed for specific purposes are
going to do better for those applications than a PC.
BUT, I would like the Vax Lover Crowd to acknowledge that they integer
performance of their machine is pathetic.
Its not the speed
of the individual bus, but its the number of busses.
That's of course bull.....
The more busses, the more parallelism and the less
waiting.
-IF- the speed of the busses is high enough!
One
fast bus works well until you want to do multiple things, and
then it quickly becomes a bottleneck.
Excuse me? Could you please back up this assertion with data? After all,
at -some- point, all these busses have to get their data into/out of the CPU,
right? And -that- is a "bottleneck" for sure... (Sure, you can have
channel-to-channel I/O, but most aps are not just shuffling bits.)
And, if you
don't like Dhyrstone 2.1, then what benchmarks -can- we use?
Each application area has their own set of benchmarks that
reflect their use of the machine. For example, a lot of the
supercomputer centers use fluid dynamics programs to evaluate
machines, since that's what takes up most of their cycles. We
take a two pronged approach to graphics performance. One is
to run some standard visualization and measure frame rate (this
ties us to the real world). Second is to run a set of programs
that measure individual aspects of the graphics pipeline,
such as transformation rate (as a function of vertices/polygon),
fill rates, lighting rates, texture rates, along with
where the pipeline blocks. This give us a pretty good picture
of the display, and how we will need to generate code to
drive it. You've been reading too much sales literature. AGP
has no
effect on a wide range of graphics applications. The only
place its a big win is texture mapping. In all other cases
the geometry still has to go through the CPU, which is FSB
limited, no matter how fast the memory is.
Sure, but AGP is better than -no- AGP, and it does show that there are other
busses available on a PC, yes? (Which was my original point.)
Its interesting to note that SGI fell into the same
trap
that you did when they design their graphics PCs. They
put all sort of bandwidth in that thing, and then found
that the competition blew them away, one of the main
reasons SGI is in so much trouble now! They didn't
realize that the PC is FSB limited, and all the bandwidth
they had built in couldn't be used.
I know this. But, frankly, -every- bus is limited! Knowing how to "tune"
a system's architecture is partially what makes computers fascinating to me.
It's also one of the main reasons I enjoy looking at and studying these
old behemoths, even vaxes? ;-)
-mac
6:32 p.m.
Ah, to bad you
don't know what you're talking about here. I know of a
certain major corporation that just got done putting a whole pile of new
VAX 7000's in a brand new computer room. Said corporation has numerous
computer rooms with VAXen, and these systems are heavily used.
Maybe I should have said "Nobody -sane- is going to....". Speed
isn't everything.
You're right, speed isn't everything; it's the -only- thing! ;-) I'd rather
have a nice VAX than a modern PC,
you've also got to consider the fact that PC's aren't the most reliable of
platforms, and most run an OS that totally sucks!
My PCs are damn reliable; are you buying junk? They are -waaaaaaaaaaay- more
reliable than the VAX-11/780s, VAX-11/750s and VAX-11/785s that I have
used in the past. (I run BSDI unix on a Pentium Pro, as well as NetBSD on
other machines, and they have -never- crashed.) That's fascinating. Take obsolete hardware and
architecture (vax), and
keep them running! I guess I will never cease to be amazed at the weird
things people do. Heck, I heard the other day that people are -still-
running 1401 emulation mode under a VM/360 simulator on their modern h/w!
Let's see, on the VMS side, there is the question of reliability, you can't
get much more reliable than a VMS Cluster. But VMS runs on Alpha's you
say, well, not all apps have been ported.
Then there is the question of which costs less, keeping these systems
running, or converting to something new (this is both a hardware and
software quesiton). If the current system does everything you need, why
change? In some cases it makes sense to run old apps in an emulator on new
hardware.
Remember, I was just making the observation that the
integer performance of
the vax 8650 is worse than a dx2-66. I think single-user; I run single-user
machines. The future is single-user with vast network-accessed databases.
Well, that's one point of view. However, it's starting to look like the
trend is using those single-user systems as nothing more than intelligent
terminals (which is basically what you're saying).
What you failed to mention is that sgi is -only-
selling NT these days,
having given up on Big Iron.
And you've failed to stay current.
BUT, I would like the Vax Lover Crowd to acknowledge
that they integer
performance of their machine is pathetic.
Yes, but the 64-bit 21264 Alpha can beat any PC out there! If you need
speed you switch to Alpha, if you don't there is no reason not to stick
with VAX. BTW, I've got a letter I found today while cleaning up from
Compaq commiting to support the VAX hardware for a MINIMUM of 10 more years
through 2010. It's not like this is unsupported hardware.
Where the PC has it made is cost. For a few hundred dollars you can build
a pretty good, and fairly fast system, and load UNIX on it. It's hard to
beat that.
Zane
| Zane H. Healy | UNIX Systems Adminstrator |
| healyzh(a)aracnet.com (primary) | Linux Enthusiast |
| healyzh(a)holonet.net (alternate) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
8:46 p.m.
On Sun, 24 Oct 1999, Zane H. Healy wrote:
Let's put it this way, said corporations livelyhood DEPENDS on those
systems and thier stability and reliability.
Wow. I remain amazed.
Wrong, what counts is that the computer can do the job that it needs to.
That is why you'll still find systems such as the PDP-8 and PDP-11 still in
service. That is also why most people don't need anything more than a
68k-based Macintosh.
This is dead-wrong. You assume that "the job" remains static. But the
fact of the matter is, unless your computer is embedded in your microwave
or toaster, you'll want to run new and interesting s/w on it. And, in
general, that implies that you'll want a faster computer in 18 months.
That may indeed be true. Could you please enlighten me?
WAIT!!!!! WAIT!!!! I didn't say -anything- about Alphas! I just said,
let me repeat a fact:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ F A C T ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An Intel i486DX2/66 will run Dhrystone 2.1 2 to 3 times faster than a Vax 6500.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ F A C T ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now, as for Alphas: I want one! ;-)
Ah, to bad you don't know what you're talking
about here. I know of a
certain major corporation that just got done putting a whole pile of new
VAX 7000's in a brand new computer room. Said corporation has numerous
computer rooms with VAXen, and these systems are heavily used.
Maybe I should have said "Nobody -sane- is going to....". Speed isn't everything.
You're right, speed isn't everything; it's the -only- thing! ;-) I'll admit, with good hardware, and running UNIX,
or OS/2 you've got a
pretty reliable system. I think we'll see that reliability increase as
time passes and you start to see real clustering on PC's. If you want TRUE
reliability though you'll either go with one of Compaq's OpenVMS or Tandem
systems
Oh, hey, as my model says, PCs on the desktops, servers in the back rooms.
I want my servers to be 100% 24x7. I use PCs, but I do agree that there are
way better alternatives for backroom servers.
Then there is the question of which costs less,
keeping these systems
running, or converting to something new (this is both a hardware and
software quesiton). If the current system does everything you need, why
change? In some cases it makes sense to run old apps in an emulator on new
hardware.
If you're running some accounting application or airline reservations system,
sure, keep it the same until its lifetime expires. But, does it scale?
Can you load it more?
What you failed
to mention is that sgi is -only- selling NT these days,
having given up on Big Iron.
And you've failed to stay current. BUT, I would
like the Vax Lover Crowd to acknowledge that they integer
performance of their machine is pathetic.
Yes, but the 64-bit 21264 Alpha can beat any PC out there! with VAX. BTW, I've got a letter I found today
while cleaning up from
Compaq commiting to support the VAX hardware for a MINIMUM of 10 more years
through 2010. It's not like this is unsupported hardware.
It's gonna cost you!
Where the PC has it made is cost. For a few hundred
dollars you can build
a pretty good, and fairly fast system, and load UNIX on it. It's hard to
beat that.
Right about that!
But we love the old iron, right? That's why we're all here!
-mac
25 Oct
25 Oct
4:48 a.m.
Wrong, what
counts is that the computer can do the job that it needs to.
That is why you'll still find systems such as the PDP-8 and PDP-11 still in
service. That is also why most people don't need anything more than a
68k-based Macintosh.
This is dead-wrong. You assume that "the job" remains static. But the
fact of the matter is, unless your computer is embedded in your microwave
or toaster, you'll want to run new and interesting s/w on it. And, in
general, that implies that you'll want a faster computer in 18 months. If you're running some accounting application or
airline reservations system,
sure, keep it the same until its lifetime expires. But, does it scale?
Can you load it more?
To many depends there. Often the software does not scale. If it were vax
or as400 the answer is well known, yes.
An Intel i486DX2/66 will run Dhrystone 2.1 2 to 3
times faster than a Vax 6500.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ F A C T ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's still meaningless.
Now, as for Alphas: I want one! ;-)
Buy one, they run just a tad more than your average Xeon/500 with all the
bells... Of course you can get an antique one that is only 330mhz a lot
cheaper.
Allison
6:11 a.m.
Mike Cheponis wrote:
[stuff deleted]
*sighs* For a large dollar segment of the hardware marketplace this assertion
is simply not true. Finance applications in particular tend to run one and
only on thing on a machine or a small collection of machines; when you
run out of gas you buy a code compatable but bigger version of what you
were previously running on and repeat, praying that your vendor won't pull
the plug on your instruction set architecture and thus nuke your only
viable upgrade path.
This may not make much sense at first, but you need to understand that these
systems are mission critical and the people who use them are generally
risk adverse. Tell a trader that his trade support system will be down for
five minutes and he'll throw you out his window; as far as he (and his
employer) are concerned the world can change radically in that period of
time. The second factor has to do with the ability of these firms to
construct software, even software that simply replicates existing functionality
on a new platform. It largely doesn't exist, which is why individual
institutions can and have spent as much as $1billion (that's *one* bank) on
internal systems development and gotten *nothing* that worked as the return
on their investment. So against that backdrop a legacy architecture which
scales by installing larger and larger versions (or clusters, if the vendor
supports the notion) is quite common on the higher end of the marketplace.
[snip]
Of course.
[snip]
Wrong, what
counts is that the computer can do the job that it needs to.
That is why you'll still find systems such as the PDP-8 and PDP-11 still in
service. That is also why most people don't need anything more than a
68k-based Macintosh.
This is dead-wrong. You assume that "the job" remains static. But the
fact of the matter is, unless your computer is embedded in your microwave
or toaster, you'll want to run new and interesting s/w on it. And, in
general, that implies that you'll want a faster computer in 18 months. Then there is
the question of which costs less, keeping these systems
running, or converting to something new (this is both a hardware and
software quesiton). If the current system does everything you need, why
change? In some cases it makes sense to run old apps in an emulator on new
hardware.
If you're running some accounting application or airline reservations system,
sure, keep it the same until its lifetime expires. But, does it scale?
Can you load it more? WAIT!!!!! WAIT!!!! I didn't say -anything- about
Alphas! I just said,
let me repeat a fact:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ F A C T ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An Intel i486DX2/66 will run Dhrystone 2.1 2 to 3 times faster than a Vax 6500.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ F A C T ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Actually, what people are reacting to is the following:
On Sun, 24 Oct 1999 14:24:54 -0700 Mike Cheponis wrote:
Hey, I'm not saying the original IBM PC was going
to outperform the VAX 6500;
but a modern PC will crush any VAX in any application, IMHO, with equivalent
h/w attached.
PC isn't synonymous with Intel, when this statement was made it opened the
door to a discussion of machine architecture designed to show that the above
assertion was untrue.
Cheers,
Chris
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
8:24 a.m.
This is dead-wrong. You assume that "the
job" remains static. But the
fact of the matter is, unless your computer is embedded in your microwave
or toaster, you'll want to run new and interesting s/w on it. And, in
general, that implies that you'll want a faster computer in 18 months.
I am so glad this isn't true. This endless appetite for pain is NOT
universal. Many people don't give a rodents hind parts about new
applications, they really really really just want email and word processing.
Have you seen what a VooDoo3 card will do in an old P166? That is NOT
suffering, that is decent speed to play most games.
OS releases and a few games, with fewer still applications have exploded
into outrageous bloatware, and I hope it bites them in the rear but good
now that ram prices are making people pay twice for their upgrades. Windows
2k from all the reports I am reading is "hoping" for a 30% upgrade rate in
the first year. That is leading to a royally sucking situation, developers
need to be compatible with W2k, 98, 95 (and its two or three versions),
with a sprinkle of a couple NT releases, maybe W3.1, leaving only DOS out
in past. Dropping support for an existing application in windows 95 will be
a curious point for some time I think. All sorts of questions rise up about
tech support costs, erosion of user base, to staff continuity (non of the
original software people are still around to make OS specifc changes in 95
etc.).
9:53 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 3271 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991025/a065afe5/at…
24 Oct
24 Oct
6:46 p.m.
Jeeeezus.
On Sun, 24 Oct 1999, Mike Cheponis wrote:
That's fascinating. Take obsolete hardware and
architecture (vax), and
keep them running! I guess I will never cease to be amazed at the weird
Obsolete hardware? Are you aware that they're still being made? Systems
based on CURRENT technology, using CURRENT production techniques.
Keep in mind that the VAX isn't a computer...it's an architecture. There are
old implementations and new ones.
Now, you say "obsolete architecture"...Do you honestly believe that PCs are
"new" computers? That architecture was designed in 1980. And it wasn't
designed to be scalable. The VAX was designed only a couple of years earlier,
and it *was* designed to be scalable. That's why they're still around, still
in demand, still working hard in the face of constant marketing lies by Intel
and Microsoft.
What you failed to mention is that sgi is -only-
selling NT these days,
Wrong.
having given up on Big Iron. Also, the market sizes
for IBM, HP, and Sun's
"big iron" exist specifically to be those back-room servers that can do lots
of disk I/Os per second (the web, eh?).
...the back-room servers that you insist are obsolete, you mean?
BUT, I would like the Vax Lover Crowd to acknowledge
that they integer
performance of their machine is pathetic.
Old vaxen are slow. New vaxen are fast. C'mon, man. You're comparing
apples and oranges. Compare a current vax to a current PC.
I sure would like the PC lover crowd to admit to themselves that the PeeCee
isn't the end-all-be-all of computing. It's a cheap, slow, nonscalable, poorly
designed architecture that some little ass-kisser fresh out of college came up
with to impress his boss at IBM. GET OVER IT.
-Dave McGuire
9:32 p.m.
On Sun, 24 Oct 1999, Mike Cheponis wrote:
What are the current models? What are the current specs?
What new models are being designed? When will they be released?
That's fascinating. Take obsolete hardware
and architecture (vax), and
keep them running! I guess I will never cease to be amazed at the weird
Obsolete hardware? Are you aware that they're still being made? Systems
based on CURRENT technology, using CURRENT production techniques.
Keep in mind that the VAX isn't a computer...it's an architecture. There are
old implementations and new ones. Now, you say "obsolete architecture"...Do
you honestly believe that PCs are
"new" computers? That architecture was designed in 1980. And it wasn't
designed to be scalable. The VAX was designed only a couple of years earlier,
and it *was* designed to be scalable. That's why they're still around, still
in demand, still working hard in the face of constant marketing lies by Intel
and Microsoft.
Ahh, 32 bits is obsolete today. In case you hadn't noticed, even DEC figured
that out, and did the Alpha.
FACT: VAX is at end of life.
What you failed
to mention is that sgi is -only- selling NT these days,
Wrong. having given up
on Big Iron. Also, the market sizes for IBM, HP, and Sun's
"big iron" exist specifically to be those back-room servers that can do lots
of disk I/Os per second (the web, eh?).
...the back-room servers that you insist are obsolete, you mean? BUT, I would
like the Vax Lover Crowd to acknowledge that they integer
performance of their machine is pathetic.
Old vaxen are slow. New vaxen are fast. C'mon, man. You're comparing
apples and oranges. Compare a current vax to a current PC.
I sure would like the PC lover crowd to admit to themselves that the PeeCee
isn't the end-all-be-all of computing. It's a cheap, slow, nonscalable, poorly
designed architecture that some little ass-kisser fresh out of college came up
with to impress his boss at IBM. GET OVER IT.
Excuuuuuuuuuuuuuse me! In case you hadn't noticed, there are more PCs than
every other type of computer ever made, ever! Did you notice this?
FACT: And it wasn't designed by some little ass-kisser fresh out of college; it
was designed by Intel.
-Dave McGuire
-mac
p.s. Is it common on this group for people to ignore the FACTS? Do FACTS
matter, or is this a group where there are opinions and commonly-shared
versions of reality, where facts are unimportant?
9:44 p.m.
This is the last of these that I will entertain. You're a flame-baiter, and
while this has been fun, it's trashing the s/n ratio of the list rather badly.
The facts remain, and as long as people keep paying me for my advice, I'll
stick to what I've learned is the right path to take...in spite of Intel's
marketing department's best efforts.
On Mon, 25 Oct 1999, Mike Cheponis wrote:
What? Do you even understand the significance of data path width? You just
said that numbers between 0 and 2^32 are obsolete. That's just plain silly.
How many spreadsheets do YOU recalculate that require numbers larger than
4294967296? Do you really write code that handles so much in-core data that it
requires larger than a 32-bit pointer?
64-bit processors are *different*. Better in some ways, but worse in others.
Something does not magically become "obsolete" as soon as something new is
introduced. Do you take your 1998 car to the dump as soon as the 1999 cars
come out? Sure, the 1999 cars might be better in one way or another...progress
is inevitable. But do you take that 1998 care to the dump or not? It's really
no different.
Enlighten me, please. If I'm wrong, let me know. But simply calling me
wrong without enlightening me is rude, IMHO.
Irix is still supported and in development, as is Unicos. Neither of them
will be going away anytime soon, mostly due to pressure from the US government
and several very large customers. Something about "vital to national
security". Guess they figured out that PCs can't do *everything*, huh?
Eeek, I guess I misunderstood you there...sorry...
What are the current models? What are the current
specs?
What new models are being designed? When will they be released?
Look at their web server.
Now, you say
"obsolete architecture"...Do you honestly believe that PCs are
"new" computers? That architecture was designed in 1980. And it wasn't
designed to be scalable. The VAX was designed only a couple of years earlier,
and it *was* designed to be scalable. That's why they're still around, still
in demand, still working hard in the face of constant marketing lies by Intel
and Microsoft.
Ahh, 32 bits is obsolete today. In case you hadn't noticed, even DEC figured
that out, and did the Alpha. FACT: VAX is at end of life.
If you're a salesman, maybe. I'm not a salesman. I don't base my
"obsolete"
or "useless" judgements on the marketing decisions of vendors.
What you failed to mention is that sgi is -only-
selling NT these days,
Wrong. ...the
back-room servers that you insist are obsolete, you mean?
I -never- insisted the back-room servers were obsolete. Gee, I wish people
would actually carefully read and then respond, rather than getting all
worked up and then to respond to something that's not even claimed! Excuuuuuuuuuuuuuse me! In case you hadn't noticed,
there are more PCs than
every other type of computer ever made, ever! Did you notice this?
And I guess in your eyes that makes them GOOD, right?
People don't buy PCs because they're well-designed. They don't buy them
because they're fast. Nor do they buy them because they're the right tool for
the job, or because they do anything particularly well. They buy them because
they're conditioned to believe that _that's what they're supposed to do_.
FACT: And it wasn't designed by some little
ass-kisser fresh out of college; it
was designed by Intel.
Oh, sorry. A WHOLE FUCKING COMPANY full of ass-kissers fresh out of
college. I stand corrected.
-Dave
9:57 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2819 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991025/a0ee8eb3/at…
10:37 p.m.
A dx2/66
running Dhrystone 2.1 will be 2 to 3 times faster than an 6500.
So? My roommate's 200MHz Pentium will blow my 7.1MHz 68000 based Amiga
out of the water, yet my Amiga still feels quicker, even though they have
the same capabilities (okay, the Pentium has a better sound system and
graphics sub-system than the Amiga, yet it took the PCompatible over 10
years to match capabilities and it still feels a bit sluggish at times). So, a 486DX2/66 will beat a VAX 6500 in integer
math. Great, if all I'm
doing is integer math. Do an I/O benchmark and I'm sure a VAX 11/780 will
beat the 486DX2/66 no problem.
See? There you go again! The 780's I/O was no great shakes. Sure, you
could stuff on a Fujitsu Eagle and do -pretty- good, but it was definitely
no speed demon. Since a dx2/66 is around 20 to 30x the integer performance
of that 11/780, I'm pretty sure the Intel part would crush an 11/780 in any
benchmark you could name. Of course, the 486 came out in 1989, and the
11/780 came out in, what, 1979. And, I don't have data on the 11/780's I/O
channels, so I can't be positive.
Excuuuuuuuuuuuuuse me! In case you hadn't noticed, there are more PCs than
every other type of computer ever made, ever! Did you notice this?
I wouldn't go that far---as a general purpose computer, yes, it is
probably the most numerous. Most numerous of ALL computers? I doubt it.
More people probably have microwaves than computers. Or VCRs. FACT: And it wasn't designed by some little
ass-kisser fresh out of college; it
was designed by Intel.
Sigh. What do they teach in school these days? -spc (I've seen the building where the PC was
designed---when I saw it, it
was an art museum)
-mac
25 Oct
25 Oct
6:39 a.m.
Mike Cheponis wrote:
[snip]
You've been talking about PCs as machines and x86 processors interchangably,
so you'll understand our confusion.
See? There you go again! The 780's I/O was no
great shakes. Sure, you
could stuff on a Fujitsu Eagle and do -pretty- good, but it was definitely
no speed demon. Since a dx2/66 is around 20 to 30x the integer performance
of that 11/780, I'm pretty sure the Intel part would crush an 11/780 in any
benchmark you could name.
I note that we've ratched down from "any vax" to "11/780". TPC-C
comes to mind...
[snip]
Sigh. What do
they teach in school these days?
It's a matter of understanding what "it" refers to. I took it to refer to
the dx2/66 or its predecessors. They were built by Intel.
IBM merely glued a pile of Intel chips together and put 'em in a box.
Where "glued the chips together" means "designed (although I use the term
loosely) the memory and I/O architecture".
Cheers,
Chris
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
7:10 a.m.
On Mon, 25 Oct 1999, Chris Kennedy wrote:
C'mon! IBM did essentially nothing but run wires between Intel's chips.
Mike Cheponis wrote:
> See? There you go again! The 780's I/O was
no great shakes. Sure, you
> could stuff on a Fujitsu Eagle and do -pretty- good, but it was definitely
> no speed demon. Since a dx2/66 is around 20 to 30x the integer performance
> of that 11/780, I'm pretty sure the Intel part would crush an 11/780 in any
> benchmark you could name.
I note that we've ratched down from "any
vax" to "11/780". TPC-C comes to mind...
Chris, PAY ATTENTION: READ MY LIPS! -I- was not the one who made the
initial comparison of dx2/66 to a 780. I -continue- to assert (until data
proves me otherwise, and getting data on obsolete machines like VAX 6500 is
apparently next to impossible or non-existent) that the dx2/66 will kick
serious VAX 6500 butt, too, -with equivalent h/w- . You -do- remember me
saying that, right?
The POINT is that the busses and performance of "modern" (that is, >1989)
PCs
are BETTER than the 6500, AND that modern PCs leave EVERY VAX ever made in
the dust.
Why is reality so hard for some people here to comprehend?
Look, I like old junk, too; that's why we gather here.
But it is old, tired, worn-out, obsolete junk!
I think it's fascinating that people wish to keep old PDP-9s going if
possible, 'cause their application is operationally equivalent to an
embedded processor. Great for History Lessons, I guess.
But, for me, trusting a Mission Critical application on a PDP-9 today is
business suicide.
> It's a matter of understanding what
"it" refers to. I took it to refer to
> the dx2/66 or its predecessors. They were built by Intel.
You've been talking about PCs as machines and x86
processors interchangably,
so you'll understand our confusion.
I didn't make the initial comparison, mind you. As for me, PC and x86
processors -are- essentially equivalent in this context, and any distinction
is merely pedantic.
IBM merely
glued a pile of Intel chips together and put 'em in a box.
Where "glued the chips together" means "designed (although I use the term
loosely) the memory and I/O architecture". Cheers,
Chris
-mac
p.s. Folks, help me out here: Try to actually -read- what I say, and perhaps
even quote it (In context, please!) and -then- open up your flamethrowers
and have at it. I especially appreciate thoughtul comments that prove
that I'm wrong, and show me what's right.
But I'm getting a little tired of defending things I did't say or assert.
Also, please, no public name-calling. Send me private email if you
want to call me names.
Thanks, all!
7:49 a.m.
Chris, PAY ATTENTION: READ MY LIPS! -I- was not the
one who made the
initial comparison of dx2/66 to a 780. I -continue- to assert (until
data proves me otherwise, and getting data on obsolete machines like
VAX 6500 is apparently next to impossible or non-existent) that the
dx2/66 will kick serious VAX 6500 butt, too, -with equivalent h/w- .
You -do- remember me saying that, right?
All this ranting has been mildly amusing but is now quickly headed
into the annoying category. Seeing's how this is the "Classic
Computing List" and that various members of the list actually own
the hardware in question, why don't we put our money where our
mouths are and actually come up with a "Shootout". First we
come up with the ground rules (general hardware configs, various
application test cases, etc). If we could find the approriate VAX
hardware somewhere near the next VCF, then we could use the
VCF crowd itself to act as our load and it would make for a cool
and actually on topic demonstration. Of course this doesn't have
to be limited to VAXen or 486/66's, actually having a "modern" pc
as comparision would also be interesting. And if someone has
another favorite example of early big iron, that could also be used.
So how about it, let's stop blowing air and let's start actually doing
something.
George
8:58 a.m.
"George Currie" <g(a)kurico.com> wrote:
All this ranting has been mildly amusing but is now
quickly headed
into the annoying category.
I agree. This suggests a new addition to the ClassicCmp FAQ:
Q: Should I post verifiable, factual statements about old computers?
A: For God's sake, no! Doing so will lead to huge flame wars. Please
stick to opinions only.
8:12 a.m.
Mike Cheponis wrote:
That's fair, but for others of us the term "PC" implies a certain family of
I/O architectures. I don't consider a Sequent to be a PC, despite the fact
that they use the same processors.
C'mon! IBM did essentially nothing but run wires between Intel's chips.
I'm the last guy to defend IBM's architecture for the PC, but IMHO there's
slightly more there than just laying out something from Intel data sheets.
Maybe we should move on?
Best,
Chris
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
Chris, PAY ATTENTION: READ MY LIPS! -I- was not the
one who made the
initial comparison of dx2/66 to a 780. I -continue- to assert (until data
proves me otherwise, and getting data on obsolete machines like VAX 6500 is
apparently next to impossible or non-existent) that the dx2/66 will kick
serious VAX 6500 butt, too, -with equivalent h/w- . You -do- remember me
saying that, right?
Close. The quote I've found by dredging through the messages is the one
I quoted earlier:
Hey, I'm not saying the original IBM PC was going
to outperform the VAX 6500;
but a modern PC will crush any VAX in any application, IMHO, with equivalent
h/w attached.
That's not quite an assertion about the dx2/66; in fact it's not quite an
assertion about the x86 in general. Sure, we can postulate a 486dx2 machine
with a bunch of buses and channel processors, but that's not what was being
asserted above.
The POINT is that the busses and performance of
"modern" (that is, >1989) PCs
are BETTER than the 6500, AND that modern PCs leave EVERY VAX ever made in
the dust.
Perhaps. I'm not terribly familiar with Vaxen, but in general a machine with
a single high performance bus yeilds inferior performance in data intensive
applications in comparison with machines equipped with multiple buses.
Contention sucks.
Why is reality so hard for some people here to
comprehend?
Speaking only for myself, it's because the assertions keep changing.
Look, I like old junk, too; that's why we gather
here.
But it is old, tired, worn-out, obsolete junk!
A great deal of it, yes. I don't believe that's what people are reacting to;
while there may be a few it's not my sense that people are reacting to
your statements out of some emotional attachment to Vaxen or a physical
revulsion to x86 machines.
I think it's fascinating that people wish to keep
old PDP-9s going if
possible, 'cause their application is operationally equivalent to an
embedded processor. Great for History Lessons, I guess.
But, for me, trusting a Mission Critical application on a PDP-9 today is
business suicide.
I'd generally agree, but until something better and proven comes along you're
kinda stuck. I'm hardly thrilled with the computing technology behind the
enroute air traffic control system, but it's proving to be a bitch to
replace. The same holds for certain systems in other industries. It sucks,
but it is what it is.
> It's
a matter of understanding what "it" refers to. I took it to refer to
> the dx2/66 or its predecessors. They were built by Intel.
You've been talking about PCs as machines and
x86 processors interchangably,
so you'll understand our confusion.
I didn't make the initial comparison, mind you. As for me, PC and x86
processors -are- essentially equivalent in this context, and any distinction
is merely pedantic. IBM merely glued a pile of Intel chips together and
put 'em in a box.
Where "glued the chips together" means "designed (although I use the term
loosely) the memory and I/O architecture".
9:03 a.m.
Chris Kennedy <chris(a)mainecoon.com> wrote:
I'm the last guy to defend IBM's architecture
for the PC, but IMHO there's
slightly more there than just laying out something from Intel data sheets.
Get out the schematics of the original 5150 PC and study them. You'll
realize that what IBM did was copy the 8088 application notes, and then
screw things up at nearly every opportunity.
The only detailss of the 5150 that don't fall right out of the application
notes are
1) The way that the 8259 interrupt controller is used: IBM botch this
severely.
2) The actual pinout of the bus connectors.
3) The keyboard and cassette interfaces.
When I hear people talking about the way the IBM PC was "designed" (or,
worse yet, "architected"), it makes me cringe.
However, given that it was a skunkworks project on a tight schedule,
with no intention of setting a standard that would be used by hundreds
of millions of systems in the future, I can't really blame them.
11:57 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 2310 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991025/8fddc154/at…
7:54 p.m.
Tony Duell wrote:
All of the Intel ap notes I've read recommend either active-low level
sensitive, or falling-edge sensitive. Sure, you can set the bits to the
other two modes, but nowhere does Intel suggest that it's a good idea.
I don't recall an Intel app note showing the DMA
'extension' registers,
to get the 8237 to work with the 8088. Most likely Intel would have been
pushing the 8089 (even though it wasn't out in time...)
Too expensive. IBM couldn't put expensive chips in it, even if they
were available. So they did a quick hack to add the register. Maybe
that detail isn't direct from an Intel ap note, but it's not exactly
rocket science either.
The RAM timing, etc looks decidedly non-intel as well.
Intel had RAM
controller chips IIRC. IBM used TTL and a delay line.
Intel had a cheap DRAM controller that wasn't good enough, and a good
enough one that wasn't cheap. DRAM controllers using TTL and delay lines
were certainly common enough elsewhere. Again, this isn't really a
sign of any ingenuity on IBM's part.
Maybe every detail of the schematic wasn't pulled from Intel ap notes,
but a pertty significant portion was.
The peripheral cards are not Intel at all.
Nor did anyone claim they were.
If the IBM engineers had designed more of the cards earlier on, they
wouldn't have put such a crappy bus design, particularly with regard
to the interrupt control.
1) The way
that the 8259 interrupt controller is used: IBM botch this
severely.
Hmm... Well, the active high edge triggering doesn't help ;-). But that's
an Intel documented mode for the chip. In what other ways did IBM botch
this. IMHO the 8259 is used almost as Intel would have done.
26 Oct
26 Oct
10:12 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 5007 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991026/2d84e717/at…
3:09 p.m.
At 08:12 PM 10/26/99 +0100, Tony allegedly wrote:
_You're_ the one claiming that the PC was
essentially an Intel design.
But IMHO, apart from trivial/standard sections, it wasn't.
Having worked at Intel just after 1981 (Jan '84) and knowing how "app
notes" got written, it is entirely possible that some FE wrote the app note
while looking at the IBM PC TechRef book! The app note for the 82786
(graphics chip) was written based on the design that Number-9 got working.
--Chuck
3:56 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1360 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991027/a2ee00d1/at…
3:26 p.m.
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
But equally, I wonder why Intel made it active high
in the first place.
-tony
Hi
I would suspect that it was not intended to be tied
directly to a bus. One would normally have some robust
receiver that would invert the signal. In the days when
it was designed, the 0 to 2.5V TTL bus was just starting
out. Many had other voltage ranges and required some
conditioning. The simplest conditioning circuits usually
had an inverted signal out.
Dwight
4:04 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 944 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991027/398e94cc/at…
4:53 p.m.
I would suspect that it was not intended to be tied
directly to a bus. One would normally have some robust
receiver that would invert the signal. In the days when
it was designed, the 0 to 2.5V TTL bus was just starting
out. Many had other voltage ranges and required some
conditioning. The simplest conditioning circuits usually
had an inverted signal out.
Dwight
Ah, not even close. TTL voltages on busses were old hat by then. The
intent was to NOT connect 8259 inputs directly on busses as they are MOS
devices and susceptable to damage. The expectation was at minimum an
inverter ahead of the input.
Also, many of the intel devices had interrupt pins that went active high.
That or maybe they ran out of room on the die for an inverter.
Allison
8:35 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 3671 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991025/a69f2d93/at…
8:18 p.m.
On Mon, 25 Oct 1999, Zane H. Healy wrote:
See http://anacin.nsc.vcu.edu/~jim/mvax/vax-perf.html
for a full list which
Thanks, that's a lovely resource!
---- Mariah chip series(1991) - Decimal SID =
301989888--------+------------
12 | 2 | 1202|13-58 | XBCD | VAX 6000 model 510-560 |Calypso/XMP
So, the VAX 6000 in question is somewhere between 13-58 times as fast as a
VAX 11/780.
Zane, if you know, how can a single processor have a 4.5 to 1 ratio on
performance? The DEC document at http://www.digital.com/timeline/1990-4.htm
says the 6500 was 13x a 780.
If so, then if people were thinking of a 58 MIPS 6500, this -certainly-
explains the performance difference. Heck, a 58 MIPS 6500 is even faster
than a 486DX4/100 !!!
Personally I'd LOVE to have a fully loaded
VAXstation 4000/90A (one of these
days I need to get some RAM for my VS4000/90). I find that for a single
user system a VAX in the 2-3 VUP's range is quite nice. Something in the
30+ VUP's range has got to be Awsome :^) Of course if I do ever get a
VS4000 working it will be in the cluster with my AlphaStation 500/333 and
various lesser systems :^) Yes, I realize that the AS500 is far faster than
any of the VAXen I've got.
You know, I'd love to experience something like a 6500 or some other fast
vax. It' be fun to "feel" it compared with modern junk.
Tnx again, nice pointer.
-mac
9:13 p.m.
On Mon, 25 Oct 1999, Zane H. Healy wrote:
OK I think you're refering to the 13-58 number above. I believe that
refers to a 6000/510 (single processor) running at 13 VUPs, up to a
6000/560 (six processor) running at 58 VUPS. So the system in question
should be ~35 VUPS if I figure correctly.
See
http://anacin.nsc.vcu.edu/~jim/mvax/vax-perf.html for a full list which
Thanks, that's a lovely resource!
---- Mariah chip series(1991) - Decimal SID =
301989888--------+------------
12 | 2 | 1202|13-58 | XBCD | VAX 6000 model 510-560
|Calypso/XMP
So, the VAX 6000 in question is somewhere between 13-58 times as fast as a
VAX 11/780.
Zane, if you know, how can a single processor have a 4.5 to 1 ratio on
performance? The DEC document at http://www.digital.com/timeline/1990-4.htm
says the 6500 was 13x a 780. If so, then if people were thinking of a 58 MIPS 6500,
this -certainly-
explains the performance difference. Heck, a 58 MIPS 6500 is even faster
than a 486DX4/100 !!!
BUT, it's NOT MIPS, it is VUPS. I don't have info on what all VUPs
measures but IIRC, it's more than just processor speed. To make matters
worse, the baseline for VUPS, SPECint92, and SPECfp92 is the VAX-11/780,
and as such a VAX-11/780 has a score of 1.0 on all three of those tests.
Of course the only SPECint/fp92 tables I can come up with don't list many
VAXen. It does list the 6000/510 though at ??? SPECint92, and 13.3
SPECfp92.
Trying to compare benchmarks is a real headache, you can get some machines
under one type of benchmark, and some more under another type, etc. While
there is a little overlap, there isn't enough.
Zane
| Zane H. Healy | UNIX Systems Adminstrator |
| healyzh(a)aracnet.com (primary) | Linux Enthusiast |
| healyzh(a)holonet.net (alternate) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
8:07 a.m.
Chris Kennedy wrote:
Mike Cheponis wrote:
[snip]
Mike: you wanted numbers.
The 11/780 is one machine on which I do have a few recently acquired
docs. In page 2-2
of the 1977-78 VAX 11/780 architecture handbook there is a nice figure
of the cpu and
different interconnects. Basically, the cpu, main memory and I/O
subsystems were tied to
the Synchronous Backplane Interconnect (SBI), 13.3 MB/s, cycling at
200ns.
The console was attached to the CPU directly thorugh a separate channel.
Any device could request control of the SBI and control was granted
using a priority
scheme. The I/O subsystem could hold one unibus adaptor (1.5 MB/s) and
up to four
massbus adaptors (2MB/s each). The cpu had 8KB of two-way
set-associative write-through
cache (and the instruction set allowed for generation of very compact
code). The cache
monitored I/O <=> main memory transfers and updated accordingly.
Given this architecture, I think that there is reason to assume that an
11/780 might
service 100 users over serial lines faster than any 486-66 PC . Just
think of the interrupt
service overhead of 100 users typing simultaneously, even with 16 byte
FIFO buffers.
By the way, this little book is great reading... It really puts things
in perspective
to see the great 11/780 implementation 22 years ago...
Carlos.
--
Carlos Murillo-Sanchez email: cem14(a)cornell.edu
428 Phillips Hall, Electrical Engineering Department
Cornell University, Ithaca, NY 14853
See? There you go again! The 780's I/O was
no great shakes. Sure, you
could stuff on a Fujitsu Eagle and do -pretty- good, but it was definitely
no speed demon. Since a dx2/66 is around 20 to 30x the integer performance
of that 11/780, I'm pretty sure the Intel part would crush an 11/780 in any
benchmark you could name.
I note that we've ratched down from "any vax" to "11/780". TPC-C
comes to mind...
3:02 p.m.
On Mon, 25 Oct 1999, Carlos Murillo-Sanchez wrote:
Mike: you wanted numbers.
The 11/780 is one machine on which I do have a few recently acquired
docs. In page 2-2 of the 1977-78 VAX 11/780 architecture handbook there
is a nice figure of the cpu and different interconnects. Basically, the
cpu, main memory and I/O subsystems were tied to the Synchronous
Backplane Interconnect (SBI), 13.3 MB/s, cycling at 200ns.
Great! Numbers! Thanks, Carlos. OK, SBI = 106 Mbits/sec.
For comparison, the 486's Main Bus runs at 848 Mbits/sec [1]. That's 8 times
as fast as the 11/780 SBI bus.
The console
was attached to the CPU directly thorugh a separate channel. Any device
could request control of the SBI and control was granted using a priority
scheme. The I/O subsystem could hold one unibus adaptor (1.5 MB/s) and
up to four massbus adaptors (2MB/s each).
Unibus = 12 Mb/s (Coincidentally, USB is -also- 12 Mb/s ...)
Massbuss = 16 Mb/s each.
(For a rough comparison, the 64-bit 66 MHz PCI bus is over 4 Gbits/sec; so
that particular modern PC bus has 57 times more bandwidth than a Unibus
and four Massbus adaptors, combined!)
The cpu had 8KB of two-way
set-associative write-through cache (and the instruction set allowed for
generation of very compact code). The cache monitored I/O <=main memory
transfers and updated accordingly.
The 486 also has 8K of cache, and is approximately 30 times as fast as the
11/780 running the Dhrystone 2.1 benchmark.
Given this architecture, I think that there is reason
to assume that an
11/780 might service 100 users over serial lines faster than any 486-66
PC . Just think of the interrupt service overhead of 100 users typing
simultaneously, even with 16 byte FIFO buffers.
Well, let's see. The ISA16 bus runs at 8.33 MHz, 4 clocks, 16 bits per
cycle. That's only 33.3 Mb/s, comparable to a Unibus plus a Massbus.
(And, of course, most 486dx2/66 machines used at least an EISA bus [2],
running 32 bits at 8.33 MHz x two clock edges = 533 Mbits/sec.)
So if we are able to plug multiport intelligent serial cards into our EISA
bus, and to use a standard EISA SCSI controller, the numbers say that the
dx2/66 would crush the 11/780 by a factor of at least 5 (which is
533 Mb/s / 106 Mb/s) or perhaps as much as 30, depending on the task.
By the way, this little book is great reading... It
really puts things
in perspective to see the great 11/780 implementation 22 years ago...
I remember the book well; I wish I still had my copy!
Carlos.
Thanks again, -Mike
[1] Intel i486 Microprocessor Manual, Page 1. Doc #240440-002 November 1989
[2] Indispensable PC Hardware Book, 3rd edition, p. 552
6:22 a.m.
Mike Cheponis wrote:
[stuff deleted]
FACT: And it wasn't designed by some little
ass-kisser fresh out of college; it
was designed by Intel.
That's gonna come as a hell of a shock to the boys from Boca. Intel is responsible
for the processor, not the PC nor the architecture of the PC. There's a hell of
a difference.
p.s. Is it common on this group for people to ignore
the FACTS? Do FACTS
matter, or is this a group where there are opinions and commonly-shared
versions of reality, where facts are unimportant?
*ROFL* You're kidding, right? You can't distinguish between a PC and it's
processor and accuse others of ignoring facts??
Best,
Chris
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
7:14 a.m.
Mike,
Excuuuuuuuuuuuuuse me! In case you hadn't
noticed, there are more PCs
than every other type of computer ever made, ever! Did you notice this?
Oh come on, since when has quantity been any measure of QUALITY? The black
death was rather popular in the middle ages too you know....
There is one major reason that the PC is so popular, despite being such a
lousy, unreliable system (and before you harp on again about how reliable YOUR
PC is try supporting a site with 400+ PCs on it. You'll soon change your
opinion of the reliability of these machines). Remember the old adage from the
'70s and early '80s "Nobody was ever fired for buying IBM", that's
why PCs are
so popular today....they made it into countless companies around the world and
thus filtered down into the homes of the workers when they wanted their own
machines (usually to run software they'd swapped with their colleagues at
work).
The expandability factor helped a lot too, but if not for the PC's popularity
in the workplace it would've gone the same way as the Apple ][, S100 based
machines etc.
TTFN - Pete.
--
Hardware & Software Engineer. Sound Engineer.
Collector of Arcade Machines, Games Consoles & Obsolete Computers (esp DEC)
peter.pachla(a)wintermute.org.uk |
peter.pachla(a)vectrex.freeserve.co.uk |
peter.pachla(a)virgin.net |
peter.pachla(a)wintermute.free-online.co.uk | www.wintermute.free-online.co.uk
--
24 Oct
24 Oct
10:52 p.m.
Mike wrote (about VAX 7000 systems):
That's fascinating. Take obsolete hardware and
architecture (vax), and
keep them running! I guess I will never cease to be amazed at the weird
Dave McGuire <mcguire(a)neurotica.com> replied:
Obsolete hardware? Are you aware that they're
still being made? Systems
based on CURRENT technology, using CURRENT production techniques.
False. It's neither current technology nor current production techniques.
DEC hasn't developed a new VAX chip since the NVAX+ in 1992. It's seven
years out of date already.
Of course, that doesn't mean that it isn't still useful. But it's a
legacy system, not state of the art.
8:19 p.m.
Mark Green wrote:
>Mike Cheponis wrote:
>>Looks like the 6500 was about 13 VAX-11/780 MIPS. That would make it about
>>2x to 3x slower than a 486DX2/66.
You've got to be kidding!!! Most
VAXes out there are running large
multiuser systems. The VAX has not been out of production for
very long, and there are still a considerable number of systems
that are running on them. If you meant it in terms of dozens of
users being too small, I might agree. Many of these systems are
running more like hundreds of users. >Now, perhaps if we were to port Apache to the
VAX, and used that I/O bandwidth
>on multiple DS3s, well, that's great.
The problems is equivalent hardware. You
can't configure a PC
like a VAX, they are two different types of machines. A PC
is tuned for a single user, while a VAX is tuned for many users.
Amen! Thank you!
I think all the flamage back and forth needs to accept this, and I think
Chuck first brought it up. That's right!
Remember, I was just making the observation that the integer performance of
the vax 8650 is worse than a dx2-66. I think single-user; I run single-user
machines. The future is single-user with vast network-accessed databases. These are very different machine configurations,
and even the latest
PC would have no hope of keeping up to a decade old VAX running
a large multiuser application.
Again, with -equivalent hardware- it certainly would.
Many of the PC manufacturers
have tried to scale PCs to this level and they have all failed.
This is why companies like IBM, HP, SUN and SGI are still selling
big iron, and sales are increasing rapidly. There is a huge
demand for server style systems, and single bus systems like
the PC can't scale to the performance required.
What you failed to mention is that sgi is -only- selling NT these days,
having given up on Big Iron. Also, the market sizes for IBM, HP, and Sun's
"big iron" exist specifically to be those back-room servers that can do lots
of disk I/Os per second (the web, eh?).
I fully agree that computer systems designed for specific purposes are
going to do better for those applications than a PC.
BUT, I would like the Vax Lover Crowd to acknowledge that they integer
performance of their machine is pathetic.
No one in this group ever said it was good. As I said above
the reaction was to your comment about PCs always being better
than a VAX regardless of application.
Its not the speed
of the individual bus, but its the number of busses.
That's of course bull..... The more busses, the more parallelism and the less
waiting.
-IF- the speed of the busses is high enough!
One
fast bus works well until you want to do multiple things, and
then it quickly becomes a bottleneck.
Excuse me? Could you please back up this assertion with data? After all,
at -some- point, all these busses have to get their data into/out of the CPU,
right? And -that- is a "bottleneck" for sure... (Sure, you can have
channel-to-channel I/O, but most aps are not just shuffling bits.)
And, if
you don't like Dhyrstone 2.1, then what benchmarks -can- we use?
Each application area has their own set of benchmarks that
reflect their use of the machine. For example, a lot of the
supercomputer centers use fluid dynamics programs to evaluate
machines, since that's what takes up most of their cycles. We
take a two pronged approach to graphics performance. One is
to run some standard visualization and measure frame rate (this
ties us to the real world). Second is to run a set of programs
that measure individual aspects of the graphics pipeline,
such as transformation rate (as a function of vertices/polygon),
fill rates, lighting rates, texture rates, along with
where the pipeline blocks. This give us a pretty good picture
of the display, and how we will need to generate code to
drive it.
That's the beauty (and downfall?) of benchmarks like Dhrystone 2.1 - it can
be run on most any piece of computer h/w every designed.
Yes, and the results are typically meaningless. Benchmarking
is really hard, and typically the more general the benchmark
the more useless it is. Here's a little example. Several
years ago we went to two companies to evaluate their high
end machines. According to the specs and benchmarks Machine A
was the clear winner, at least 3x faster than Machine B. When
we actually ran our programs we found that Machine B was
consistently 2 or 3x faster than Machine A. This was a pretty
wide range of applications. There are several reasons why
this happened. One was that Machine B had much better compiler
technology. The other was that the specs and benchmarks didn't
tell the real story, how the machine really performed. Its
easy to tune a machine to look good on standard benchmarks,
but it may not run anything else at near that speed.
You've been reading too much sales literature.
AGP has no
effect on a wide range of graphics applications. The only
place its a big win is texture mapping. In all other cases
the geometry still has to go through the CPU, which is FSB
limited, no matter how fast the memory is.
Sure, but AGP is better than -no- AGP, and it does show that there are other
busses available on a PC, yes? (Which was my original point.)
Its interesting to note that SGI fell into the
same trap
that you did when they design their graphics PCs. They
put all sort of bandwidth in that thing, and then found
that the competition blew them away, one of the main
reasons SGI is in so much trouble now! They didn't
realize that the PC is FSB limited, and all the bandwidth
they had built in couldn't be used.
I know this. But, frankly, -every- bus is limited! Knowing how to "tune"
a system's architecture is partially what makes computers fascinating to me.
It's also one of the main reasons I enjoy looking at and studying these
old behemoths, even vaxes? ;-)
11:24 p.m.
That's
fascinating. Take obsolete hardware and architecture (vax), and
keep them running! I guess I will never cease to be amazed at the weird
Here's the clue to understanding it: software and business logic. I do believe at one point you stated that a dx2-66
could beat a
VAX 8650 on any application (I don't think these are your exact
words, something like crushing one). This is what people are
reacting to, I don't think anyone is arguing about the difference
in integer performance.
Thanks for helping me understand. I certainly believe the dx2/66 would
make the 8650 cringe on any app, but I'd want to collect all the data on
the 8650 (or 6500, for that matter) that would completely describe the I/O
busses, memory busses, etc before I'd say for -certain- that the dx2/66
would kick old vax butt.
> >These are very different machine
configurations, and even the latest
> >PC would have no hope of keeping up to a decade old VAX running
> >a large multiuser application.
I don't believe this.
SGI is not selling any NT at this point, and its not
clear that
they ever sold very much. The NT experiment at SGI is over, and
there are attempts to sell off what they can of it. SGI has
gone back to building big servers, and Unix/Linux based ones.
They realized that they weren't going to be able to scale
an NT solution, and their strength was in scaling.
Yeah, this is an interesting gamble for sgi. Microsoft, of course,
heavily believes in Win2k, including its scalability. In fact, I think
W2K is going to do very well, as it is really pretty nice (I hate saying
that, but, again, I'm trying to call 'em like I see 'em...).
BUT, I would
like the Vax Lover Crowd to acknowledge that they integer
performance of their machine is pathetic.
No one in this group ever said it was good. As I said above
the reaction was to your comment about PCs always being better
than a VAX regardless of application. Its not the speed
of the individual bus, but its the number of busses.
That's of course bull..... > >The more busses, the more parallelism and the
less waiting.
>
> -IF- the speed of the busses is high enough!
This is a really simple point here. If I have 10 busses and each one
runs at 1 megabit, is that any better than my one bus that runs at 100 Mb/s ?
That's the only little point I was trying to make. (Like the point that
you can bolt 16 VAX "CI" busses onto a modern PCI bus, and still have
leftover bus cycles.)
>>One
>>fast bus works well until you want to do multiple things, and
>>then it quickly becomes a bottleneck.
>
>Excuse me? Could you please back up this assertion with data? After all,
Which CPU? If I have a high end system I will be
running multiple CPUs.
Yikes! Now we've jumped to Multiple CPUs! Yow!
That's a Whole Different Ballgame!
I've been reading Pfister's "In Search of Clusters" and I gotta say
I'm
coming to the conclusion that uni-processors tied into loose clusters
gives the best bang for the buck (in all vectors: reliabilty, scaleability,
etc.).
I agree about the problem of getting the data into
the
CPU, and as I pointed out this is the weak point of PC based
systems. Everything goes into the CPU over a single bus, which
has had problems keeping up with processor speed. Look at how
many times Intel has changed the speed of the FSB over the past
year or so.
Sure. And look how much bigger L1 cache is getting, and why more and more
L2 cache is onboad the PIII modules.
The thing that
bothers me, tho, is that it's difficult to use such programs
unless the h/w is relatively similar.
Our graphics benchmarks run on everything from low end PCs right
up to high end workstations. We use lots of PCs, and we use
lots of high end workstations, I need to know the cross over
point in performance. If I can put an application on a PC I
definitely will. I gain in price, upgradability and accessibility,
but I can't do that with all applications (I wish I could, those
large SGI machines are really expensive). That's the
beauty (and downfall?) of benchmarks like Dhrystone 2.1 - it can
be run on most any piece of computer h/w every designed.
Yes, and the results are typically meaningless. Benchmarking
is really hard, and typically the more general the benchmark
the more useless it is. Here's a little example. Several
years ago we went to two companies to evaluate their high
end machines. According to the specs and benchmarks Machine A
was the clear winner, at least 3x faster than Machine B. When
we actually ran our programs we found that Machine B was
consistently 2 or 3x faster than Machine A. This was a pretty
wide range of applications. There are several reasons why
this happened. One was that Machine B had much better compiler
technology. The other was that the specs and benchmarks didn't
tell the real story, how the machine really performed. Its
easy to tune a machine to look good on standard benchmarks,
but it may not run anything else at near that speed.
So this is a spread of maybe 6x or so between A and B? Just curious,
what were the Dhrystone 2.1 numbers for Machine A and Machine B? Could
you run identical OSs on them? Could you (if you wanted to) run identical
compilers on them?
Yes, I acknowledge the difficulty of making good benchmarks, but we should
start -somewhere- .
> I know this. But, frankly, -every- bus is
limited! Knowing how to "tune"
> a system's architecture is partially what makes computers fascinating to me.
>
> It's also one of the main reasons I enjoy looking at and studying these
> old behemoths, even vaxes? ;-)
Well the IBM 390 architecture is still in use, which
goes
back to the 360 in the early 1960s. Thats a pretty long
lived architecture.
That is long-lived. The 360 was the quintessential upward-compatible
architecture, right? "The "360 degrees" (full circle) of
applications".
And s/w compatibilty was paramount.
My bet is we'll see the PC live for much much longer than the 360. It's
just evolution, eh?
-mac
--
Dr. Mark Green mark(a)cs.ualberta.ca
25 Oct
25 Oct
6:41 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 569 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991025/355ae1e0/at…
7:18 a.m.
I recently migrated from a gorgeous 160 processor Big Blue SP2 to
a 64 node (4x500Mhz pentiums/node) AC3 Velocity NT cluster. (See
http://www.tc.cornell.edu/UserDoc/SP/what.is.sp2.html ; I hope it is
accessible outside Cornell).
The reason? We did not have funding to upgrade the SP2, and the NT
cluster was
sort of a gift. The switch in the NT cluster is supposed to be several
times
faster than that in the SP2, which is 150MB/s (it is also 6 years
newer).
Quite frankly, I don't see a performance improvement of that magnitude
as a user.
And I am not happy with the scheduler and the development environment
(understatement). But everything is under development, so perhaps
things
will improve soon.
As an aside, installation of the cluster took 15 hours for a 7 person
team,
while the SP2 took weeks ...
other links if you are interested...
http://www.tc.cornell.edu/er/media/1999/cluster.html
"Zane H. Healy" wrote:
I'm curious, what clustering software is available
that will match or exceed
OpenVMS? Under Linux you've got Beowulf, but that's basically a distributed
processing system IIRC. Under NT they like to claim they can cluster, but
the NT Admins I've spoken with about it admit it's basically failover, and
it can't even do that well.
Zane
--
Carlos Murillo-Sanchez email: cem14(a)cornell.edu
428 Phillips Hall, Electrical Engineering Department
Cornell University, Ithaca, NY 14853
8:52 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 874 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991025/b05b701e/at…
7:12 a.m.
This thread is starting to get tedious, it was interesting to start with but
now seems to have degenerated into pointless argument.
Mike, you seem either to be rather ill informed or out to start a flame war.
Despite the fact that I have my arm in a sling and it's agony to type (result
of moving a piece of classic iron recently) I can't sit by and watch this pass
without making at least some comment. After which I'm filtering out this
thread....
So, to business.
It depends entirely on the system architecture.
Two 1MHz busses will be faster than a single 2MHz bus if they are being used
for different purposes, such as one for I/O and one for memory accesses.
Particularly in the case of the PC the single expansion bus is a major
bottleneck. The original design had all I/O, memory, memory refresh etc ALL
done over a single bus.
Although things have gotten a lot better with the introduction of MCA, EISA,
VL and PCI, separate RAM busses etc there's still a long way to go. We still
effectively have a single bus down which we're trying to shovel the majority
of our data.
....I think single-user; I run single-user machines....
Exactly, Mike you're looking at just ONE sector of the computer world. What is
important to you is of no consequence to a vast number of other
people/corporations who need to support multiple users and process vast
amounts of data.
....The future is single-user with vast
network-accessed databases.
RUBBISH, you're making assumptions based on your own view of the industry. In
the real world there is a need for both single user systems/workstations AND
(comparatively) large multi user installations.
Both types of systems are targeted at different types of applications and both
will always have their place in the market.
But then, of course, I think you probably realise this and are just offering
us more flame bait?
BUT, I would like the Vax Lover Crowd to acknowledge
that they integer
performance of their machine is pathetic.
More flame bait. Do you REALLY think that making assertions such as this is
going to make anyone on the other side of the fence anything but
defensive?????
As others have already pointed out, integer performance/MIPS/drystones etc is
NOT a good indicator of overall SYSTEM performance. THAT is what is of
importance at the end of the day.
A personal example....in the mid '80s I was working in the video games
industry writing software for Atari and Commodore systems (Atari 8-bit,
C64/+4, Atari 7800). I used to assemble my programs on the Atari and transfer
them to the target system rather than use a cross assembler on a PC. Why?
Because although the PC I had access to ran a V20 at 8MHz compared to the
rather pedestrian 1.79MHz of my Atari's 6502 the PC took roughly 4 times
longer to do the same job - even with the obvious advantage of having a hard
drive. If you want the damn figures I expect I still have them somewhere
(though it would mean digging out my Atari system to access the data).
It was a simple case of superior SYSTEM architecture.
Its not the
speed of the individual bus, but its the number
of busses.
That's of course bull.....
The more busses, the more parallelism and the less
waiting.
-IF- the speed of the busses is high enough! After all, at -some- point, all these busses have to
get their data
into/out of the CPU....
No, at some point all these busses have to get their data in/out of MEMORY.
Polled/interrupt driven I/O is at best extremely wasteful of processor
time....this is why I personally use SCSI in my PC in preference to IDE (which
makes it ALMOST usable).
....and it does show that there are other busses
available on a
PC, yes? (Which was my original point.)
But with just ONE bus in the system you STILL have a bottleneck.
It doesn't matter how many lanes you have on a single motorway, or how fast
your car is, when you have a lot of traffic on the road you still get traffic
jams and major bottlenecks at junctions and on/off ramps....
TTFN - Pete.
--
Hardware & Software Engineer. Sound Engineer.
Collector of Arcade Machines, Games Consoles & Obsolete Computers (esp DEC)
peter.pachla(a)wintermute.org.uk |
peter.pachla(a)vectrex.freeserve.co.uk |
peter.pachla(a)virgin.net |
peter.pachla(a)wintermute.free-online.co.uk | www.wintermute.free-online.co.uk
--
8:08 p.m.
Peter, I do hope your arm heals quickly.
On Mon, 25 Oct 1999, Peter Pachla wrote:
Which is going to be done on servers.
I don't believe it. Can you please give me some specific application that
is better served by some timesharing system?
Peter, I have -tried my damndest- to -prove- beyond the shadow of a doubt
with facts and data to support that assertion. Look, I'm getting
tired of repeating this.
What I'm TRYING to do is to understand the performance of old machines
in terms of new machines; what I don't understand is why so many people
are uptight about this. Heck, we might all even learn something, eh?
Peter, you'll note that I said that there are some cases where "channel-to-
channel" I/O occurs, but I call that "Simulfax Shuffle Time" (after
Firesign Theatre) - that is, in general, except for the special case of
file copy for backup, moving data around without processing it is a logical
and architecture error (or at least, inefficiency).
And, data into or out of memory -eventually- must go into and out of the CPU,
in general - else, there's no processing actually occurring. And I'm
afraid I don't agree with the one poster that was making the case that
moving data around should be considered processing, for reasons, above.
This analogy is flawed, I'm afraid.
A better example is: how much lead can you deliver to a load with two guns
rated 1 Mega-Bullets per Second vs one gun rated at 2 MB/Sec?
Answer, of course: They produce the same amount of deposited lead on the
target.
Another analogy might be:
I have a Racecar, a family car, a truck, and a bicycle. (Roughly SBI,
CI Bus, MASSBUS, and UNIBUS).
But if I had all Racecars......
....I think
single-user; I run single-user machines....
Exactly, Mike you're looking at just ONE sector of the computer world. What is
important to you is of no consequence to a vast number of other
people/corporations who need to support multiple users and process vast
amounts of data. ....The future
is single-user with vast network-accessed databases.
RUBBISH, you're making assumptions based on your own view of the industry. In
the real world there is a need for both single user systems/workstations AND
(comparatively) large multi user installations. But then, of course, I think you probably realise this
and are just offering
us more flame bait?
I have never offered flame bait on this discussion. I have tried to
understand other points of view, and to be corrected when I was wrong. I'm
a little too old to be throwing out flame bait.
BUT, I would
like the Vax Lover Crowd to acknowledge that they integer
performance of their machine is pathetic.
More flame bait. Do you REALLY think that making assertions such as this is
going to make anyone on the other side of the fence anything but
defensive????? As others have already pointed out, integer
performance/MIPS/drystones etc is
NOT a good indicator of overall SYSTEM performance. THAT is what is of
importance at the end of the day.
BUT, BUT BUT! It -is- true that a .... is 2 to 3 times ... Right? Admit
it! That's a very very simple statement of fact, why is this -sooooooo-
difficult for so many on this list?
A personal example....in the mid '80s I was working
in the video games
industry writing software for Atari and Commodore systems (Atari 8-bit,
C64/+4, Atari 7800). I used to assemble my programs on the Atari and transfer
them to the target system rather than use a cross assembler on a PC. Why?
Because although the PC I had access to ran a V20 at 8MHz compared to the
rather pedestrian 1.79MHz of my Atari's 6502 the PC took roughly 4 times
longer to do the same job - even with the obvious advantage of having a hard
drive. If you want the damn figures I expect I still have them somewhere
(though it would mean digging out my Atari system to access the data).
I would always choose the faster system, all other things being equal, too.
It was a simple case of superior SYSTEM architecture.
And, no doubt, crummy PC s/w.
Two 1MHz busses will be faster than a single 2MHz bus
if they are being used
for different purposes, such as one for I/O and one for memory accesses.
But my point is that one 4 MHz synchronous bus is going to be faster than
two 1 MHz busses in all cases.
Nonetheless, what you say is not necessarily true.
For example, assume that your hypothetical case of two 1 MHz busses, and
assume that the I/O bus and the Memory Bus are saturated.
If these I/O and memory accesses were multiplexed onto a 2 MHz bus, then,
they'd be one I/O then one memory then back to I/O etc, perfectly interleaved.
Anything less that this, and the busses would not be saturated.
In that case, the 2 MHz bus would equal the 1 MHz bus.
Now, what about the case for random arrivals? I'm not going to fully
derive this, but consider an I/O request frequency of Fio
and let Fm be the frequency of memory references.
If you have a system that is mostly doing computation, then Fio << Fm
and therefore, on a 2 MHz bus, the memory bandwidth is > 1 MHz (which is
the MAX you can get on the other bus).
Similarly, if you're doing mostly I/O, then Fio >> Fm, and you can do
up to two times the I/O on a single 2 MHz bus than you can do on a single
1 MHz bus.
I think I have just proven that multiple busses are an architectural disaster.
Failing at that, I have proved your original assertion as being incorrect.
Multiple busses -are- useful to match the slow speed of I/O to the fast
speed of the processor's memory system. And, clearly DEC believed in the
more busses the merrier: UNIBUS (tm), MASSBUS, CI Bus, SBI Bus, etc.
But if the I/O can keep up, then separate busses are a disaster.
Particularly in the case of the PC the single expansion
bus is a major
bottleneck. The original design had all I/O, memory, memory refresh etc ALL
done over a single bus.
You'll note that I was not trying to defend the original PC.
Although things have gotten a lot better with the
introduction of MCA, EISA,
VL and PCI, separate RAM busses etc there's still a long way to go. We still
effectively have a single bus down which we're trying to shovel the majority
of our data.
After all, at
-some- point, all these busses have to get their data
into/out of the CPU....
No, at some point all these busses have to get their data in/out of MEMORY.
Polled/interrupt driven I/O is at best extremely wasteful of processor
time....this is why I personally use SCSI in my PC in preference to IDE (which
makes it ALMOST usable). ....and it does
show that there are other busses available on a
PC, yes? (Which was my original point.)
But with just ONE bus in the system you STILL have a bottleneck.
It doesn't matter how many lanes you have on a single motorway, or how fast
your car is, when you have a lot of traffic on the road you still get traffic
jams and major bottlenecks at junctions and on/off ramps.... TTFN - Pete.
--
Hardware & Software Engineer. Sound Engineer.
Collector of Arcade Machines, Games Consoles & Obsolete Computers (esp DEC)
-mac
8:43 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 3433 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991026/c21d82fc/at…
9:20 p.m.
The Great Initialed One (spc) states:
Because I develop software. I Edit (Integer), Compile (and an optimizing
compiler really grinds away in core, err, memory), and Run (usually integer).
Since that's what I do, that's what I want a system to do -well-.
I can BLT bits around, too. But it doesn't help me compile data, or
to compute Viterbi syndromes of data, or perform some signal processing
on some data, etc...
"Processing" means it goes through the central "Processing" unit, or
indeed,
through some "channel processor" that modifies data in some way, or at
least uses data to compute some other quantity. Some processor has to
comb over the memory.
Mike Cheponis sez:
Why? Exactly? Well, I want to know just how "powerful" these machines
really were. One way to do that is to actually work on them, and another
way is to compare them to machines that I understand.
For me, it helps put these machines in perspective.
You know, it's funny, I just made this (what seemed to me obvious) observation
about the Dhrystone 2.1 performance, figuring that other people would be
pleased to have some anchor on performance they (like I) could relate to.
But, instead, I've had to change my Asbestos Suit here several times! ;-)
What I'm TRYING to do is to understand the performance of old machines
in terms of new machines; what I don't understand is why so many people
are uptight about this. Heck, we might all even learn something, eh?
Why exactly? it! That's
a very very simple statement of fact, why is this -sooooooo-
difficult for so many on this list?
I don't think it's difficult. Yes, a Pentium is X times faster than a VAX
in integer math. But what I'm curious is to why is that important? Yes
siree, many's the time I wanted my computer to nothing but adding huge lists
of integers as fast as possible. The more the better. I don't actually
care about anything else than adding lists of integers.
Do I sense a wee bit of sarcasm here? ;-/
Peter,
you'll note that I said that there are some cases where "channel-to-
channel" I/O occurs, but I call that "Simulfax Shuffle Time" (after
Firesign Theatre) - that is, in general, except for the special case of
file copy for backup, moving data around without processing it is a logical
and architecture error (or at least, inefficiency).
Please define what you mean by ``processing''. I can have the Amiga load
data off the floppy into memory, then have it output that data to the sound
chips, all without the data going through the CPU. I can have the Amiga
load data off the floppy into memory and have it displayed and moved about
with having it go through the CPU. In fact, some high end [Internet] core routers
don't even ``process'' the
packets that they route. Or rather, the CPU in such routers rarely, if
ever, ``process'' such packets. Data comes in one side, goes out the other
in a more or less ``channel to channel I/O'' process.
The important point is "more or less" AND the whole -point- of routers is
that they are, to the extent possible, simulfax shuffle devices. But if
they were -pure- simulfax shufflers, then they'd be replaced with a piece of
wire.
Those routers are re-wrapping the IP when they send it out another port,
decrementing the TTL field, re-computing the IP checksum, and the low-level
(link layer) wrapper. Sure, much of this is h/w assisted.
(And, as I've said, s/w is just h/w that hasn't settled down yet...)
But if you're going to play semantic games with me, for example, saying that
the channel processors are NOT processors, then, fine. But they are,
indeed, processors. So saying that channel processors are just
simulfax shufflers is cheating (since they are processors).
But it's just a definition. Some say simulfax shuffling is processing;
OK, that's fine, as long as we define terms.
(You conveniently clipped my proof why one bus is often better than two,
but what the heck - you must have agreed with me on that! 8-) )
Like all analogies applied to computers, even this
one is misleading.
Yes, even though the single 2MB/sec gun can deliver the same amount of lead
as two 1MB/sec guns, with two guns I can have better targeting, or have more
of a spread.
I don't see the relevance here with your distinction; can you please
elaborate?
-spc (Sure, I can have the CPU read every byte off
the harddrive (IDE)
AND then process it, but I still get better through put by having
the hardware read every byte off the harddrive (most SCSI cards)
and then process it ... )
I like SCSI, too.
-mac
26 Oct
26 Oct
2:54 p.m.
New subject: Defining "OBSOLETE" (Was: gauging interest in VAX 6000-530
"OBSOLETE"
"You rang?"
I don't see any reason why my computing hardware needs to be much less
obsolete than I am.
Ah, the ubiquitous obligatory automotive analogy.
OB_AutoAnalogy: Which is faster? A "Land-Speed-Record" contender? Or a
Formula I car?
Now enter them both in the Baja 500. Two DNFs. The same drivers would
have better odds of completion with a stock enonobox.
Which is faster? A Porsche Boxster or a '38 GMC schoolbus?
Ferrying a few dozen people to and from the airport at rush hour?
OB_CC: Moving a VAX?
Perhaps as a more appropriate measure of automotive speed, we could use
the time that it takes to move 8 Vaxen 200 Kilometers.
EVERY computer is the fastest. You just need to figure out which task it
is the fastest at.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
It doesn't
matter how many lanes you have on a single motorway, or how fast
your car is, when you have a lot of traffic on the road you still get traffic
jams and major bottlenecks at junctions and on/off ramps....
This analogy is
flawed, I'm afraid.
Another analogy might be:
I have a Racecar, a family car, a truck, and a bicycle. (Roughly SBI,
CI Bus, MASSBUS, and UNIBUS).
But if I had all Racecars......
24 Oct
24 Oct
7:08 p.m.
On Sun, 24 Oct 1999, Mark Green wrote:
You've got to be kidding!!! Most VAXes out there
are running large
multiuser systems. The VAX has not been out of production for
very long, and there are still a considerable number of systems
The VAX is still in production, man.
-Dave McGuire
7:34 p.m.
On Sun, 24 Oct 1999, Mark Green wrote:
Sorry, with all the changes going on at Compaq, I thought they would
have killed it off by now (after all it was a DEC machine) :-).
--
Dr. Mark Green mark(a)cs.ualberta.ca
Professor (780) 492-4584
Director, Research Institute for Multimedia Systems (RIMS)
Department of Computing Science (780) 492-1071 (FAX)
University of Alberta, Edmonton, Alberta, T6G 2H1, Canada
You've got to be kidding!!! Most VAXes out
there are running large
multiuser systems. The VAX has not been out of production for
very long, and there are still a considerable number of systems
The VAX is still in production, man.
-Dave McGuire
8:03 p.m.
On Sun, 24 Oct
1999, Mark Green wrote:
Sorry, with all the changes going on at Compaq, I thought they would
have killed it off by now (after all it was a DEC machine) :-).
--
Dr. Mark Green mark(a)cs.ualberta.ca You've got to be kidding!!! Most VAXes out
there are running large
multiuser systems. The VAX has not been out of production for
very long, and there are still a considerable number of systems
The VAX is still in production, man.
-Dave McGuire
10:39 p.m.
Mark Green <mark(a)cs.ualberta.ca> wrote:
The problems is equivalent hardware. You can't
configure a PC
like a VAX, they are two different types of machines. A PC
is tuned for a single user, while a VAX is tuned for many users.
These are very different machine configurations, and even the latest
PC would have no hope of keeping up to a decade old VAX running
a large multiuser application.
False. I have personal experience with PCs serving the same kind
of workload you describe of VAXen, and they work fine.
Many of the PC manufacturers
have tried to scale PCs to this level and they have all failed.
Compaq's high-end x86 based servers don't seem to have failed.
single bus systems like the PC can't scale to the
performance required.
The bus in a modern PC isn't the issue. It's comparable to what's
in most workstations.
The problem is the software architecture. Despite all of the ballyhoo
surrounding MS Windows NT, the reality is that it is too bloated and
inefficient to support enterprise applications.
I'll agree with you that high-end server class machines today
are more powerful, have higher bandwidth busses, and more busses,
than most PCs. But how could it be otherwise? Anyhow, that's not what
this discussion was about.
The claim was that a 486DX2/66 PC could outperform a VAX 8650. And so
far, no one has refuted that claim, though many people seem to have
decided that it must be false, and given specious arguments as supposed
proof. Apparently there is some sort of near-religious belief that a
minicomputer (regardless of how old it is) MUST have better performance
than a PC.
11:06 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1358 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991025/e10285fc/at…
25 Oct
25 Oct
7:37 a.m.
Mark Green <mark(a)cs.ualberta.ca> wrote:
Note that in the above comments I said PC, I did not say
server. I'm talking about a PC architecture and not the
particular chip, such as an Intel chip. I have yet to see
a PC (as in workstation) have more than 2 CPUs. I can
get 2 CPU systems from the likes of HP, DELL, whoever gets
SGIs NT line, etc. But thats where it ends. On a workstation,
such as SUN, SGI, HP and probably others I can scale above
2 CPUs.
The PC architecture was designed to be low cost. It works
very well that way, but you can't say its the best architecture
for everything (which is the point being discussed). At some
point you need to go to multiple busses, multiple processors,
interleaved memory architectures, etc.
The problems is equivalent hardware. You
can't configure a PC
like a VAX, they are two different types of machines. A PC
is tuned for a single user, while a VAX is tuned for many users.
These are very different machine configurations, and even the latest
PC would have no hope of keeping up to a decade old VAX running
a large multiuser application.
False. I have personal experience with PCs serving the same kind
of workload you describe of VAXen, and they work fine.
Many of the PC manufacturers
have tried to scale PCs to this level and they have all failed.
Compaq's high-end x86 based servers don't seem to have failed. single bus systems like the PC can't scale to
the performance required.
The bus in a modern PC isn't the issue. It's comparable to what's
in most workstations.
The problem is the software architecture. Despite all of the ballyhoo
surrounding MS Windows NT, the reality is that it is too bloated and
inefficient to support enterprise applications.
I'll agree with you that high-end server class machines today
are more powerful, have higher bandwidth busses, and more busses,
than most PCs. But how could it be otherwise? Anyhow, that's not what
this discussion was about.
The claim was that a 486DX2/66 PC could outperform a VAX 8650. And so
far, no one has refuted that claim, though many people seem to have
decided that it must be false, and given specious arguments as supposed
proof. Apparently there is some sort of near-religious belief that a
minicomputer (regardless of how old it is) MUST have better performance
than a PC.
You may be arguing that, and I agree with your point. Its just
comments like the PC architecture can outrun anything that I
find hard to take. Some of these statements may have come out
in the heat of the arguments.
--
Dr. Mark Green mark(a)cs.ualberta.ca
Professor (780) 492-4584
Director, Research Institute for Multimedia Systems (RIMS)
Department of Computing Science (780) 492-1071 (FAX)
University of Alberta, Edmonton, Alberta, T6G 2H1, Canada
24 Oct
24 Oct
3:48 p.m.
My main belief is that nobody is going to keep a VAX
anything running with
dozens of simultaneous users. So, if a VAX is to be something close
to "useful" today, it'll be in single-user mode. In that case, Integer
performance is very important.
Ah, to bad you don't know what you're talking about here. I know of a
certain major corporation that just got done putting a whole pile of new
VAX 7000's in a brand new computer room. Said corporation has numerous
computer rooms with VAXen, and these systems are heavily used.
Hey, I'm not saying the original IBM PC was going
to outperform the VAX 6500;
but a modern PC will crush any VAX in any application, IMHO, with equivalent
h/w attached.
Speed isn't everything. I'd rather have a nice VAX than a modern PC,
you've also got to consider the fact that PC's aren't the most reliable of
platforms, and most run an OS that totally sucks!
Zane
| Zane H. Healy | UNIX Systems Adminstrator |
| healyzh(a)aracnet.com (primary) | Linux Enthusiast |
| healyzh(a)holonet.net (alternate) | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
5:35 p.m.
My main belief
is that nobody is going to keep a VAX anything running with
dozens of simultaneous users. So, if a VAX is to be something close
to "useful" today, it'll be in single-user mode. In that case, Integer
performance is very important.
Ah, to bad you don't know what you're talking about here. I know of a
certain major corporation that just got done putting a whole pile of new
VAX 7000's in a brand new computer room. Said corporation has numerous
computer rooms with VAXen, and these systems are heavily used. Hey, I'm
not saying the original IBM PC was going to outperform the VAX 6500;
but a modern PC will crush any VAX in any application, IMHO, with equivalent
h/w attached.
Speed isn't everything. I'd rather have a nice VAX than a modern PC,
you've also got to consider the fact that PC's aren't the most reliable of
platforms, and most run an OS that totally sucks!
My PCs are damn reliable; are you buying junk? They are -waaaaaaaaaaay- more
reliable than the VAX-11/780s, VAX-11/750s and VAX-11/785s that I have
used in the past. (I run BSDI unix on a Pentium Pro, as well as NetBSD on
other machines, and they have -never- crashed.)
Zane
-mac
6:33 p.m.
Mike Cheponis wrote:
[stuff deleted]
That's correct. Unfortunatly, CPU speed is kinda meaningless in and of itself,
save for some very degenerate applications (i.e., no I/O, no external
memory references, everything resolves in on-board cache, etc.)
I run Solaris on Ppros, PIIs and Sparcs, Linux on PIIIs and OpenBSD on Sparcs.
The PCs are less reliable than the sparcs, but even then they're far more
reliable than anything from the late 70's. If we look at contemporaries, my
fuzzy recollection is that the 785 I was using was generally a hell of a lot
more reliable than the PC/AT I was using at the time -- and the 785 cranked
a hell of a lot harder than the AT did.
Cheers,
Chris
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
The paradigm today is client on Ethernet, server
cluster in the back room.
Scalable, cheap, reliable.
One Big Box In The Back Room is what people did in the 40s, 50s and 60s.....
And 90s. Data is expensive to ship and dramatically more expensive to keep
coherent when distributed, even across short distances and gigabit networks.
If this were not the case we wouldn't see Enterprise class machines being
pushed out the door, and I wouldn't be watching a client who accepted the
notion of "cheap" computing clusters without stopping to think throw more
and more hardware at their back-end -- what was originally a single US170E
became a 2300, then a 2400, then a pair of 2400s and now a four-processor
E450 and a 2400 -- all to support a handful of 500MHz NT clients who are
doing all the computations. That right, no integer math, no floating point,
not nuthin' on the backend except moving data around.
Draw a typical "modern" distributed computing architecture on the wall,
then do the same for a 360 TSO system using 3270s. Damn if the pictures
don't look the same save for the labels on the boxes. The 3270 has been
replaced by a thin client, and the Big Blue box has been replaced by a
big-ass Enterprise 10K from Sun. Yeah, the communications links are
faster, but with more processing done on the front end I generally have
to ship more data more often and go through parlor tricks to keep the
stuff in synch -- not an issue for passive web browsers, but then the
browser is a lousy model for many applications.
The bottom line here is the speed of light; at some point I need to do
more things in parallel to increase my throughput. A typical PC with a
single bus simply can't push as much data as a large machine with a bunch
of independent dedicated buses managed by their own controllers.
Of course, none of this has anything to do with the 486 integer ALU vs.
a Vax 8mumble ALU -- it has to do with the overall architecture of
the machine. Given a similar bus and channel controller structure
one could get the same throughput out of an x86 as a Vax, MV or
309x class machine.
>>Hey, I'm not saying the original IBM PC
was going to outperform the VAX 6500;
>>but a modern PC will crush any VAX in any application, IMHO, with equivalent
>>h/w attached.
The problem is that I can't attach equivalent hardware. Given the choice between
deploying Solaris on an x86 or a sparc I'll take the x86 90+% of the time
-- on the desktop the price-performance is tough to beat. However, there's
simply no way that I can do it for anything that requires shuffling around
large amounts of data. I can't get a PC that has enough aggregate bandwidth;
an Enterprise machine will smoke the PC's doors off despite the fact that the
PC is clocking hundreds of Mhz faster (aside: does anyone know offhand what
the typical CPI is for the Ppro, PII and PIII?). Again, that's not a commentary
on the processor, it's a commentary on the overall architecture. A Sequent, for
example, has a far better architecture than any PC I can buy.
Speed isn't everything.
You're right, speed isn't everything; it's the -only- thing! ;-) I'd rather
have a nice VAX than a modern PC,
you've also got to consider the fact that PC's aren't the most reliable of
platforms, and most run an OS that totally sucks!
My PCs are damn reliable; are you buying junk? They are -waaaaaaaaaaay- more
reliable than the VAX-11/780s, VAX-11/750s and VAX-11/785s that I have
used in the past. (I run BSDI unix on a Pentium Pro, as well as NetBSD on
other machines, and they have -never- crashed.) 
25 Oct
25 Oct
4:53 a.m.
New subject: Solaris Pentium vs. Solaris Sparc
The problem is that I can't attach equivalent
hardware.
Given the choice between deploying Solaris on an x86 or a sparc I'll take
the x86 90+% of the time -- on the desktop the price-performance is tough
to beat. However, there's
simply no way that I can do it for anything that requires shuffling around
large amounts of data. I can't get a PC that has enough aggregate bandwidth;
an Enterprise machine will smoke the PC's doors off despite the fact that the
PC is clocking hundreds of Mhz faster (aside: does anyone know offhand what
the typical CPI is for the Ppro, PII and PIII?). Again, that's not a
commentary on the processor, it's a commentary on the overall architecture.
A Sequent, for example, has a far better architecture than any PC I can buy.
I run Solaris on Ppros, PIIs and Sparcs, Linux on PIIIs and OpenBSD on Sparcs.
The PCs are less reliable than the sparcs, but even then they're far more
reliable than anything from the late 70's. If we look at contemporaries, my
fuzzy recollection is that the 785 I was using was generally a hell of a lot
more reliable than the PC/AT I was using at the time -- and the 785 cranked
a hell of a lot harder than the AT did.
Cheers,
Chris
Having played around with equivalent 486-66's and SparcII's (properly
configured) I'd say Solaris works better on Sparc.
I'm not sure that I'd pick the Sparc over PC using the a different OS (say,
OpenBSD or Linux).
The PC's are often less reliable because of cheap non-parity memory,
badly designed cheap IDE disks and such.
(I've run 6 years of FreeBSD on PC's with only two hardware related
failures -- 486/33 motherboard and one Adaptec 2740 -- the later due to
me mis-plugging the SCSI connector and bending and shorting a controller
pin.) My SparcII's and 10's at work don't do as well and I've already
been through one Ultra's motherboard.
My new home box is a K6-2 450 on an FIC 503+ motherboard with dual
SCSI Fast Wide Symbios controllers. Damn thing feels as solid and
quick as the 8650 Vax (but I miss the RT11 front end).
Now if FreeVMS would be available in addition to the mix of
DOS/Win31/OS2/FreeBSD/Linux/Win2000 that I'm loading I'd be happy.
Your mileage may vary....
Bill
---
bpechter@shell.monmouth.com|pechter@pechter.dyndns.org
Three things never anger: First, the one who runs your DEC,
The one who does Field Service and the one who signs your check.
24 Oct
24 Oct
6:34 p.m.
I really hate to become a part of this stupid flame war, but there are some
real misconceptions here that I really feel the need to try to address.
Nothing personal; smarter people than I have been known to fall for PC-itis.
On Sun, 24 Oct 1999, Mike Cheponis wrote:
Maybe I should have said "Nobody -sane- is going to....".
I'm generally considered to be rather sane, and if I'm betting my reputation
and my company's livelihood on it, I sure would.
You're right, speed isn't everything; it's the -only- thing! ;-)
I think the point was "integer cpu speed" isn't everything...which is
about
all a "modern" PC has. There's more to computer architecture than clock
speed.
A 500MHz PentiumIII has better raw integer performance than a VAX9000...but a
VAX9000 can easily handle upwards of a thousand interactive users without
breaking a sweat. The pentium will fold up with a hundred at most.
Too many smart people have fallen for Intel's marketing and PC hype. Don't
be one of them. Real computers are still available...you just can't buy them
in malls.
-Dave McGuire
My main belief is that nobody is going to keep a VAX
anything running with
dozens of simultaneous users. So, if a VAX is to be something close
to "useful" today, it'll be in single-user mode. In that case, Integer
performance is very important.
Ah, to bad you don't know what you're talking about here. I know of a
certain major corporation that just got done putting a whole pile of new
VAX 7000's in a brand new computer room. Said corporation has numerous
computer rooms with VAXen, and these systems are heavily used. The paradigm today is client on Ethernet, server
cluster in the back room.
Scalable, cheap, reliable.
You mean "the paradigm that vendors want to sell today is..."
Keep in mind that there are computer rooms other than yours, with different
requirements than yours, doing different things than yours. It's easy to put
blinders on and think "what works for me ought to work for anybody" (hell, I do
it all the time myself!)...but keep in mind that people do *different* things
with computers.
One Big Box In The Back Room is what people did in the
40s, 50s and 60s.....
And 70s and 80s and 90s. It's not going away anytime soon. Just because it
was also done a long time ago doesn't mean it sucks now.
"Wow, when are you going to get rid of that automobile? People used those
way back in the 30's, man! Throw that old shit away!"
Hey, I'm not saying the original IBM PC was going
to outperform the VAX 6500;
but a modern PC will crush any VAX in any application, IMHO, with equivalent
h/w attached.
Speed isn't everything.
6:49 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1596 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19991024/bd032b5d/at…
9:35 p.m.
On Sun, 24 Oct 1999, Sean 'Captain Napalm' Conner wrote:
Mike Cheponis once stated:
>
>>I'd rather have a nice VAX than a modern PC,
>
>My PCs are damn reliable; are you buying junk? They are -waaaaaaaaaaay- more
At one company I did some consulting work for they
had a rather large
Another story relates how they shut the machine down
to reboot it into
THAT was a reliable machine, although for the life of
me I'm blanking on
the type of computer (I want to say Sequent (sp?)).
-spc (So far, the longest I've seen a PC go is
320 days)
These are great stories, thanks for telling them.
Really, isn't that they way we want computers to behave? It's almost as
if they're alive!
very best -Mike
25 Oct
25 Oct
6:44 p.m.
----- Original Message -----
From: Mike Cheponis <mac(a)Wireless.Com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Sent: Monday, 25 October 1999 6:54
Subject: Re: gauging interest in VAX 6000-530
Eh? ROFLMAO. Sorry, but it appears to me that you have not been exposed to
these machines, or
you would not be making this statement...
Mark Green wrote:
> Mike Cheponis wrote:
>> Looks like the 6500 was about 13 VAX-11/780 MIPS. That would make it
about
>> 2x to 3x slower than a 486DX2/66.
Note also that it is 13 VUPS PER CPU. A 530 has 3 cpus.
Consider this, if the pci buss can't effectively serve a single cpu to the
point
it is being fully utilised, what chance does it have of coping with the
thruput load
on a multi cpu system. The Vax can and does. IIRC, the XMI gets saturated
under high workload when something like 5 or 6 cpus are fitted.
Integer
performance is a very misleading
measure of performance when you are talking about system performance.
My main belief is that nobody is going to keep a VAX anything running with
dozens of simultaneous users. So, if a VAX is to be something close
to "useful" today, it'll be in single-user mode. In that case, Integer
performance is very important.
I'll be sure and tell our Vax 6000-440 that one. It could probably use a
laugh.
It's currently:
1. Domain mail server (MX 5.1) (SMTP mail exchange for the Unix types)
2. POP3 server for about 400 users. (IUPOP3)
3. FTP server for the domain, including anon ftp etc.
4. Web server for the school site. (WASD)
5. HTTP Proxy server for 150+ PC's
6. Web based email access to VMS mail for users out of town etc. (WASD's
Yahmail add on)
7. NFS serves it's drives to various Win9x boxes for ease of updating web
sites etc..
8. I use it to snarf files from various sources, since it's FTP never gives
up.
9. It automatically mirrors parts of certain commercial sites so that
software on the pc network
can update automagically without 150 pc's hitting the commercial site
for (for instance) virus
dat file updates.....
10. I use it's telnet/ftp/lynx etc to do all sorts of other stuff.
Going flat out on a good day, it probably uses about half of the cpu time
available.
An individual process can push 1 cpu up to 100% or close to it, but it still
services
other requests (like POP when there are 3 rooms full of people surfing
happily) quite well.
SMP on a Vax works very well, unlike the NT attempt at it....
Now, perhaps if we were to port Apache to the VAX, and
used that I/O
bandwidth
on multiple DS3s, well, that's great.
Too late, there is an apache port to VMS being done. I doubt if it's any
easier to use/better etc than
the WASD server we use, but I've never used Apache so I'll withold
judgement.
I just hope it's better than the Samba port. The inherently different file
systems make some
porting very difficult, since the equivalent services don't exist or are
radically different between VMS and
Unix.
> for example, all except
> the most recent PCs, there is only a single bus. This bus
> must be used for all memory transfers, graphics, I/O, etc.
> On a single user system, this is sometimes okay, but for
> multiple users forget it.
Correct.
Hey, I'm not saying the original IBM PC was going
to outperform the VAX
6500;
but a modern PC will crush any VAX in any application,
IMHO, with
equivalent
h/w attached.
Not so, sorry. A PCI buss pentium would die horribly under this machines
load.
Even more horribly if it was running NT. For a single user environment some
apps
would certainly run faster, but for throughput, multi-user, multi-tasking
etc,
the PC architecture is not a serious player.
> Most of the VAXes had multiple
> busses, and each was dedicated to a particular function.
A 6000 box (usually - I have 1 XMI only machine) has 2 busses, the XMI buss,
which is rated at 100 megabytes per second thruput (no, I don't mean
megaBITs) and is
64 bits wide, and the BI Buss, which is rated at 13 Megabytes per second and
is (I think) 32 bits wide. You should also note
this is not burst, but constant.
The CI (Computer Interconnect) Buss is not really a buss in the accepted
sense, but a dedicated 70Mbps network on what is
essentially thick (as in semi rigid - great cable for ham radio vhf/uhf use
BTW) ethernet. It's used to link/network machines in a cluster and for HSC's
(Heirarchical Storage Controllers) to serve disks and tapes to all machines
on the cluster, and is full duplex with redundant data paths. It 'lives' on
an adapter card in the vax, and can be either an XMI or BI card, depending
on the system
configuration. I have examples of both...
To use an automotive analogy, PC v VAX is roughly like this.
PC-CAR has a Super turbo charged V12 driving a single manual gearbox stuck
in first gear. The motor screams, but it
can't make the car go really fast because the mechanism for transferring the
power to the road wheels is broken/inefficient.
VAX-CAR has a normally aspirated 6 cylinder driving a couple of variable
ratio autotrans each driving separate sets of wheels,
and is capable of using the full available power of the cpu(s) to push the
car as fast as the engine(s) are capable of driving it.
This analogy is rough in places, but you get the idea.....
Hope this helps shed some light on the subject....
Cheers
Geoff Roberts
Computer Systems Manager
Saint Mark's College
Port Pirie, South Australia.
Email: geoffrob(a)stmarks.pp.catholic.edu.au
netcafe(a)pirie.mtx.net.au
ICQ #: 1970476
7:05 p.m.
*snip*
*snip*
No kidding. I watched our vax 4000/500 with 128 megs of ram - a grotesque
amount in those days, but it could take more) pull something like 200 users
running ALLIN1, an office suite, which was a monstrous system hog. The
4000/500 did it without breaking a sweat. Hell, even a microvax II with
16 megs of ram could handle 5 or 6 users using that monstrosity. Many many
more if you just used normal applications. When I was at Intel our cluster
of 6000/mumbles carried 400-500 users using a VERY large CAM system, several
hundred data connections via tcpip, a massive database to support the CAM,
etc etc.
While a desktop PC may be able to smoke most vaxen for CPU performance, the
PC that can stand up and do a big vax's JOB doesn't exist. Vaxen were designed
for heavy continuous use. PCs were designed to be disposable.
--
Jim Strickland
jim(a)DIESPAMMERSCUMcalico.litterbox.com
-----------------------------------------------------------------------
BeOS Powered!
-----------------------------------------------------------------------
My main belief
is that nobody is going to keep a VAX anything running with
dozens of simultaneous users.
Eh? ROFLMAO. Sorry, but it appears to me that you have not been exposed to
these machines, or
you would not be making this statement...
So, if a VAX is to be something close
to "useful" today, it'll be in single-user mode. In that case, Integer
performance is very important.
I'll be sure and tell our Vax 6000-440 that one. It could probably use a
laugh.
9032
days inactive
9034
days old
66 comments
21 participants
participants (21)
-
allisonp＠world.std.com -
ard＠p850ug1.demon.co.uk -
cem14＠cornell.edu -
cfandt＠netsync.net -
chris＠mainecoon.com -
cisin＠xenosoft.com -
cmcmanis＠mcmanis.com -
elvey＠hal.com -
eric＠brouhaha.com -
g＠kurico.com -
geoffrob＠stmarks.pp.catholic.edu.au -
healyzh＠aracnet.com -
jim＠calico.litterbox.com -
mac＠Wireless.Com -
mark＠cs.ualberta.ca -
marvin＠rain.org -
mcguire＠neurotica.com -
mikeford＠socal.rr.com -
pechter＠pechter.dyndns.org -
peter.pachla＠vectrex.freeserve.co.uk -
spc＠armigeron.com