public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: William Cohen <wcohen@redhat.com>
To: David Wilder <dwilder@us.ibm.com>
Cc: Quentin Barnes <qbarnes@urbana.css.mot.com>,
	systemtap@sources.redhat.com
Subject: Re: testsuite and hardcoded timeouts
Date: Mon, 14 May 2007 20:43:00 -0000	[thread overview]
Message-ID: <4648C9B1.30307@redhat.com> (raw)
In-Reply-To: <46489CF5.6010705@us.ibm.com>

David Wilder wrote:

> 
> I ran into this issue on s390.   When a time out occurs if the test 
> would simply produce a warning message then restarts the timer, allowing 
> the timeout to be restarted say 4 or 5 times before finally reporting a 
> failure.   Then if something breaks the test will still report a 
> failure.  On slower system the test would still pass.  If a  system/test 
> normally passes with one or two restarts of the timer then something 
> changes and it starts taking 3 or 4 restarts we will know that 
> investigation is needed.
> 


You might luck out with the caching helping the later attempts skip some of the 
phases of the translator and avoid those times on the later runs. However, 
restarting 4 or 5 times is probably not going to help that much if the time 
required to generate the module is way larger than the time out.

The timeout is there to make sure that forward progress is made on the testing. 
We would prefer to have the test fail in a reasonable amount of time than to 
have a test hang for an unreasonable amount of time and not get any results at 
all. The translator internals are pretty much a black box to the testing 
harness, so the timer is used to judge when the the test isn't making forward 
progress. Too bad there couldn't be an equivalent to a watchdog for the testing 
harness, e.g. if the test is making forward progress, leave the test be.

-Will

  reply	other threads:[~2007-05-14 20:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-11 19:14 Quentin Barnes
2007-05-11 21:08 ` William Cohen
2007-05-14 16:50   ` David Wilder
2007-05-14 20:43     ` William Cohen [this message]
2007-05-14 21:01       ` David Wilder
2007-05-15 22:35         ` Quentin Barnes
2007-05-15 22:47           ` Frank Ch. Eigler
2007-05-16  0:42             ` Quentin Barnes
2007-05-16 19:03               ` William Cohen
2007-05-18  0:36             ` Quentin Barnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4648C9B1.30307@redhat.com \
    --to=wcohen@redhat.com \
    --cc=dwilder@us.ibm.com \
    --cc=qbarnes@urbana.css.mot.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).