HP3000-L Archives

March 2009, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Peter M. Eggers" <[log in to unmask]>
Reply To:
Peter M. Eggers
Date:
Thu, 5 Mar 2009 10:02:53 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (330 lines)
On Tue, Mar 3, 2009 at 7:41 PM, Paul Raulerson <[log in to unmask]>wrote:

>
> But Linux is HORRIBLY inefficient compared to operating systems written for
> the native platform. A typical operation, such as a fprintf() will run
> though hundreds or thousands of instructions, while under say, z/VM, it will
> run though 10's. Or less.


A formatted print operation has a few orders of magnitude of range in the
number of instructions depending on the formatting operations and data being
formatted, no matter what operation system.  Then you say that z/VM uses
10's or less?  Do you know that z/VM is not an operating system?  Or, did
you mistype and meant z/OS?  Either way, your argument is just plain silly.

Note that these OS's are pretty much all written in hand crafted assembler,
> which is in large part why they work so efficiently. And mainframes do I/O
> really well. They ain't called "Data Centers In A Box" for no reason.


Much depends on who is doing the "hand crafted assembler", and though most
of Linux is in C, much of the really critical code is optimized with inline
"hand crafted assembler" for each CPU architecture supported (which is just
about every commercially produced one).

Mainframes do I/O really well due to hardware.  I thought this was fairly
common knowledge.

