incorrect "Last Duration" showing up

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

incorrect "Last Duration" showing up

rja84
I'm using Hudson ver. 1.127 and have just noticed that the "Last Duration" for one of my build projects has been reporting exactly "1 hour" anytime the build takes longer then one hour.  I've searched the users and issues mailing list archives and have only come across Issues 108 and 146 discussing incorrect "Last Duration" times, but those are over a year old and don't think they're related.

I've gone through the ./log file in each of my build directories and see:

$ grep duration */build.xml
2007-08-14_17-26-22/build.xml:  <duration>4558191</duration>
2007-08-15_01-01-07/build.xml:  <duration>4389343</duration>
2007-08-15_02-14-16/build.xml:  <duration>4375297</duration>
2007-08-16_01-01-07/build.xml:  <duration>2760153</duration>
2007-08-16_08-43-01/build.xml:  <duration>6668911</duration>
2007-08-16_12-21-52/build.xml:  <duration>6448552</duration>
2007-08-16_14-36-52/build.xml:  <duration>5659179</duration>

The one build which had the duration of 2760153 (which was a failed build, which is why it's build time is so short) correctly shows up with "Took 46 minutes.  All of the other builds show "Took 1 hour" on their build page.  If I go to the "trend" chart, the chart shows the correct number of minutes ranging from the low time of 46 minutes up to a high time of 111 minutes.

Any ideas?  Is there something else I should be checking that might help out?

Thanks... 



Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

rja84
Anyone?  Any ideas on why builds over 60 minutes always report back 1hour?  I just checked, and a second project I have has been over 60 minutes a few times, and it too is reporting back as just "1 hour".

Or, is this just a bug and does an issue need to be filed about it?

Thanks...

On 8/16/07, richard alanis <[hidden email]> wrote:
I'm using Hudson ver. 1.127 and have just noticed that the "Last Duration" for one of my build projects has been reporting exactly "1 hour" anytime the build takes longer then one hour.  I've searched the users and issues mailing list archives and have only come across Issues 108 and 146 discussing incorrect "Last Duration" times, but those are over a year old and don't think they're related.

I've gone through the ./log file in each of my build directories and see:

$ grep duration */build.xml
2007-08-14_17-26-22/build.xml:  <duration>4558191</duration>
2007-08-15_01-01-07/build.xml:  <duration>4389343</duration>
2007-08-15_02-14-16/build.xml:  <duration>4375297</duration>
2007-08-16_01-01-07/build.xml:  <duration>2760153</duration>
2007-08-16_08-43-01/build.xml:  <duration>6668911</duration>
2007-08-16_12-21-52/build.xml:  <duration>6448552</duration>
2007-08-16_14-36-52/build.xml:  <duration>5659179</duration>

The one build which had the duration of 2760153 (which was a failed build, which is why it's build time is so short) correctly shows up with "Took 46 minutes.  All of the other builds show "Took 1 hour" on their build page.  If I go to the "trend" chart, the chart shows the correct number of minutes ranging from the low time of 46 minutes up to a high time of 111 minutes.

Any ideas?  Is there something else I should be checking that might help out?

Thanks... 




Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

Stephen Connolly-2
Once a build goes over 1 minute, the duration does not report how many
seconds it will take, the duration reports to the nearest minute.

When a build goes over 60 minutes, it is reported to the nearest hour,
so 90 minutes and 1 second will be reported as 2 hours while 89 minutes
and 59 seconds will be 1 hour (afaik)

This has always been the case since we started using hudson back around
version 1.40ish

As to whether this is a bug or a feature is a different question!!!

-Stephen Connolly



richard alanis wrote:

> Anyone?  Any ideas on why builds over 60 minutes always report back
> 1hour?  I just checked, and a second project I have has been over 60
> minutes a few times, and it too is reporting back as just "1 hour".
>
> Or, is this just a bug and does an issue need to be filed about it?
>
> Thanks...
>
> On 8/16/07, *richard alanis* < [hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I'm using Hudson ver. 1.127 and have just noticed that the "Last
>     Duration" for one of my build projects has been reporting exactly
>     "1 hour" anytime the build takes longer then one hour.  I've
>     searched the users and issues mailing list archives and have only
>     come across Issues 108 and 146 discussing incorrect "Last
>     Duration" times, but those are over a year old and don't think
>     they're related.
>
>     I've gone through the ./log file in each of my build directories
>     and see:
>
>     $ grep duration */build.xml
>     2007-08-14_17-26-22/build.xml:  <duration>4558191</duration>
>     2007-08-15_01-01-07/build.xml:  <duration>4389343</duration>
>     2007-08-15_02-14-16/build.xml:  <duration>4375297</duration>
>     2007-08-16_01-01-07/build.xml:  <duration>2760153</duration>
>     2007-08-16_08-43-01/build.xml:  <duration>6668911</duration>
>     2007-08-16_12-21-52/build.xml:  <duration>6448552</duration>
>     2007-08-16_14-36-52/build.xml:  <duration>5659179</duration>
>
>     The one build which had the duration of 2760153 (which was a
>     failed build, which is why it's build time is so short) correctly
>     shows up with "Took 46 minutes.  All of the other builds show
>     "Took 1 hour" on their build page.  If I go to the "trend" chart,
>     the chart shows the correct number of minutes ranging from the low
>     time of 46 minutes up to a high time of 111 minutes.
>
>     Any ideas?  Is there something else I should be checking that
>     might help out?
>
>     Thanks...
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

Kohsuke Kawaguchi
Administrator
Stephen Connolly wrote:

> Once a build goes over 1 minute, the duration does not report how many
> seconds it will take, the duration reports to the nearest minute.
>
> When a build goes over 60 minutes, it is reported to the nearest hour,
> so 90 minutes and 1 second will be reported as 2 hours while 89 minutes
> and 59 seconds will be 1 hour (afaik)
>
> This has always been the case since we started using hudson back around
> version 1.40ish
>
> As to whether this is a bug or a feature is a different question!!!
Yes. This is by design.

I did thought about this a little bit in the past. In the current
implementation it goes from 59mins -> 1hour -> 2hours, which is quite a
gap. I thought perhaps adding a few intermediate values like 1 1/4 hours
1 1/2 hours, and 1 3/4 hours might be useful (Unicode has a codepoint
for characters like "1/4" to make it look nice on HTML) --- but then,
"1/2" and "1/4" are not very distinguishable by a cursory scan.

1/3 and 1/3 doesn't have this problem, but I guess divide-by-3 is
probably not a very popular notation for time.

Maybe a tooltip can show the exact build time?

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

Wolfram Kroll-2

Am 19.08.2007 um 06:24 schrieb Kohsuke Kawaguchi:

> Stephen Connolly wrote:
>> Once a build goes over 1 minute, the duration does not report how  
>> many seconds it will take, the duration reports to the nearest  
>> minute.
>> When a build goes over 60 minutes, it is reported to the nearest  
>> hour, so 90 minutes and 1 second will be reported as 2 hours while  
>> 89 minutes and 59 seconds will be 1 hour (afaik)
>> This has always been the case since we started using hudson back  
>> around version 1.40ish
>> As to whether this is a bug or a feature is a different question!!!
>
> Yes. This is by design.
>
> I did thought about this a little bit in the past. In the current  
> implementation it goes from 59mins -> 1hour -> 2hours, which is  
> quite a gap. I thought perhaps adding a few intermediate values  
> like 1 1/4 hours 1 1/2 hours, and 1 3/4 hours might be useful  
> (Unicode has a codepoint for characters like "1/4" to make it look  
> nice on HTML) --- but then, "1/2" and "1/4" are not very  
> distinguishable by a cursory scan.

I know that road distances shown like "2 1/4" in the US. So this  
might be very common and easy to grasp. I would prefer "2:15" as  
duration time format (grown up and living in Germany).

Wolfram

>
> 1/3 and 1/3 doesn't have this problem, but I guess divide-by-3 is  
> probably not a very popular notation for time.
>
> Maybe a tooltip can show the exact build time?
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

Gregory Kick-2
I was just in the middle of agreeing with Wolfram... :-)

It seems to me that the duration reported in that column is evaluated
slightly differently than the other two.  The last success/failure is
something that doesn't need to be particularly precise, and is well
suited for an order of magnitude type representation.  To me the
duration seems like a better fit for a stopwatch type representation
(mm:ss, hh:mm:ss, etc.) because most of the time people will be
interested in the precise interval (i.e. most builds aren't going to
reach the larger durations like days and weeks where the order of
magnitude clearly differentiate them).

On 8/19/07, Wolfram Kroll <[hidden email]> wrote:

>
> Am 19.08.2007 um 06:24 schrieb Kohsuke Kawaguchi:
>
> > Stephen Connolly wrote:
> >> Once a build goes over 1 minute, the duration does not report how
> >> many seconds it will take, the duration reports to the nearest
> >> minute.
> >> When a build goes over 60 minutes, it is reported to the nearest
> >> hour, so 90 minutes and 1 second will be reported as 2 hours while
> >> 89 minutes and 59 seconds will be 1 hour (afaik)
> >> This has always been the case since we started using hudson back
> >> around version 1.40ish
> >> As to whether this is a bug or a feature is a different question!!!
> >
> > Yes. This is by design.
> >
> > I did thought about this a little bit in the past. In the current
> > implementation it goes from 59mins -> 1hour -> 2hours, which is
> > quite a gap. I thought perhaps adding a few intermediate values
> > like 1 1/4 hours 1 1/2 hours, and 1 3/4 hours might be useful
> > (Unicode has a codepoint for characters like "1/4" to make it look
> > nice on HTML) --- but then, "1/2" and "1/4" are not very
> > distinguishable by a cursory scan.
>
> I know that road distances shown like "2 1/4" in the US. So this
> might be very common and easy to grasp. I would prefer "2:15" as
> duration time format (grown up and living in Germany).
>
> Wolfram
>
> >
> > 1/3 and 1/3 doesn't have this problem, but I guess divide-by-3 is
> > probably not a very popular notation for time.
> >
> > Maybe a tooltip can show the exact build time?
> >
> > --
> > Kohsuke Kawaguchi
> > Sun Microsystems                   [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Gregory Kick
http://kickstyle.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

rja84
Why not just continue reporting in minutes?  Seems like a "Last Duration" of "98 minutes" is a whole lot more useful, and correct, then seeing just "1 hour".

On 8/19/07, Gregory Kick <[hidden email]> wrote:
I was just in the middle of agreeing with Wolfram... :-)

It seems to me that the duration reported in that column is evaluated
slightly differently than the other two.  The last success/failure is
something that doesn't need to be particularly precise, and is well
suited for an order of magnitude type representation.  To me the
duration seems like a better fit for a stopwatch type representation
(mm:ss, hh:mm:ss, etc.) because most of the time people will be
interested in the precise interval ( i.e. most builds aren't going to
reach the larger durations like days and weeks where the order of
magnitude clearly differentiate them).

On 8/19/07, Wolfram Kroll <[hidden email]> wrote:

>
> Am 19.08.2007 um 06:24 schrieb Kohsuke Kawaguchi:
>
> > Stephen Connolly wrote:
> >> Once a build goes over 1 minute, the duration does not report how
> >> many seconds it will take, the duration reports to the nearest
> >> minute.
> >> When a build goes over 60 minutes, it is reported to the nearest
> >> hour, so 90 minutes and 1 second will be reported as 2 hours while
> >> 89 minutes and 59 seconds will be 1 hour (afaik)
> >> This has always been the case since we started using hudson back
> >> around version 1.40ish
> >> As to whether this is a bug or a feature is a different question!!!
> >
> > Yes. This is by design.
> >
> > I did thought about this a little bit in the past. In the current
> > implementation it goes from 59mins -> 1hour -> 2hours, which is
> > quite a gap. I thought perhaps adding a few intermediate values
> > like 1 1/4 hours 1 1/2 hours, and 1 3/4 hours might be useful
> > (Unicode has a codepoint for characters like "1/4" to make it look
> > nice on HTML) --- but then, "1/2" and "1/4" are not very
> > distinguishable by a cursory scan.
>
> I know that road distances shown like "2 1/4" in the US. So this
> might be very common and easy to grasp. I would prefer "2:15" as
> duration time format (grown up and living in Germany).
>
> Wolfram
>
> >
> > 1/3 and 1/3 doesn't have this problem, but I guess divide-by-3 is
> > probably not a very popular notation for time.
> >
> > Maybe a tooltip can show the exact build time?
> >
> > --
> > Kohsuke Kawaguchi
> > Sun Microsystems                   [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Gregory Kick
http://kickstyle.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

Jesse Glick
In reply to this post by Kohsuke Kawaguchi
Kohsuke Kawaguchi wrote:
> In the current implementation it goes from 59mins -> 1hour -> 2hours,
> which is quite a gap. I thought perhaps adding a few intermediate
> values like 1 1/4 hours 1 1/2 hours, and 1 3/4 hours might be useful
> (Unicode has a codepoint for characters like "1/4" to make it look
> nice on HTML) --- but then, "1/2" and "1/4" are not very
> distinguishable by a cursory scan.
>
> 1/3 and 1/3 doesn't have this problem, but I guess divide-by-3 is
> probably not a very popular notation for time.

I would suggest keeping the current logic but rather than rounding to
nearest (higher? lower? even?) integer, display two significant digits.
E.g. "5.3 minutes", "17 minutes", "1.2 hours", etc.

-J.

--
[hidden email]  netbeans.org  ant.apache.org  hudson.dev.java.net
             http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

Kohsuke Kawaguchi
Administrator
In reply to this post by rja84
richard alanis wrote:
> Why not just continue reporting in minutes?  Seems like a "Last Duration" of
> "98 minutes" is a whole lot more useful, and correct, then seeing just "1
> hour".

Some of the "durability" test jobs that run on my Hudson runs for about
6 hours. Some other jobs run in order of seconds.

I think changing the cut-over point might work. We can go from 0,1,2 ...
seconds up to maybe 179 seconds, then switch over to 3,4,5 ... mins up
to 179 mins, and maybe from there to 3,4,5 hours.

Hmm...

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: incorrect "Last Duration" showing up

rja84
For those jobs that do take some time to complete, like those that may run "for about 6 hours", wouldn't seeing a time of "365 minutes" be acceptable and maybe a little more useful?   That would also match up exactly with the graph the "trend" charts already present.

Just my 2 cents, but I'd think keeping it simple and just use minutes would be the way to go...


On 8/20/07, Kohsuke Kawaguchi <[hidden email]> wrote:
richard alanis wrote:
> Why not just continue reporting in minutes?  Seems like a "Last Duration" of
> "98 minutes" is a whole lot more useful, and correct, then seeing just "1
> hour".

Some of the "durability" test jobs that run on my Hudson runs for about
6 hours. Some other jobs run in order of seconds.

I think changing the cut-over point might work. We can go from 0,1,2 ...
seconds up to maybe 179 seconds, then switch over to 3,4,5 ... mins up
to 179 mins, and maybe from there to 3,4,5 hours.

Hmm...

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]