Closed julian-carleton closed 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
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.
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
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
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.
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
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.
200 ms seems like a reasonable value then. Should be good to merge 👍
Calculating the performance of the scheduler by measuring the time it takes to execute all of the input file.
Changes: