Hi Rayson,<div><br></div><div>Let me first say thanks for OGS, its a super useful tool!</div><div><br></div><div>So, an update....</div><div>I realized that the parameter was load_report_time in the global configuration.</div>
<div>The delay was basically exactly load_report_time, and so I have set it to 0, and the delay is basically gone...</div><div><br></div><div>Rayson, here is my global configuration (qconf -sconf), any comments? Particularly, is it okay to have a value of zero for load_report_time?</div>
<div><br></div><div>$ qconf -sconf</div><div><div>#global:</div><div>execd_spool_dir /opt/sge6/default/spool</div><div>mailer /bin/mail</div><div>xterm /usr/bin/X11/xterm</div>
<div>load_sensor none</div><div>prolog none</div><div>epilog none</div><div>shell_start_mode posix_compliant</div><div>login_shells sh,bash,ksh,csh,tcsh</div>
<div>min_uid 0</div><div>min_gid 0</div><div>user_lists none</div><div>xuser_lists none</div><div>projects none</div><div>xprojects none</div>
<div>enforce_project false</div><div>enforce_user auto</div><div>load_report_time 00:00:00</div><div>max_unheard 00:05:00</div><div>reschedule_unknown 02:00:00</div>
<div>loglevel log_warning</div><div>administrator_mail <a href="mailto:none@none.edu">none@none.edu</a></div><div>set_token_cmd none</div><div>pag_cmd none</div>
<div>token_extend_time none</div><div>shepherd_cmd none</div><div>qmaster_params none</div><div>execd_params none</div><div>reporting_params accounting=false reporting=false \</div>
<div> flush_time=00:00:15 joblog=false sharelog=00:00:00</div><div>finished_jobs 100</div><div>gid_range 20000-20100</div><div>qlogin_command builtin</div>
<div>qlogin_daemon builtin</div><div>rlogin_command builtin</div><div>rlogin_daemon builtin</div><div>rsh_command builtin</div><div>rsh_daemon builtin</div>
<div>max_aj_instances 2000</div><div>max_aj_tasks 75000</div><div>max_u_jobs 0</div><div>max_jobs 0</div><div>max_advance_reservations 0</div><div>auto_user_oticket 0</div>
<div>auto_user_fshare 0</div><div>auto_user_default_project none</div><div>auto_user_delete_time 86400</div><div>delegated_file_staging false</div><div>reprioritize 0</div><div>
jsv_url none</div><div>jsv_allowed_mod ac,h,i,e,o,j,M,N,p,w</div></div><div><br></div><div><br><div class="gmail_quote">On Wed, Sep 5, 2012 at 12:52 PM, Rayson Ho <span dir="ltr"><<a href="mailto:raysonlogin@gmail.com" target="_blank">raysonlogin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Sep 5, 2012 at 1:10 PM, Jesse Lu <<a href="mailto:jesselu@stanford.edu">jesselu@stanford.edu</a>> wrote:<br>
> However, if I run in a parallel environment (e.g. qsub -pe orte ...) then<br>
> there is an approximately 40 sec delay after job completion. That is to say,<br>
> the job has technically finished, although qstat still lists it as running,<br>
> and subsequent jobs are held up. Any ideas?<br>
<br>
</div>That's fixed in the update release.<br>
<div class="HOEnZb"><div class="h5"><br>
Rayson<br>
<br>
==================================================<br>
Open Grid Scheduler - The Official Open Source Grid Engine<br>
<a href="http://gridscheduler.sourceforge.net/" target="_blank">http://gridscheduler.sourceforge.net/</a><br>
<br>
<br>
><br>
> Thanks in advance!<br>
><br>
><br>
> On Tue, Sep 4, 2012 at 5:33 PM, Rayson Ho <<a href="mailto:raysonlogin@gmail.com">raysonlogin@gmail.com</a>> wrote:<br>
>><br>
>> That's the default scheduling time, and if you really want the<br>
>> scheduler to react to your qsub requests ASAP, you can turn on<br>
>> "scheduling-on-demand":<br>
>><br>
>> <a href="http://gridscheduler.sourceforge.net/howto/tuning.html" target="_blank">http://gridscheduler.sourceforge.net/howto/tuning.html</a><br>
>><br>
>> And in OGS/GE 2011.11 u1 p1 (we need a better name), the time it takes<br>
>> to report job done should be reduced.<br>
>><br>
>> Rayson<br>
>><br>
>> ==================================================<br>
>> Open Grid Scheduler - The Official Open Source Grid Engine<br>
>> <a href="http://gridscheduler.sourceforge.net/" target="_blank">http://gridscheduler.sourceforge.net/</a><br>
>><br>
>><br>
>><br>
>> On Tue, Sep 4, 2012 at 8:05 PM, Jesse Lu <<a href="mailto:mr.jesselu@gmail.com">mr.jesselu@gmail.com</a>> wrote:<br>
>> > Yes! Exactly.<br>
>> ><br>
>> > -- Jesse<br>
>> > ________________________________<br>
>> > On Sep 4, 2012 4:19 PM, Rayson Ho <<a href="mailto:raysonlogin@gmail.com">raysonlogin@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi Jesse,<br>
>> ><br>
>> > Are you referring to the scheduling time of Grid Engine??<br>
>> ><br>
>> > Rayson<br>
>> ><br>
>> > ==================================================<br>
>> > Open Grid Scheduler - The Official Open Source Grid Engine<br>
>> > <a href="http://gridscheduler.sourceforge.net/" target="_blank">http://gridscheduler.sourceforge.net/</a><br>
>> ><br>
>> ><br>
>> > On Tue, Sep 4, 2012 at 6:37 PM, Jesse Lu <<a href="mailto:jesselu@stanford.edu">jesselu@stanford.edu</a>> wrote:<br>
>> >> Hi StarCluster users,<br>
>> >><br>
>> >> I've noticed long delays with Sun Grid Engine when submitting jobs and<br>
>> >> especially after job execution. Even running a simple "hostname" job<br>
>> >> takes<br>
>> >> several seconds. Moreover, running an MPI version of "hostname" can<br>
>> >> take 2<br>
>> >> minutes!!<br>
>> >><br>
>> >> Can someone help me get rid of this delay? Thank you.<br>
>> >><br>
>> >> Jesse<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> StarCluster mailing list<br>
>> >> <a href="mailto:StarCluster@mit.edu">StarCluster@mit.edu</a><br>
>> >> <a href="http://mailman.mit.edu/mailman/listinfo/starcluster" target="_blank">http://mailman.mit.edu/mailman/listinfo/starcluster</a><br>
>> >><br>
><br>
><br>
</div></div></blockquote></div><br></div>