response 1 of 44:

Jun 25 19:48 UTC 1999

...crunching the same blocks over and over again...

Hm, I may give SETI@home a shot once they've got some of the bugs out...

response 3 of 44:

Jun 25 20:58 UTC 1999

People have tried to run SETI @home here, thus being a pain for the staff to
deal with.

SETI@home claims that it doesn't slow down the computers that it's running
on, since it runs at a low priority, so other tasks take precidence over it.
However, it is a resource hog from the memory standpoint.  It's not a good
thing to have running on Grex.  I wouldn't run it on any computer I wanted
to be able to get work done on either.

response 5 of 44:

Jun 26 01:05 UTC 1999

With plenty of memory, an OS that handles low priority jobs well, and
typical single-user-system usage patterns (lots of CPU idle time),
SETI@home can do its number crunching without having a noticable
effect on system responsiveness.  I know people who run it in the
background on their systems and can't tell the difference in speed. 

However, grex certainly does not fit that description.  Our CPUs' time
is booked solid with "users are sitting there waiting for an immediate
response" tasks virtually all the time.  Running SETI@grex is just a
way to make this system slower for all the human user on it.

response 7 of 44:

Jun 26 03:24 UTC 1999

Besides which, Grex is really not any more powerful than a typical recent
Windows PC.  

response 9 of 44:

Jun 26 16:01 UTC 1999

When I last looked at SETI@home, there were two basic versions:

  - PC version - runs as a screen saver, only starting up after the
    computer has been idle for a few minutes.  Otherwise it doesn't
    run at all.

  - Unix version - runs as a process with a low CPU priority.  Only
    runs when no other process wants to use the CPU.

I installed the Unix version on my Linux box, and ran one block.  My
machine is a 133MHz Pentium with 32 Meg of memory, probably a bit faster
than Grex at a single task.  The block took just over a day to run. 
However during that day, my Linux system was noticably sluggish.  Let's
suppose I had SETI@home running while I was doing what I'm doing now -
typing text into a Netscape window.  Netscape isn't using much CPU - it
spends almost all of its time waiting for me to type the next character.
So since there is CPU available, SETI@home runs a lot.  But Netscape and
SETI@home are both huge memory hogs.  So whenever SETI@home starts
running, it starts grabbing memory, and Netscape starts getting swapped
out to disk.  If I then type again, then Netscape has to be loaded back
into memory before it can respond to my typed key.  Naturally things get
sluggish.  I've had some people tell me that their Unix boxes weren't
slowed much by SETI@home.  This is likely true, if they have lots of
more memory than I do.

For Grex, the situation would be similar.  Though our CPU is much busier
than most single-user systems, it is idle a significant amount of the
time.  This is a good thing.  It means that when you type a key in
something like "vi" or "gate", Grex can respond immediately.  The Sun
4/670 is faster at jumping between jobs than a Pentium is, but that
mainly helps with smaller processes.  Big memory hog processes like
SETI@home are more likely to be slow to switch.

So running SETI@home on Grex would significantly slow it down at what it
does best - juggling lots of tasks for lots of users.  At the same time,
since it doesn't run any single task very fast, it would contribute less
to the SETI@home project than if someone unleashed an idle 486 box on
the project.  It's just not a good deal for us.

The fact that Grex is a lousy place to run this thing shouldn't
necessarily discourage people from running it on their own machines.  If
you have a single user Unix box well-stocked with memory, it likely
won't be a problem.  If you have a Windows machine, the screen saver
version is almost certain not to slow anything down much.  If you've got
an old 486 that you aren't using for anything, bringing that back up to
run SETI@home would at least do more good than putting it on Grex.

response 11 of 44:

Jun 27 17:30 UTC 1999

It's the sort of thing that is most effective as a screen-saver on all of
those high-powered PCs out there.  A 486 from Kiwanis would be *much* better
used as the first computer of somebody with not a lot of money.

(and it's not like the world depends on Grex supplying a processor for running
this thing.  Sheesh.)

response 13 of 44:

Jun 28 15:38 UTC 1999

Do you need to be connected to the net all the time to run seti@home?

response 15 of 44:

Jun 28 16:26 UTC 1999

How long does it take to download a unit?

response 17 of 44:

Jul 7 00:02 UTC 1999

   I think others have spoken quite well on the reasons why not to run
Seti here, as much as I like it myself.  Grex would be home to an ET
Rane, if we had the horsepower.  However I don't think a public access
system like Grex will ever have the ability to do so.

response 19 of 44:

Jul 17 13:17 UTC 1999

I think the seti@home program works on much bigger blocks of data than
the rc5 thing, and thus uses more memory, which I think is at the root
of the problem.

response 21 of 44:

Jul 27 16:49 UTC 1999

if I ever get back up to A2 I'll bring some 486 MB's, I'm not sure when
I"ll be back up there though

response 23 of 44:

Nov 28 05:07 UTC 1999

The SETI@home program for Grex (Sun OS) doesn't cause a noticable load.
It does crash though.  I sent them a message about it.  A reply may have
come while my id was reaped.