Bug in dynamic scheduling

[Rob Kewley]

I reported last night a bug in dynamic scheduling that caused successive
iterations of an application to take longer.  I was able to duplicate
this bug in a simple modification to the template application.  I used
twenty counters, instead of one.  I managed them using a dynamic
schedule.  With each step, the counter incremented and also scheduled an
update for itself between 0 and 10 seconds from now (this ensured some
concurrent groups).  I verified that the problem was not  caused by a
memory leak using the "sbrkKBye" technique described in the 4 April
posting to this list.  As the simualtion ran, each iteration took
successively longer.  Then I stopped iterating and simply ran one
iteration with output at fixed time intervals.  The time between outputs
grew successively longer.  I am looking for a fix, but have not found
one.  This is almost definitely a bug in the Swarm code.  I want to
optimize a simulation using a genetic algorithm.  I cannot do this if
each iteration takes longer than the last.  Any answers to this dilemma
would be a great help.  I would be happy to attach a .tgz file to an
e-mail to anyone who wants to verify my results.

Rob Kewley

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================