Flagging the starting timeslot simulation

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

Flagging the starting timeslot simulation

Porag
This post was updated on .
Hi

We are trying to flag/track the starting timeslot of the simulation (which is generally the 360th timeslot;) in the marketmanagerservice's public synchronized void activate(int timeslotIndex) method... but what we have seen that in the tournament qualification round, we aren't always getting 360 as the starting timeslot there. Sometimes we are getting 359, sometimes 358... But in our local server simulation it is always the value is always 360.. We are unable to figure out whats the problem..


The code is like this in the activate method..

int currenttimeslotindex = timeslotRepo.currentTimeslot().getSerialNumber();
if (startTimeSlot == 0) {
        startTimeSlot = currenttimeslotindex;
        debugLog.info("Setting the starttime " + startTimeSlot);
}  


and startTimeSlot is initialized with 0 in the marketmanagerservice class.

Here the thing is, we get timeslotRepo.currentTimeslot().getSerialNumber() as 359 and timeslotIndex(which is the parameter of the activate function) as 360. In local simulations we get equal values but in tournament's qualifying round we are getting different values. These two values should be equal... Right???

Can you please suggest us, how can we track the startingtimeslot of the simulation? Because for this we are having lots on problems.

Best regards,
Porag
Reply | Threaded
Open this post in threaded view
|

Re: Flagging the starting timeslot simulation

grampajohn
Administrator
Hello, Porag -
Porag wrote
We are trying to flag/track the starting timeslot of the simulation (which is generally the 360th timeslot;) in the marketmanagerservice's public synchronized void activate(int timeslotIndex) method... but what we have seen that in the tournament qualification round, we aren't always getting 360 as the starting timeslot there. Sometimes we are getting 359, sometimes 358... But in our local server simulation it is always the value is always 360.. We are unable to figure out whats the problem..
The boot session should always be 360 timeslots, numbered 0 - 359. If it's not, then there was a problem with the boot session. Can you give us some game numbers where the starting timeslot was not 360?

Based on what I have been seeing, I suspect there may be some congestion problems at RSM where the servers are running. We would like to figure out exactly what is happening.

Thanks -

John
Reply | Threaded
Open this post in threaded view
|

Re: Flagging the starting timeslot simulation

Porag
Hi John,

Point 1: boot session is not 360 timeslot: It’s 336 (we checked bootstrapTimeslotCount in log and netUsage length)

Point 2: In MarketManagerService:activate(int timeslotIndex)
  when we run the current snapshot of the server locally, we get:
  timeslotIndex = timeslotRepo.currentTimeslot().getSerialNumber() = 360
  in contrast, during the competition we got:
  timeslotIndex=360, and
  timeslotRepo.currentTimeslot().getSerialNumber()=359
 
We observed that this behavior is consistent in each of the simulations.

Should we consider the timeslotIndex as correct timestamp or should we query timeslotRepo?

Best regards,
Porag
Reply | Threaded
Open this post in threaded view
|

Re: Flagging the starting timeslot simulation

grampajohn
Administrator
On 04/11/2015 05:44 PM, Porag [via Power TAC Developers] wrote:
Hi John,

Point 1: boot session is not 360 timeslot: It’s 336 (we checked bootstrapTimeslotCount in log and netUsage length)

The boot record is indeed 336 timeslots long, because we discard the first 24 hours to let prices settle. So a boot session is indeed 360 timeslots long, of which the last 336 are recorded.


Point 2: In MarketManagerService:activate(int timeslotIndex)
  when we run the current snapshot of the server locally, we get:
  timeslotIndex = timeslotRepo.currentTimeslot().getSerialNumber() = 360
  in contrast, during the competition we got:
  timeslotIndex=360, and
  timeslotRepo.currentTimeslot().getSerialNumber()=359
 
We observed that this behavior is consistent in each of the simulations.

At the start of  a sim session, the clock is set back by an hour so we can use the standard "next timeslot" behavior to start things off. So timeslot 359 is just there for initialization purposes. The "normal" sim-session activity indeed starts at timeslot 360. Sorry for the confusion.

John



Should we consider the timeslotIndex as correct timestamp or should we query timeslotRepo?

Best regards,
Porag


If you reply to this email, your message will be added to the discussion below:
http://power-tac-developers.975333.n3.nabble.com/Flagging-the-starting-timeslot-simulation-tp4025974p4025977.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Flagging the starting timeslot simulation

Porag
Hi John,

Recently I got this error in two games :

"worker thread waited more than 120 sec for server, abandoning the game"

Do you know why this is happening?

Thanks
Porag



Reply | Threaded
Open this post in threaded view
|

Re: Flagging the starting timeslot simulation

grampajohn
Administrator
On 04/12/2015 05:58 PM, Porag [via Power TAC Developers] wrote:
> Hi John,
>
> Recently I got this error in two games :
>
> "worker thread waited more than 120 sec for server, abandoning the game"
>
> Do you know why this is happening?

It sounds like you got disconnected. I can't say more without looking at
the logs. Which games were they?

John

Reply | Threaded
Open this post in threaded view
|

Re: Flagging the starting timeslot simulation

serkan
In reply to this post by Porag
For a while ago, I had experienced a similar problem. For my case, it was a timing problem and was fixed by installing a NTP client. Also, you may shutdown firewalls and internet security tools.