#4 Context switching. Seems like when you switch from one task to
another on some processors, all of cache is invalidated. Doesn't seem
to be so with the mainframe. I assume there is a point, where we
"thrash cache", but it seems like when we switch tasks on the mainframe,
your part of cache (instruction cache...stuff within the processor),
seems to stay in tack.
I wish I could find the paper on this to reread it again. Perhaps it
was in the IBM Journal. It would be interesting to reread it now that I
have zLinux experience (Linux is Linux, it is the hardware that makes
the difference.)
Tom Duerbusch
THD Consulting
>>> [EMAIL PROTECTED] 5/17/2006 11:42 AM >>>
[GRAIN TYPE="SALT" MODE="Stand Up Philosopher"]
Just remember:
#1: A mainframe is designed to provide maximum *reliable*
single-thread
performance (per CP) simply because a lot of the business workload
(merge
phase of sortation, for instance, or balancing a b-tree after an
insert)
needs it and errors can't be tolerated.
#2: A mainframe provides maximum I/O connectivity. Granted, as we
move
towards fibre channels we're getting away from this differentiator. I
wish
I had a Shark ESS to play with...
#3: A mainframe excels are maximizing I/O bandwidth across *all*
devices
in order to minimize choke-points, especially when dealing with
databases
(and their key structures).
Think for a moment: the most expensive "simple" arithmetic operation a
CPU
can perform is a divide (integer *or* floating point); likewise the
most
expensive "simple" operation for a DBMS is to "insert a row" (I
learned
about this back in my days dealing with "DIRECT" mode files in
Business
BASIC; even with only one key field this was *slow* on even the
hottest
Unix boxes of the time). Given the use of databases, anything that has
to
be done single thread is going to have to be optimized... and has to,
for
many businesses, be reliable enough to "bet the business" on accurate
results.
As for "new workloads" not fitting the mainframe...
Well, I _think_ some will likely fit pretty well while others won't.
The
same can be said for the other end of the spectrum. It can't be all of
one
or the other, either, since neither viewpoint has a monopoly on truth.
Over time I suspect that some efforts will be made to find the
synergies
across the whole spectrum.
[/GRAIN]
Sorry for the philosophizing but I was desperate for a laugh.
After all, no one listens to Zathras.
-soup
--------------------
John R. Campbell, Speaker to Machines (GNUrd) (813) 356-5322 (t/l
697)
Adsumo ergo raptus sum
MacOS X: Because making Unix user-friendly was easier than debugging
Windows.
Red Hat Certified Engineer (#803004680310286)
----- Forwarded by John Campbell/Tampa/IBM on 05/17/06 12:14 PM -----
Thomas David
Rivers To:
LINUX-390@VM.MARIST.EDU
<[EMAIL PROTECTED] cc:
m> Subject: Re:
[LINUX-390] Who's been reading our list...
Sent by: Linux on
390 Port
<[EMAIL PROTECTED]
IST.EDU>
05/17/06 08:16 AM
Please respond to
Linux on 390 Port
OK - I'm going to play serious devil's advocate here,
at the risk of the ire of several people, I'm sure.
But, I think we need to do something more 'direct'
in terms of refuting the arguments.
I've seen a couple of posts that have a sentiment of
"well - this guy doesn't know what he's talking about."
But - I'd like to see some data and arguments to back up that
sentiment.
If I break down his argument, these are the points I get from it:
1 - A mainframe CPU is about as fast as a PIII
2 - SCSI is SCSI - mainframe SCSI isn't going to be any
better/faster than any other SCSI.
3 - Linux is Linux, running on PC Linux is just as
"good" as mainframe Linux.
4 - Mainframes are awfully expensive for what you
get, given #1-3 above.
5 - The mainframe is very good at running it's legacy
apps, but not the new ones.
Now - how do we break-down the arguments and address them?
Simply jumping up-and-down and saying "nyaa-nyaa - this guy
is wrong" plays directly into his "these guys are a bunch
of clueless zealots who need to be consigned to the back
corner for there mutual back-patting session" idea. I suggest
we don't fall into that trap.
If you have some real data/experience to offer, please make it
known. If not, then we have a problem.
I think we could come up with an argument that says "well,
yes - we did have a PC farm of Linux machines; we consolidated
all of that quite successfully on a mainframe (because of #2 and
#3 above) and had a tremendous cost savings."
Or - something like "yes - the mainframe I/O did, in fact,
run faster than the PC for my DB2 database."
Or - something like "using the advanced backup facilities
on my SHARK, I was able to completely eliminate scheduled
downtime for backups."
Or - something like "using hipersockets allowed me to get
to the z/OS database (where all of the PCs are trying to
get to anyway) and change my average web response time from
M to N, an X% improvement."
Please understand, I'm not necessarily in agreement with this
fellow, but I'd sure like to have a reasoned response. If he
doesn't have a clue, then demonstrate it. Let's beat this
sentiment back with rationality.
- Thanks -
- Dave Rivers -
--
[EMAIL PROTECTED] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
