Conference 44.370::system_management

We would certainly exploit such a facility within SIM, and presumably, if 
that node is *only* batch, in effect, on a good day, we would get 
"interactive speed" compilations - quite a good carrot I would have 
thought.

Jerry

    
    This is a very good idea. I started to implement batch mode
    compilations on VULCAN but have not worked on it since it became
    clear that VULCAN would be going away. I have 'nearly finshed'
    developing a PASCAL program that provides the developer with a DCL command
    'MAKE' which enables a batch mode precompile and/or compilation
    followed by inserting the completed module into the project object
    library. There are also swithches for optimise and debug compilations
    and further swithches could be provided if needed. Since all of
    the file searching and validation is done via PASCAL as opposed
    to the ususal DCL command file this process is fairly quick.
    
    If someone wants to do the work I'm sure this approach could be
    developed further to provide a 'PLINK' i.e batch mode project link
    command.
    
    Yours,
    
    Pete' Platt
    

    No , but it might take us back a few decades in the way we work
    
    If you correctly set up the generic cluster wide batch queues the
    the cluster will make a reasonable attempt at balancing batch loads
    across the 3 x 785s. The only time it makes sense to dedicate a
    specific processor to batch work is when you have a real engine
    in the cluster (8650 etc) and you have a guarenteed batch v interactive
    processing profile. Otherwise yo will end up with a dedicated batch
    processor sitting idle at the times of no batch work.
    
    Chris...
    

    Just to follow on from the previous reply . The EUC cluster runs
    both interactive development and HUGE production batch jobs.
    
    We have the queues set up so that on submition to SYS$BATCH (the
    default) the job is submitted to the least loaded processor.
    
    As we tend to do all the interactive work on RDGE21 the jobs batch
    jobs invariably hit RDGE26 as the load balancing algorithm takes
    into account the number of interactive session on each of the two
    nodes. At night when there are no interactive sessions the batch
    jobs are spread evenly across the two machines.
    
    In practice this works well and we NEVER get any noticable degredation
    of interactive performance.
    
    Anyway my message is DO NOT partition the cluster. Leave it to its
    own devices. Despite waht you may have heard it will in most cases
    make the best use of the processing power available to it without
    degrading the interactive performance.
    
    Chris...
    

    To make life even better set up a LAT service alias for the cluster.
    This does in a rather cruder fashion for the interactiv users what
    the batch load balancing algorithm does for the batch jobs.
    
    Intead of connecting to a specific node in the cluster you connect
    to an alias defined as a LAT service. This will then place you on
    what the LAT considers to be the least loaded proicessor by
    interagating the cluster itself. 
    
    Chris...
    

re:- < Note 23.3 & 23.4 by RDGE21::MORRIS >

    Thanks, Chris,  good  input.    Even  if  we  don't  partition the
    cluster, is it  still  worth  switching to batch compile and link,
    along the lines suggested  in  previous replies?  That is, is this
    more effective than doing so interactively and letting the cluster
    manage the workload?
    
Tony.

From what Chris has said, I would say that re: .1, I stand corrected. Vms 
can probably load balance better than we can.

Vote withdrawn :-)

Jerry

    How longs a piece of string ?
    
    The loads on the machines are the same irrespective of wether they
    are running interactive or batch.
    
    You could adopt a policy of first and second class service by imposing
    job limits and lower priorities on the batch queues , that theoretically
    would give the interactive user and edge over batch. I suspect that
    if you did this in practice all that would happen is that the
    developers , frustrated by the slow batch response for compilations,
    will return to doing it interactivelly . Net result - back to were
    you started.
                                 
    My suggestion is set it up simply , generic batch queues at Prio=4,and
    joblims = 6 generic and 3 local. Then see what happens. Lets not
    solve a problem that I honestly believe doesnt exist once you get
    into the cluster environment. (there are a lot of others that do
    though !)
    
    chris...
    
     

re:- < Note 23.8 by RDGE21::MORRIS >

>    Lets not solve a problem that I honestly believe doesnt exist once
>    you get into  the cluster environment.  (there are a lot of others
>    that do though !)
    
Nuff  said!    Unless   someone  comes  up  with  a  good  reason  for
resurrecting this idea, it is hereby interred.

Tony.