Ralf Wildenhues wrote: > Thanks for the report. This is a different type of failure than the > last one, I'm glad. It is of the kind of the lost race inherent and > unavoidable in the test: trying to find out whether parallel execution > really is faster than sequential, is not deterministically possible > on non-real-time systems.
And will have quite different results on single cpu versus multi cpu systems. > Was the system very loaded at the time? I do not know and do not keep records to be able to correlate it. Probably. It could go either way. This is the faster 64-bit system. So I would expect it to be less bogged down than the 32-bit system running in parallel beside it. If I had to guess I would say it was running a load average of between 4 and 5 during the build and test because htat is not uncommon. But better would be to have this information gathered at that point in time because I could easily guess wrong here. For this type of test perhaps it could be reasonable to gather this information dynamically? (e.g. with uptime) Useful debug info... > Note I'm not suggesting to make it less so; au contraire, this test > part should either be disabled or made even less prone to failure in > that case. This is the first such failure in surely a lot of test > runs. If it is a different test failure then it certainly has had a lot of test runs without producing this failure. Bob
