Debug option for non fixed slot duration?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Debug option for non fixed slot duration?

mtobiass
Hi,
Currently each game slot is a fixed length of time, usually 5 seconds. Would it be difficult to as an option let the brokers decide when the server advances to the next slot?

The idea is that each broker would send a "finished" message when it is done with the curent slot. When the server has received a "finished" message from each broker, then the server starts the next slot.

This is not something that would be used in a competition, but during development it would be very good. Both to speed up the game to collect data faster, and to let the server wait while I am stepping through my broker code in a debugger.

Thanks,
Mattias
Reply | Threaded
Open this post in threaded view
|

Re: Debug option for non fixed slot duration?

grampajohn
Administrator
Hello, Mattias -
mtobiass wrote
Hi,
Currently each game slot is a fixed length of time, usually 5 seconds. Would it be difficult to as an option let the brokers decide when the server advances to the next slot?
Yes, this capability is part of the simulation clock-control design. The original goal was to support research with human decision-makers competing with autonomous brokers.

What you have to do is add a line like

   server.competitionControlService.brokerPauseAllowed = true

to the server.properties file. If you are running the server with maven, this file is in server-distribution/config; if you are running from sources, then it's in server-main/src/main/resources/config.

Once you have done this, the broker can send a PauseRequest message to the server to pause the clock, and a PauseRelease message to re-start it. Note that I have not tested this feature for a while with a broker, although the feature in the server is tested as part of the unit-testing suite. If it does not work for you, please let me know, and send me the part of the server's trace log where the PauseRequest message was received. The string "Pause request" should show up in the log.

Hope this helps -

John
Reply | Threaded
Open this post in threaded view
|

Re: Debug option for non fixed slot duration?

mtobiass
This post was updated on .
Thank you very much!
I have tried it, and for debugging it works just as a wanted. Since debugging was my most important use-case I am happy as it is now.

But for a possible future change, I am still interested in being able to speed up the server a bit more.
I would like to run a lot of fast test games just to collect data. It is difficult to set a correct value for "common.competition.simulationTimeslotSeconds". Too low and I risk missing a slot, too high and I waste time. Just 1 extra second per time slot means over 20 minutes extra run time. It would be great if the server could wait for a "Finished" message from the brokers. Then it would run as fast as possible, with no risk of missing any messages.

Maybe the server could automatically pause the time when all messages have been sent to the brokers, and then wait for a PauseRelease from each broker?

But as I said, I am happy for now with the ability to debug.

Thank you,
Mattias
Reply | Threaded
Open this post in threaded view
|

Re: Debug option for non fixed slot duration?

grampajohn
Administrator
Mattias -
mtobiass wrote
But for a possible future change, I am still interested in being able to speed up the server a bit more.
I would like to run a lot of fast test games just to collect data. It is difficult to set a correct value for "common.competition.simulationTimeslotSeconds". Too low and I risk missing a slot, too high and I waste time. Just 1 extra second per time slot means over 20 minutes extra run time. It would be great if the server could wait for a "Finished" message from the brokers. Then it would run as fast as possible, with no risk of missing any messages.
I'm glad it works for you. There are two other parameters that might help:

(1) server.simulationClockControl.minAgentWindow sets the minimum interval in msec between the last outgoing message (TimeslotComplete) and the start of the next timeslot. The default setting is 2000 msec.

(2) common.competition.simulationTimeslotSeconds sets the (minimum) timeslot duration. It has to be in integer seconds, and it has to be a factor of 60 (so the "rate" can be an integer).

So if you set simulationTimeslotSeconds to 3 and leave minAgentWindow at 2, you will get 3-second timeslots most of the time, but still get 2 seconds for your agent. If the server does not finish in 1 second (tariff evaluation and retrieval of weather data can take longer), then it will pause itself and send new clock parameters to the agents when it catches up.

Have fun with this, and let us know if you find a formula that works well.

John