The reason someone might refer to a mainframe as a "Data Centers In A Box"
is because they are able to run hundreds or even thousands of virtual
servers at once in a single box.  But, the phrase is used by ComputerWorld (
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9023178&intsrc=news_ts_head),
Scientific American (
http://www.sciam.com/article.cfm?id=data-center-in-a-box), and System
Management News (
http://www.sysmannews.com/HARD_TO_CONTAIN_ENTHUSIASM_FOR_DATA_CENTERS_IN_A_BOX/By_John_Rath/15th_of_July_2008/About_DATACENTERS_and_IBM_and_RACKABLE_and_SUN_and_VERARI/32521)
to refer to modular data centers in a shipping container (box) with Sun
being the first to create such a product using racked servers, not
mainframes.  IBM's own entry into the "Data Centers In A Box" market has to
do with cutting emissions and energy consumption (Tech World:
https://www.techworld.com.au/article/263809/data_centers_box?img=11010&ssid=1&fp=4&fpid=248),
and is described by IBM in a redbook here:
http://www.redbooks.ibm.com/abstracts/redp4413.html

By the way, Linux is darn near ubiquitous on mainframes these days. :)


You think there might be a correlation between the arrival of Linux on the
mainframe and the mainframe's revival?


> Peter - you will find my name in some of the Unix kernel code for BSD.


Some kernel contributors correct spelling errors, some design general
scheduling algorthyms for multi-purpose work loads;  some fix an iteration
count by 1, some write video drivers.  Where do you fall in the spectrum?
As in what did you write and can you cite the source code or patch with your
name on it.

I know how efficient Unix and Linux can be.
> Very efficient indeed.


Now you think Linux is very efficient?!


> But, you may not know how efficient mainframes are. They are very much like
> HP3K's - only much more so.
>
> Typically, a small mainframe, one priced in the same range as a largish
> HP3K, can easily support 10K users or more.


That has far more to do with the hardware architecture than the software
architecture, including the operating system, or in this case the
hypervisor.  In any case, they excel at moving massive amounts of data
around.  They are not efficient at compute intensive loads (that is what
supercomputers are for), nor do they do graphics efficiently (a more
specific compute intensive load that GPUs are extremely efficient at).

A Z10 BC machine running z/VM can run 10's or even 100's of copies of Linux,
> all simultaneously


You can do that with a Dell server, given sufficient memory, at a fraction
of the price.  Depending on workload of the guest operating systems, will
tell which will perform better.  Of course, the mainframe will win in
reliability hands down in any case.

To state "MPE, VM, ZOS, etc. all blow away Linux in terms of efficiency and
>>
>  the way they use the hardware" is not only unsubstantiated by any credible
>> tests that I am aware of, but also shows a lack of low level operating
>> system knowledge.
>>
>
> Oh, I wouldn't say that. I would say rather that it shows intimated
> knowledge of the platforms.


I can as easily intimate that the moon is made of cheese, but that doesn't
make it so either.


> I make no claims at all to expertise on HP3K's. But I do have a rather
> broad bit of experience on
> IBM Mainframes, Unisys (Sperry) 2200's, a bit on Burroughs, Suns, AS/400's,
> PDP-11's, a raft of embedded systems using
> Motorola and PowerPC, RS6000s, and a few other systems, including the Aegis
> kernel. And what I would class as
> exposure to a whole bunch of other systems.


So far, I'm not seeing the expertise in general operating system theory, nor
in specific architecture knowledge.  I see some name dropping, some
intimated expertise, some comparisons of "apples to oranges", and a lot of
hand waving on your part.  What I don't see is any evidence backed up by any
references, credible or not.


> I'm not bragging, just pointing out that I am not a mainframe bigot. But
> facts is facts.


I think you are confused here about what a fact is, and exposure doesn't
equate to expertise or comprehension.

  MPE, VM, and z/OS are written for a single hardware
> architecture families by their manufacturers.  VM isn't even an operating
> system, rather a hypervisor to run other operating systems, CP/CMS in
> particular.
>

What a load of marleky! z/Vm (to give it's proper and current name) is
> indeed a full operating system. CMS is nothing more than a shell, of which
> there are plenty others. Yes, it provides a hypervisor to run guests - or
> logins. Those logins can certainly be other operating systems - including
> z/VM itself.  However, z/VM was used as an interactive timesharing platform
> since the 1960s.


You are joking, right?  IBM's z/VM hypervisor was released October of 2000.
It was based on concepts that date back to the 1960s, and it has always been
a hypervisor, not an operating system.

-  CMS (Conversational Monitor System) is a light weight single user
operating system.
-  VM/370 is a reimplementation of CP/CMS, which is an operating system and
which was released in August of 1972.
-  z/VM is a hypervisor (by IBM's own description - http://www.vm.ibm.com/)
and is based on CONCEPTS going back to the 1960s, but introduced in October
of 2000 (thought it needed repeating).
-  z/OS is IBM's current flagship operating system

There is a whole "VM" family of products, VM-CP being the hypervisor and
VM-CMS being the operating system part.  A bit confusing to someone with
extremely little firsthand knowledge of IBM mainframes, but I would think an
expert like yourself would have those "little" details down pat.

For all the normal tasks, including word procesing, e-mail, spreadsheets,
> printing, etc. PROFS was a very standard way to do it.


So what does that have to do with operating system efficiency?

Both MPE and z/OS do not have GUIs and have very limited driver
>> support.  When you strip away all of the GUIs and myriad device drivers
>> unneeded for any sized server from Linux,  and then compile optimizing for
>> a
>> particular CPU, you have a very lean-and-mean operating system.
>>
>>
> No - what you really have is psuedo PDP-11 Macro assembler that is
> converted to the native assembly language for the target platform, with a
> whale of a lot of overhead.


How in the world do equate an assembler and native assembly language to an
operating system?  And what the heck does a PDP-11 have to do with anything
in this discussion?

First, Unix was written to be rather portable. Linux far more so.
> Efficiently is almost always sacrificed to portability in Linux.
> What makes Linux appear efficient is that it is running on really fast
> hardware - link Intel - and the hardware itself is being drive very
> inefficiently. What is the average utilization of the processor on even a
> heavily used Linux system? (Hint, it is why VMWARE is making inroads in the
> data centers.)


Hint:  You don't need VMWare if you don't run MS Windows servers.

Linux will run on very anemic hardware like cheap routers or an IPAQ.  What
part of that statement do you not understand?

The local computer recycler sells desktop computers with a Linux
distribution installed for Internet , home, and school use that runs well on
hardware that XP can't be loaded on.

Second, when you do strip it down to the bare bones, it isn't very useful.
> Great for running a phone perhaps, but not for handing massive data center
> loads. (And indeed, it turns out Linux does drive phone switches very
> nicely, but then, so did Unix. ESS systems you know... )


A stripped down Linux makes all sorts of nifty servers.  To run a phone
system requires that appropriate packages be applied to a certified kernel.
I don't know of any Unix system used to run a single phone, but Linux on
desktop hardware with GUI and Ekiga installed does a decent job.


Let me put it another way, I love the OS on 3Ks - it looks a LOT like
> Burroughs MCP, which I very much admire.
> I think when we get a decent emulator out here, or have the capability to
> port MPE/ix to a current platform,  that it has a real place in the current
> OS pantheon, and will be very popular indeed. (Well, with a little marketing
> that is...)


If you squint your eyes really tightly, an HP's MPE may look like Burroughs'
MCP, but only if your eyes are glazed over. ;)

I run Linux on my mainframe, and do some absolutely knock-you-socks-off
> amazing things with it.


Like what?


> But efficient is a relative term, and relatively speaking, Linux is
> anything but efficient. Indeed, I spend hours each month teaching it how to
> use the machine a bit more efficiently.


You are teaching it?  Last I looked, Linux didn't have any artificial
intelligence included.

 Not that I am complaining mind you, Linux is amazing. But how fast the
>
>> hardware is is knock-your-socks-off
>> amazing. :)
>
>
So, why don't you run something more efficient on your
"knock-your-socks-off" hardware?  There was a time that the BSD TCP/IP stack
was much superior, then it wasn't and never got the lead back.  There was a
time that Windows was tuned to serve high volumes of web pages on a
multiprocessor box (at a bandwidth exceeding all common networking
components), and then in less than 2 months time, it lost and lost big time,
never again to challenge Apache running on Linux for speed and efficiency.

So, what are you comparing Linux to on your hardware that shows Linux to be
inefficient?


> Linux does not need fast hardware to run and run well.  Most home wireless
>>
> routers and modems (DSL and cable) run Linux on very anemic hardware.  Yet,
> Linux is the choice to run the very fastest supercomputer in the world,
> Roadrunner (http://www.top500.org/system/9707), an IBM machine, yet IBM
> uses
> Linux over their own operating systems (granted, IBM operating systems are
> written for and optimized for mainframe architecture, not supercomputer
> architecture).  IBM mainframes also run a considerable amount of Linux (
> http://www-03.ibm.com/systems/z/os/linux/ and http://tinyurl.com/b2kpeq).
>
>
Supercomputing is *not* a mainframe thing; high volume transactional
> processing *is*. Big databases *are*.
> Really intensive I/O, *is*.


In case you hadn't noticed, Oracle knows a little something about databases,
especially large high transaction ones and data warehouses.  In 1998, IIRC,
they discovered on any particular hardware, Linux outperformed any other
operating system, and began converting not only their developer workstations
and servers over to Linux, but also all of their business systems.  Oracle
is now developed on Linux and then ported to other operating systems.

 If Linux doesn't run efficiently on any architecture, you can blame the
>> person installing it, not the Linux kernel, nor operating system built
>> around it.
>>
>>
> Actually, you can blame the Linux kernel. Just as a *simple* example, try
> having the kernel
> automatically limit CPU to a runaway process ---  without a kernel panic I
> mean.
> Ain't there. Not even in SuSE 11.


Define a "runaway process".  How does it differ from one that is a resource
hog that is running efficiently?  Do you not know how to limit a process's
CPU priority on Linux?  I have had processes that couldn't be killed on MPE,
but so far, never on Linux.

I used to get kernel panics (core dumps) once in awhile back in the '90s,
but can't remember the last.  Maybe that is because I only use stable
kernels to do work on, maybe its the Linux distributions I use.  Whatever
reason, it just works.

 I don't know why I bother anymore.
>
>
I'm not sure why either. You jumped all over me like white on rice. Who has
> been using you for a punching bag lately?
> You do have some points.
>
> Spirited Discussion is fun. The way you jumped me ain't.


Sorry, I was cleaning out my inbox when I came across this little gem marked
for reply, lost in the clutter, when my BS meter started blaring in my
head.  Being the Linux bigot that I am, I just couldn't let it go.  Knowing
little if anything about IBM mainframe particulars (nor really caring to),
but armed with an Internet connection, a little common sense, and an
uncommon understanding of computers, I dove into the steaming pile with the
fervor of a TV evangelical preacher.

One of the "grand old men" of the 3000 world once told me a few years back
that the window of opportunity to save MPE and the HP3000 closed in 2001,
and there wasn't currently the financial nor technical resources available,
and were willing, to save it since then.

Cheers, just "blowing in the wind", Peter

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2