Thursday 15 March 2018

TrafficControl: Analysing TrafficClock

As I mentioned in the last blog post, there are some refactoring and UI fixes that I need to do for the trafficClock.

The first step is to analyze the behaviour of qThread and qTime. I want to know how accurate the timing is (does the thread wake up after the specified time) and how much time the train/track/station operations take. I've done this by adding some qDebug statements:


For an interval of 100 ms, the output is:


The time difference between "BEFORE EMIT" and "AFTER EMIT" is almost always 0 ms, so the estimated time consumption for emitting stepTimeSignal command can be neglected.

The time between "BEFORE SLEEP" and "WOKE UP" is between 1 ms up to 15 ms more than expected. This is a minor issue, but the target time tends to drift as the small delays accumulate. The solution to this behaviour is the following code change:

After printing the time at the start and end of tcNetworkControl::stepTimeForNetwork(), I am able to track the time consumption for three trains in a small network.
In this case, the interval is 100 ms.
The system configured for low performance and the build is debug.

In this case, the interval is 20 ms.
  The computer is set to have high performance and the build is release, the operations take 2-3 ms.
It seems that the time intervals are irregular.

In this case, the interval is 20 ms, but the operations take 30 ms.
The next signal is trigged as soon as the former is done.
The behaviour is expected. 
Finally, I tested without QML.
The time consumption is far below one millisecond. This means that QML will be critical for optimizations.
In the next blog post, I'll make three changes in the user interface:

  1. Display the simulated time
  2. Show the time needed for stepTimeForNetwork, as a percentage of the intervals
  3. Replace the two time spinboxes with one spinbox for fast forward factor and add a button that will toggle between "play" and "pause".


Further, I need to investigate if it is possible to make the QML operations run without affecting the performance of the train operations.

No comments:

Post a Comment