1: Two years ago, when a colleague had root access to our
   2: lab's SUN 4500s (8 processors each, each running at 500mhz),
   3: we decided that all those spare processor cycles were
   4: going to waste.  With his knowledge of UNIX calls and
   5: my affinity for perl, we came up with a SETI runner which
   6: fired up new instances when the system was idle, and
   7: killed instances when the system load went up.
   8: 
   9: 
  10: my $uptime       = "uptime";  # or whatever it's called...
  11: 
  12: my $setiRoot     = '/usr/bin/seti';
  13: my $setiBinary   = 'setiathome';
  14: my $setiFlags    = '';
  15: my $setiLog      = 'seti.log';
  16: 
  17: my $napTime      = 2;
  18: 
  19: my $maxInstances = 8;    # maximum number of SETI instances
  20: my $minInstances = 0;    # minimum number of SETI instances
  21: my $lowThreshold = 8.00; # start SETI
  22: my $hiThreshold  = 9.00; # stop SETI
  23: 
  24: my @setiPids;            # pid array
  25: 
  26: while(1)
  27: {
  28:    sleep( $napTime );
  29:    
  30:    my $uptime = `$uptime`;
  31:    
  32:    $uptime = $1 if $uptime =~ /load average: (\d+\.\d\d)/;
  33: 
  34:    print STDERR "load average: $uptime\n";
  35:    
  36:    #
  37:    # if the uptime is below a certain load,
  38:    # then fire up a new SETI instance.
  39:    #
  40:    &startSETI
  41:       if ( ($uptime < $lowThreshold) && (@seti < $maxInstances) );
  42:    
  43:    #
  44:    # if the uptime is above a certain load,
  45:    # then kill a SETI instance.
  46:    #
  47:    &stopSETI
  48:       if ( ($uptime > $hiThreshold) && (@seti > $minInstances) );
  49: }
  50: 
  51: #
  52: # Organize our list of PIDs
  53: #
  54: sub startSETI
  55: {
  56:    print STDERR "Firing up a SETI...\n";
  57:    print STDERR "We have ", scalar( @setiPids ), " PIDs:\n";
  58:    print STDERR join( " ", @setiPids ), "\n";
  59:    # list all processes
  60:    my $number = scalar( @setiPids );
  61:       
  62:    chdir( "$setiRoot/seti$number" );
  63:    
  64:    print STDERR "Working directory: $setiRoot/seti$number\n";
  65:    
  66:    push( @setiPids, `$setiBinary $setiFlags > $setiLog` );
  67: }
  68: 
  69: #
  70: # Quick and dirty killer
  71: #
  72: sub stopSETI
  73: {
  74:    print STDERR "Shutting down a SETI...\n";
  75:    
  76:    kill 9, pop @setiPids;
  77: }

Replies are listed 'Best First'.
Re: Perl ran SETI@Home for us.
by qslack (Scribe) on Nov 27, 2001 at 06:01 UTC
    I might be just completely blind, but here you use the array @seti:
    &startSETI if ( ($uptime < $lowThreshold) && (______@seti______< $maxInstan +ces) ); # # if the uptime is above a certain load, # then kill a SETI instance. # &stopSETI if ( ($uptime > $hiThreshold) && (______@seti______ > $minInstan +ces) );
    (emphasis with __s mine) But you never put anything in the array. Typo?

    Anyways, thanks for this -- it's a great idea. I have a couple of machines with some unused CPU cycles, so I'll go ahead and install this.

    Quinn Slack
    perl -e 's ssfhjok qupyrqs&&tr sfjkohpyuqrspitnrapj"hs&&eval&&s&&&'
      @seti is being used in a scalar context here, to get the number of elements in the array. To be sure, it would have been better to use if( scalar @seti < $max ), but it is of no great import.

      To get a feel for how this works, you can play around with

      perl -le 'print @ARGV > 2 ? "more" : "less"'

      ... with more or less parameters following on the command line.

      update: oops, didn't realise this was a typo issue.

      --
      g r i n d e r
        I'm pretty sure that's not what qslack meant. @seti isn't declared anywhere. The author most likely meant to use @setiPids. use strict indeed.

        [ ar0n -- want job (boston) ]

      You're absolutely right. Upon inspection, the
      array is probably @setipids (or was it @setiPids?).
      Thanks for the typo catch. You've got my vote for
      today.

      Rob

Re: Perl ran SETI@Home for us.
by Fatty Lumpkin (Acolyte) on Dec 12, 2001 at 02:02 UTC
    I am curious, why couldn't you just keep it always running and nice the process to like 19 or something? Wouldn't this have the desired effect?

    -Fatty Lumpkin
      Ah, a discerning question.

      Well, when the equipment was running our softswitch code,
      a number of processes would be launched and design was very
      picky about what was running on the system with their
      software. So we needed to sense an uptick in resource use
      and shut down processes. This way, when errors popped
      up, they wouldn't have to worry if SETI@Home were somehow
      to blame.

      Unfortunately, when problems did pop up, they did a ps and
      saw "setirunner". In other words, we unfortunately named
      the script poorly, and it was easily picked out. We should
      have named it something unobtrusive... something vaguely
      UNIX-system-like. Ah, well.

      Rob