RE: dean of students and Deschall...

Dan Oetting (oetting@gldfs.cr.usgs.gov)
Tue, 6 May 1997 11:37:57 -0600


Adam Haberlach <HaberlaA@testlab.orst.edu> wrote:

>From: Colin L. Hildinger [SMTP:colin@ionet.net]
>Sent: Monday, May 05, 1997 11:49 PM
>To: a psychedelic psychopath; deschall@gatekeeper.megasoft.com
>Subject: Re: dean of students and Deschall...
>
>On Tue, 6 May 1997 02:22:56 -0400 (EDT), a psychedelic
>psychopath
>wrote:
>
>>>our little group here at wmu decided to run deschall on two
>>>groups of sparcs5/20s. one sysadmin just killed the jobs for
>>>various "too much load" and other reasons. the other shut off
>>>our accounts and reported us to the dean. *sigh*
>
>>Hmmm, could you rename it to report some acedemic program's
>>name? ;-)
>
> This does bring up a good point--it's probably a better idea to
>clear it with the sysadmin BEFORE you ramp the load up on all of
>his machines. They're usually pretty twitchy around here, and
>our effort got somewhat bolloxed by this (ie, we can't run it on
>.engr.orst.edu machines [well, I do when I'm logged in]). If
>you've been reported to the dean of students, you're probably
>really screwed...

You could also point out to the sysadmin one other advantage of running the
deschall clients in the idle cycles. It's posible for stelth programs to be
running undetected under almost any OS. By running a known cpu hog the
sysadmin could detect when the total accounted cpu time doesn't add up. And
since the deschall clients are doing real work thats constantly verified by
the keyserver, a program that tries to adjust the cpu stats of the client
would also be detectable.

I have one Sun Ultra-1 that would consistantly run the deschall-ultra
client at the speed of a Sparc-4 with no other active jobs and an initial
cpu load of 0.0 After rebooting last night the client on this server
performs at the same level as the other Ultra-1 clients. Did I have a
stelth program eating up cpu cycles? I don't know! But DESCHALL is going to
be there if it ever tries to come back!

-- Dan Oetting <oetting@gldfs.cr.usgs.gov>