When you open a trace in Tracealyzer, it usually opens to the vertical timeline. This view, which shows all activity in the system, is in many ways the core of Tracealyzer and most of the other views link back to the timeline, but with its massive amount of information it is not always the best starting point; it can be very difficult to see the forest for all the trees in there.

But there are at least two other views in Tracealyzer that seasoned Tracealyzer users employ to get that quick overview over their application: Actor Statistics and Communication Flow. The idea behind today’s post is to briefly introduce these views.

The most important numbers

Let’s start with the Actor Statistics view, which you can bring up once you have opened a trace by going to Views -> Actor Statistics Report. In Tracealyzer, an Actor signifies a task/thread or an interrupt service routine. An Instance is a single execution of this actor, usually but not always corresponding to one iteration of the main loop or servicing one interrupt. The Instance may further be split into several Fragments, if for example the task blocks on a kernel call or is preempted by a higher-priority task.

After you have selected which actors and data you want to include, the view displays statistics like CPU usage and minimum, maximum, average execution time (in microseconds, unless you’ve changed the default setting) for each task in your application; see below. Many statistics are also linked so that if you click on them, you are taken to the corresponding spot in the timeline and other views you have open.

Tracealyzer Actor Statistics

Fragmentation counts the number of fragments of an actor instance (due to context switching or interrupts). Response Time is measured from the start of an instance to its completion, Periodicity from the start of an instance until the next instance starts and Separation from the end of an instance to the start of the next instance.

Of course, these numbers do not tell the whole story, but they can show you potential problems in your application. If the CPU load consistently is close to 100%, for instance, or if the response time for a certain task varies very much – those things might be worth looking at in more detail. As a rule of thumb, high-priority tasks should display pretty consistent behaviour while tasks with lower priority are allowed to vary more.

A high level of fragmentation indicates that the task in question is constantly being interrupted. Again, this doesn’t have to be a problem, but it might be.

There is a full description of the Actor Statistics view in the online manual; please note that the manual still describes Tracealyzer 3 and that a few features listed there have not yet made it into Tracealyzer 4 (but they are on their way).

Objects talking to each other

The Communication Flow view, accessed through Views -> Communication Flow, presents your application as a network of actors and RTOS objects passing messages between each other. Tracealyzer constructs the graph by going through the event stream looking for message sending calls, synchronization calls like waiting for a mutex et cetera.

You get a very good overview with the Communication Flow graph, and a visual verification that your application architecture works as you intended it to. It can reveal unsuitable designs as well as mistakes in the interaction between tasks. For instance, if a task uses multiple mutexes it may be at risk to cause deadlocks or excessive blocking. Likewise, some simple programming mistakes, like a task sending data to the wrong message queue, are immediately visible.

The Communication Flow graph is also a nice way to understand the overall behavior recorded in the trace. You can generate this view for the whole trace, or for a selected part of the trace, to ensure that your mental model of the system is correct and up to date with the current code. Getting the same understanding directly from the code is much more difficult.

Actors are shown as rectangles, and other kernel objects are shown as ellipses or hexagons. Ellipses are used for directional communication and synchronization objects, while hexagons are used for mutexes and similar, i.e., for bi-directional objects.

Double-click any node to open a parallel view showing events related to that object.

The graph can be customized in many ways, e.g. by hiding objects or by centering it around a selected object. Try right-clicking on a node in the graph to see the available options or read through the online documentation.

Equipped with these views, you’ll be off to a good start in your next Tracealyzer session.