Thanks. I will see if I can reproduce that here.<br><br>Ken<br><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 4:21 PM, Burkhard Bunk <span dir="ltr">&lt;<a href="mailto:bunk@physik.hu-berlin.de" target="_blank">bunk@physik.hu-berlin.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
the problem shows up if a queue does not have a limit on walltime<br>
or if an array job is queried as a whole (elapsed time is undefined,<br>
I guess).<br>
<br>
Example 1: no limit on Elapsed Time =&gt; 00:00:00<br>
<br>
                                              Req&#39;d       Elap<br>
        Job ID                  ...           Time    S   Time<br>
        ----------------------- ----------- --------- - ---------<br>
        4119.gargamel.physik.h  ...               --  R  00:00:00<br>
<br>
&quot;qstat -f&quot; does show the correct resources_used.walltime.<br>
The info is there, the problem is with the display by qstat on the client side.<br>
<br>
Example 2: compact display of array job shows &quot;Elap Time&quot; = &quot;Req&#39;d Time&quot;.<br>
<br>
                                              Req&#39;d       Elap<br>
        Job ID                  ...           Time    S   Time<br>
        ----------------------- ----------- --------- - ---------<br>
        60603[].irz14.physik.h  ...         720:00:00 R 720:00:00<br>
<br>
If &quot;Req&#39;d Time&quot; is unset, I see &quot;Elap Time&quot; = 00:00:00 .<br>
I would prefer the behavior of 2.5.11: &quot;Elap Time&quot; = -- .<br>
<br>
Explicit display of array members (qstat -at) is correct:<br>
<br>
        60603[2].irz14.physik.  ...         720:00:00 R  08:00:25<br>
<br>
<br>
All that is easy to understand, given the fact that qstat.c in 2.5.13 tries to compute<div class="im"><br>
<br>
        elap_time = req_walltime - rem_walltime<br>
<br></div>
which doesn&#39;t work if &quot;Requested Time&quot; or &quot;Remaining Time&quot; is undefined<br>
(falls back to zero).<div class="im HOEnZb"><br>
<br>
Regards,<br>
Burkhard Bunk.<br>
------------------------------<u></u>------------------------------<u></u>----------<br>
 <a href="mailto:bunk@physik.hu-berlin.de" target="_blank">bunk@physik.hu-berlin.de</a>      Physics Institute, Humboldt University<br>
 fax:    <a href="tel:%2B%2B49-30%202093%207628" value="+493020937628" target="_blank">++49-30 2093 7628</a>     Newtonstr. 15<br>
 phone:  <a href="tel:%2B%2B49-30%202093%207980" value="+493020937980" target="_blank">++49-30 2093 7980</a>     12489 Berlin, Germany<br>
------------------------------<u></u>------------------------------<u></u>----------<br>
<br></div><div class="HOEnZb"><div class="h5">
On Thu, 1 Aug 2013, Ken Nielson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Burkhard,<br>
<br>
I looked at the output of qstat -a and the elapsed time seems to be working as<br>
expected to me. What are you getting and what do you expect?<br>
<br>
Ken<br>
<br>
On Thu, Aug 1, 2013 at 11:09 AM, Burkhard Bunk &lt;<a href="mailto:bunk@physik.hu-berlin.de" target="_blank">bunk@physik.hu-berlin.de</a>&gt;<br>
wrote:<br>
      Hi,<br>
<br>
      unfortunately the behavior of &quot;Elapsed Time&quot; in &quot;qstat -a&quot; is<br>
      still<br>
      slightly screwed up, as reported two days ago.<br>
<br>
      The problem is in src/cmds/qstat.c:<br>
      &quot;eltimewal&quot; was replaced by &quot;elap_time_string&quot;, which is computed<br>
      from<br>
      &quot;rem_walltime&quot; in<br>
<br>
          878     if ((*jstate != &#39;Q&#39;) &amp;&amp; (*jstate != &#39;C&#39;))<br>
          879       {<br>
          880       elap_time = req_walltime - rem_walltime;<br>
          881       time_to_string(elap_time_<u></u>string, elap_time);<br>
          882       }<br>
<br>
      This will fail if &quot;req_walltime&quot; is not available.<br>
<br>
      I fixed it by reverting to &quot;eltimewal&quot; in the print statements<br>
      (lines 904 and 924), and it works for me.<br>
<br>
      This is a preliminary hack, not a real fix. I&#39;m sure that the<br>
      &quot;elap_time_string&quot; mechanism was introduced for a reason (which I<br>
      don&#39;t understand), and it should be fixed accordingly.<br>
<br>
      Regards,<br>
      Burkhard Bunk.<br>
      ------------------------------<u></u>------------------------------<u></u>----------<br>
       <a href="mailto:bunk@physik.hu-berlin.de" target="_blank">bunk@physik.hu-berlin.de</a>      Physics Institute, Humboldt<br>
      University<br>
       fax:    <a href="tel:%2B%2B49-30%202093%207628" value="+493020937628" target="_blank">++49-30 2093 7628</a>     Newtonstr. 15<br>
       phone:  <a href="tel:%2B%2B49-30%202093%207980" value="+493020937980" target="_blank">++49-30 2093 7980</a>     12489 Berlin, Germany<br>
      ------------------------------<u></u>------------------------------<u></u>----------<br>
<br>
      On Wed, 31 Jul 2013, Ken Nielson wrote:<br>
<br>
            Hi all,<br>
<br>
            I have fixed the last reported but with 2.5.13. The<br>
            download is available<br>
            through GitHub. You can download it with the following<br>
            command.<br>
<br>
            git clone<br>
            <a href="https://github.com/adaptivecomputing/torque.git" target="_blank">https://github.com/<u></u>adaptivecomputing/torque.git</a> -b<br>
            2.5.13 2.5.13<br>
<br>
            Please let us know right away of any major problems.<br>
<br>
            Regards<br>
<br>
            --<br>
            Ken Nielson<br>
            <a href="tel:%2B1%20801.717.3700" value="+18017173700" target="_blank">+1 801.717.3700</a> office <a href="tel:%2B1%20801.717.3738" value="+18017173738" target="_blank">+1 801.717.3738</a> fax<br>
            1712 S. East Bay Blvd, Suite 300  Provo, UT  84606<br>
            <a href="http://www.adaptivecomputing.com" target="_blank">www.adaptivecomputing.com</a><br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
torqueusers mailing list<br>
<a href="mailto:torqueusers@supercluster.org" target="_blank">torqueusers@supercluster.org</a><br>
<a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/<u></u>mailman/listinfo/torqueusers</a><br>
<br>
<br>
<br>
<br>
--<br>
Ken Nielson<br>
<a href="tel:%2B1%20801.717.3700" value="+18017173700" target="_blank">+1 801.717.3700</a> office <a href="tel:%2B1%20801.717.3738" value="+18017173738" target="_blank">+1 801.717.3738</a> fax<br>
1712 S. East Bay Blvd, Suite 300  Provo, UT  84606<br>
<a href="http://www.adaptivecomputing.com" target="_blank">www.adaptivecomputing.com</a><br>
<br>
<br>
</blockquote>
</div></div><br>_______________________________________________<br>
torqueusers mailing list<br>
<a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
<a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Ken Nielson<br>+1 801.717.3700 office +1 801.717.3738 fax<br>1712 S. East Bay Blvd, Suite 300  Provo, UT  84606<br><a href="http://www.adaptivecomputing.com" target="_blank">www.adaptivecomputing.com</a><br>
<br>