[GE users] Re: Matlab integration

Charu Chaubal Charu.Chaubal at Sun.COM
Wed Mar 15 18:36:14 GMT 2006


    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

Hi Bernd,

Bernd Dammann wrote On 03/15/06 07:43,:

>Dear Andreas,
>
>  
>
>>I hope there is no reason not to talk about this in
>>public. Please find my replies below.
>>
>>    
>>
>That's ok with me.
>
>  
>
>>>Right now we are using something like 'qstat | grep jobID', which
>>>gives a substantial overhead, because this is called frequently from
>>>Matlab to check the status of the tasks.
>>>      
>>>
>>Generally there are means to lessen the overhead. I'm curious
>>however what kind of synchronization that is? Possibly it is
>>related to the "status files" you mention below?
>>
>>    
>>
>Maybe I wasn't clear enough:  What we need is the status of a job/task,
>like 'qw', 't', 'r', etc, and this is only available if one does a qstat
>for the whole system.  So the overhead comes from the piping into grep
>and the post-processing.
>
>  
>
>>Qsub as-is does not support multiple ranges. Though that limitation
>>is only due to client-side qsub parsing code, but nevertheless the
>>limitation exists. Possibly one can work around that by submitting
>>an array job for each range?
>>
>>    
>>
>No, one can't, because Matlab DCT considers a job as consisting of
>several tasks - splitting it up means create more than one job ID,
>which is not feasible.
>
>  
>
Perhaps you can take advantage of the ability in N1GE to give arbitrary 
names to jobs.  You can submit a job using 'qsub -N <name> job.sh', and 
then use 'qdel <name>' 'qmod -sj <name>' etc.  The nice thing is that, 
if you give the same name to more than one job, then these operations 
work on all those jobs simultaneously, so you could, eg, suspend or kill 
all the jobs as a group. 

So, all you would need to do is generate a unique job name, and then use 
this name for all jobs within a single group --- seems easier than 
tracking job IDs.

Regards,
    Charu

>>I understand this makes it somewhat uncomfortable. Nevertheless
>>having it working at first with shared file system constraint
>>only may be already usable for others.
>>
>>    
>>
>I agree, and I also see this as a minor problem.  As far as I remember,
>a shared filesystem is also a requisite for the built-in JobManager in
>DCT, so it has the same limitation.
>
>  
>
>>Never had problems with GridWiki.
>>    
>>
>
>Works again for me (at least where I am now) - it's the loading of the
>.js file that created problems, because the server didn't resolve in
>our DNS. :-(
>
>Regards,
>Bernd
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
>For additional commands, e-mail: users-help at gridengine.sunsource.net
>
>  
>

-- 
####################################################################
# Charu V. Chaubal              # Phone: (650) 786-7672 (x87672)   #
# Grid Computing Technologist   # Fax:   (650) 786-4591            #
# Sun Microsystems, Inc.        # Email: charu.chaubal at sun.com     #
####################################################################

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list