| Thread Previous • Date Previous • Date Next • Thread Next |
Thanks Francesco!I was particularly interested in your single core numbers. That's almost two hours faster than the current IS buildbot machine. I'm somewhat tempted to run another single core run *without* the /dev/random hack, just to see what that affects, if anything, in that scenario.
I have run 4 cores, and I'm doing 2 cores now. So far we have this: 1 core: 4:17 2 cores: (in progress) 3 cores: 4 cores: 1:21 5 cores: 6 cores: 7 cores: 8 cores: 0:51 This begins to sketch a curve that looks pretty much like what I expected.The only other data point I'd say we really ought to have is 6 core, just because I think that's the default purchase number of cores for the data center. We could fill out more if we wanted to. 3 would be my next choice, myself. And maybe 1 core minus the /dev/random thing, like I said above, just for interest.
If someone could review the test runs to determine what bugs we should file/cards we should create, that would be useful. Otherwise, please help me remember to do it. :-)
Gary On 03/21/12 17:53, Francesco Banconi wrote:
Here is the summary of my tests. I've used a m2.4xlarge instance. Please find attached the failure reports. First run: Start Wed Mar 21 12:33:56 2012 End Wed Mar 21 13:25:20 2012 Elapsed 51 mins, 23 secs Failures: run-1.txt Second run: Start Wed Mar 21 13:57:10 2012 End Wed Mar 21 14:48:32 2012 Elapsed 51 mins, 22 secs Failures: run-2.txt Third run: Start Wed Mar 21 15:00:11 2012 End Wed Mar 21 15:50:37 2012 Elapsed 50 mins, 25 secs Failures: run-3.txt Subunit: subunit-8-cores.txt.gz Single core run: Start Wed Mar 21 17:06:12 2012 End Wed Mar 21 21:23:10 2012 Elapsed 4 hrs, 16 mins, 57 secs Failures: run-4.txt Subunit: subunit-1-core.txt.gz
| Thread Previous • Date Previous • Date Next • Thread Next |
