Included inactivity timer that checks for both scheduler threads

withaspirit / Elevator-Simulation

Elevator System Simulation project

1 stars 1 forks source link

Included inactivity timer that checks for both scheduler threads #213

Closed julian-carleton closed 2 years ago

julian-carleton commented 2 years ago

Calculating the performance of the scheduler by measuring the time it takes to execute all of the input file.

Changes:

A timer checks for inactivity of both scheduler threads. Gets trigger after timerTimeOut time has passed of inactivity.
Included calculation of timeElapsed for the scheduler thread.

withaspirit commented 2 years ago

Functionally it seems good, but it waits a long time after the system is done to output the message. I got a result of ~8000 ms which doesn't seem right

julian-carleton commented 2 years ago

Functionally it seems good, but it waits a long time after the system is done to output the message. I got a result of ~8000 ms.

Yeah, I was getting around ~6000 ms, which seems a little high, but I'm not sure if that's happening because of the time we take to manually run each program. At least that's how I tested it. And the runtime time can be changed, I have 7s but we can make it lower.

withaspirit commented 2 years ago

Maybe it should record a certain time after it receives its last packet, and if the timertask expires, that certain time is used as the end time for the calculation

julian-carleton commented 2 years ago

I just pushed a version where the start measurement is taken after the first package is received. And the result is ~200 ms for both threads if ElevatorSubsystem is ran before floorsubsystem

julian-carleton commented 2 years ago

Maybe it should record a certain time after it receives its last packet, and if the timertask expires, that certain time is used as the end time for the calculation

But that's the issue, we don't know which is the last packet.

withaspirit commented 2 years ago

But that's the issue, we don't know which is the last packet.

If we record the time each time a packet is received, we don't need to know which packet is the last one. We can just use the value as is because no other packet has been received since

julian-carleton commented 2 years ago

Oh that's actually what it's already doing. It resets the timer after it processes a package. And the timer time is substracted when the elapse time is calculated.

withaspirit commented 2 years ago

200 ms seems like a reasonable value then. Should be good to merge 👍