On 02 Sep 2015, at 10:24, Guillermo Polito <guillermopolito@gmail.com> wrote:I saw also that one of the linux slaves is much much slower than the others. Just check this:In one of the slaves the build takes one hour. In the other it takes 6.El mi��., 2 de sept. de 2015 a la(s) 9:11 a. m., Marcus Denker <marcus.denker@inria.fr> escribi��:I don���t think so��� the job used to run in 15 minutes. But we added more tests,Rules got slower���On 02 Sep 2015, at 08:34, Nicolai Hess <nicolaihess@web.de> wrote:It is possible to see from the console output which rule or test takes a lot time?2015-09-02 8:09 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:On 01 Sep 2015, at 19:15, Ben Coman <btc@openinworld.com> wrote:Do you want to try a post-load...
Delay delaySchedulerClass: DelayExperimentalSemaphoreScheduler
which fixes the "super fast delay" on virtual machines reported here...
http://comments.gmane.org/gmane.comp.lang.smalltalk.pharo.devel/100873
Its named "experimental" only since it was integrated just before
Pharo 4 release and did not have wide spread community testing, but
its complete and working. There is some further overall streamlining
of the DelayScheduler hierarchy I'd like to do later, but it would be
good to give this one a run as the default for a while to see how it
impacts the issue. (It would be good to get rough "CIAndRule: Timeout"
before and after statistics.)
btw, is that CI error indicating it times out after one hour? Are
there any other timestamps present in the log that indicate if 1 hour
really passed?Yes, I think so���Now looking at it (no idea why it is chinese), it seems that we have someslowdown recently and all runs take 40-50 minutes, a slowdown to 60 can happenjust by having less compute power available (or running multiple things in parallel).We should-> do a pass over slow tests-> do a pass over slow rulesI will put the limit higher than 60 min for now.Marcus