- Don't enforce the join order, MariaDB usually gets this right.
- Update DB statistics before terminating.
Change-Id: If7bbbe146321430d199811062d05b3c179c5732f
We're not yet using the common DatabaseCampaign as it doesn't allow
for additional experiment parameters (such as "variant" and
"benchmark") yet. TODO: Integrate changes in DatabaseCampaign in a
generic way and use it.
Change-Id: I45480003be433654aea8d3a417fbfa66be31155b
When eCos is built as a multiboot binary, some of its data structures
are still at very low (<<1M) addresses, but the rest moves to
addresses >1M. This change makes sure our invalid mem access
detection is not overly generous.
Change-Id: If8265a407b3706a4ff71562b316e05aa22255f62
When we want to use a bounded job queue, job producer and job consumer must
run in different threads in order not to deadlock the campaign. Ideally
this functionality moves to the CampaignManager later (including the
retrieval of existing experiment results and storing new results).
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1946 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
This modification creates and uses multiple intermediate snapshot states
(one every 1,000,000 instructions) to fast-forward to the FI site.
Unfortunately this doesn't work yet; the trace seems to change in many (not
all!) cases we do this. One possible cause could be an incorrect
(off-by-one or alike?) restoration of the serial device timers, and
therefore an earlier/later transition to "output buffer empty", resulting
in eCos' serial putc function needing a different amount of polling loop
iterations. Needs more investigation.
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1940 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
For the eCos kernel test campaign we define a relatively "special" metric
to compare FI results from different applications: Instead of aligning
the fault-space dimensions (e.g., by artificially adding "don't care" space
to the right for shorter application variants), we only keep the data
address axis constant. The rationale behind this is that -- despite the
benchmark applications' run-to-completion behavior -- an operating system's
scheduler usually runs ad infinitum, and that we therefore can extrapolate
from a short application run to any longer period.
In essence, this means we use a failure/experiment-length quotient (ignoring
the Y axis for simplicity, as it is constant in size) to compare
application variants, instead of an absolute failure count. One important
side effect is that we do not punish any application slowdown with this
metric. (And simply prolongating non-susceptible program sections with,
e.g., NOPs, seemingly "improves" fault tolerance.)
git-svn-id: https://www4.informatik.uni-erlangen.de/i4svn/danceos/trunk/devel/fail@1922 8c4709b5-6ec9-48aa-a5cd-a96041d1645a
