The Search For Extra Terrestrial Intelligence on AS/400

Some of you have begun to run the SETI at Home for AS/400
client or have heard about it.  (If you don't know what
"SETI" is, see farther down).  Those of you who've heard of AS/400
SETI may have wondered about items like "why does it require PASE"
and "what performance should I expect if I run the SETI client
on my AS/400."

Some of these questions were raised earlier on this mailing list.

Here's some answers.

But first, an important disclaimer.  I had a lot to do with getting this
thing into existence, but this is _not_ an official, IBM product
even though I work on AS/400 for IBM.  This was a labor
of love on my own time.  IBM let me steal some spare cycles here
and there to test it, but that's no more than other vendors have
done.  Don't imply any sort of IBM endorsement, ownership, etc.
I have never seen the SETI source code, in fact.

On that same line, the author was one Chris Graham, an non-IBMer
and a non-AS/400 owner, who himself received the source code from the
SETI scientists.  Mr. Graham deserves the lion's share of the credit for
making
this a reality.  More on this in a moment.


Question:  What is SETI at home?

See http://www.setiathome.ssl.berkeley.edu for details.  The short answer
is that many scientists think we can detect alien civilizations by doing
some basic analysis of radio waves received from space.  Turns out
that, whether used for TV programs or navigation beacons, some
standard analysis can separate probable artificial radio signals from
natural
ones.  Once data from a radio telescope is recorded, it can be divided
up into work units.  These can be downloaded, and processed later on using
any
computer, anywhere, provided it has the SETI software.  SETI at home is
done
mostly on home PCs, but many servers also run the software, so the "at
home"
is a bit of a misnomer now.  AS/400 now participates in this via PASE.


Question:  Why PASE?

PASE, Portable Application Solutions Environment, is available to allow
AS/400 to run AIX (Unix) applications with minimal software change.  It
proves the ability to run nearly identical binaries to AIX packages which
(for any number of reasons) are not worth a full port to native AS/400
POSIX and ILE C.

SETI is a good example for using PASE.  For SETI, PASE was
simple, expedient, and runs fast.  Like many others, I found out about
the SETI project and was intrigued.  A few e-mails told me there was no
AS/400 version of SETI.  The exchanges also convinced me that someone could
use the PASE environment to deliver a SETI client for AS/400, probably
without
a lot of work.  Since this is a volunteer effort, low effort was very
important.

So, a few more e-mails later, Mr. Graham, who did the AIX
"port," graciously agreed to make separate modifications from his
existing AIX client to run SETI under PASE.  This was a low
priority, labor-of-love for both of us.  If it was a regular, for-pay
assignment,
it would have probably taken, at most, a week.  In real life, it took a bit
longer.  The upshot was, that we have a version
of the code that is _not_ identical to the AIX version and which will run
on
PASE using either V4R4 or V4R5.  (So don't try the AIX version; it won't
quite work -- download the AS/400 version and all will be well.  See
http://www.setiathome.ssl.berkeley.edu/unix.html to download it).

PASE is not, nor is it intended to be, a complete AIX.  That means there
will be missing interfaces that have to be worked around for many
PASE projects.  Since the usual reality applies (80% of the code uses
20% of the interfaces), this need not be a great number.  In the
case of SETI, it came down to about three missing interfaces.

The main difference from AIX is that AS/400's SETI will charge the client
on a "wall clock" basis instead of a "CPU consumed" basis; AIX's will
charge for "CPU consumed".  This is due to a V4R4 restriction.  So,
cancel SETI jobs; don't "hold" them (don't HLDJOB).  As it happens,
this is not a big deal in the context of SETI.  All SETI clients
checkpoint;
they expect to be cancelled because they're supposed
to be low priority, when-time-permits kinds of function.  So, a cancel
means little work lost.


Question: What Kind of Performance Can I Expect?

On the latest and greatest machines, performance is quite good:  I have
seen times of 4 and 3/4 hours per SETI work unit on some 820/830 class
machines.
The newer 270s come in a little slower at 5 1/2 - 6 hours (using 270 2252,
a 950
Batch CPW rating).  The amount of time any individual SETI
work unit takes varies somewhat; at least by 20%.  Since multi-processors
can simply run one job per physical CPU and since SETI scales very well,
a 830 2402 (a 4-way) would do 4 3/4 hours per work unit _per CPU_.  Thus,
while
the fastest time per work unit is about the same as for the fastest
uniprocessor,
four jobs get you, of course, four times the throughput.  Anyone familiar
with SETI
would find about 18-20 work units of work per day for one machine to be a
great result,
presuming you had a day to waste on SETI for an 830 class 4-way ;-).

What about an "older" machine, like a 170 2385?  It takes about 10 - 11
hours
per work unit (with a 460 Batch CPW).

These are, of course, dedicated timings.

As you can see, Batch CPW is not a perfect predictor, but reasonably close.
For MPs, dividing the Batch CPW by the number of CPUs should over-estimate
the time for one work unit on one CPU a bit if you ratio it to the 270 2252
I give above,
but would still be "in the ballpark".

The 820/270 performance stacks up well against many competitive machines.
For instance, most Intel of the 500 MHz class machines are about 9 to
10 hours; only the high end Xeon IIIs with 1 MB L2 caches come
in at the 5 hour range.

As for disk and main storage, requirements are modest.  SETI takes
something
like 3 MB of disk overall and (a correspondent told me) about 32 MB of
main storage while executing at priority 99.




Larry W. Loen  -   speaking for himself
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---