[wine-devel] Re: Wine test week 2 - nice apparent progress

Alan W. Irwin irwin at beluga.phys.uvic.ca
Tue Mar 25 12:07:47 CDT 2014

On 2014-03-25 07:51-0500 Jeremy White wrote:

> On 03/25/2014 02:33 AM, Henri Verbeet wrote:
>> On 25 March 2014 01:00, Jeremy White <jwhite at codeweavers.com> wrote:
>>> My script results are here:
>>>    http://www.winehq.org/~jwhite/ebd5f96aea22.html
>> For what it's worth, note that the intermittent failures in
>> ddraw:ddraw7 are timeouts, and happening in different places. I
>> suspect that's either the generic issue of the testbot timing out on
>> occasion, or the testbot just not being fast enough to finish the test
>> in time, perhaps due to it being under some load from a different VM.
> Francois, do we have (or could we easily create) a mechanism to test that by 
> constraining the number of VMs that run simultaneously?  I know it would slow 
> performance, but it would be interesting to see if we
> can quantify that.

I am not a wine developer, but observing this interesting thread from
the outside point of view, it seems to me what you really need is a
mechanism to specify "timeout" for each test not in terms of
wall-clock time, but in terms of roughly how many floating-point
operations are consumed by the test before it is decided the test is a
failure.  IOW, each timeout in seconds should effectively be
multiplied by the integral of the time-variable load factor on the
actual hardware that is running the VM divided by a constant factor
corresponding to the speed of the machine.  So for example, the
timeout in seconds could be specified for a 1-GHz otherwise idle
theoretical hardware, and adjusted appropriately on-the-fly to speed
of the actual hardware and its time-variable load. If this is
implemented correctly, once a test succeeds with a given timeout
(specified for the theoretical hardware) on given hardware, it should
never fail again due to load/computer speed factors on that or any
other hardware with that same given timeout.

Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).

Linux-powered Science

More information about the wine-devel mailing list