I have the feeling that is is an artefact of the virtualisation somehow.��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