Trace Compass/Project Meetings/2017-02-24

Attendees

• Genevieve Bastien
• Bernd Hufmann
• Jean-Christian Kouame
• Matthew Khouzam
• Patrick Tasse

Update @ Ericsson

• Release 2.3
• Internal works

Update @ Poly

• Update with custom charts.
• TraceCompass logging: Will work on automatic benchmarking of UI operations using JUL tracing, extracting metrics from trace and comparing them
• Extension repository

Discussions on unsorted events

We see coming traces with unsorted events or with events whose payload contains the timestamps and event data, for example GPU traces and chrome traces with one event representing start and end. Also the timestamps may be of different clocks. For example, how to reconcile the java JUL nano timestamp with the LTTng kernel timestamp to match with a kernel trace.

Problems:

• Our data structures are optimized for monotonic events
• Seeking the event in the trace:

 * seek to timestamp, where the event is not, or to the actual event that caused the state change
 * where to put that event, insert it at the right position, or keep it where it came

Possible solutions:

• At trace time: Have the tracer sort the event / use different channels/streams for those kind of events. More overhead to the tracer who should be fast. Cannot assume that a trace will be done with that right structure.

• At the viewer level : low hanging fruit: Trace Compass or babeltrace can rewrite the trace with the events in proper order. That would work for small traces or traces where events are very close to where they should be, but less efficient for large traces (resulting trace will be at least the same size as original) and traces where the last event could contain some event that belongs to the start of the trace.

• Research: How do we handle large traces, use structures/index that will allow to keep the original trace while still being able to seemlessly navigate the views and events

Action Items

• None remaining