[GE users] Re: Matlab integration
Andreas.Haas at Sun.COM
Wed Mar 15 17:47:53 GMT 2006
On Wed, 15 Mar 2006, Bernd Dammann wrote:
> > > 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.
Possibly I should have been more clear with my question:
Which component needs to know job/task status? Is it a Matlab
client component that is ran by each user or is it some kind
of server component with just a single instance?
> > 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.
There is no possibility to cheat ... maybe ... little?
> > 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.
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