Re: [tracecompass-dev] Experiments vs Composite TraceTypes

[Bernd Hufmann <bernd.hufmann@xxxxxxxxxxxx>]

Hi Ivan,

These are interesting use cases. I try to answer your questions with some disclaimers that I'm not able to try it.

To answer your 2 questions:

> I think we have two ways of resolving the issue:

1. Create our own experiment types and add new analyses to them.
2. I don't think an experiment type would work with the current implementations (i.e. AbstractTimeGraphMultiViewer, AbstractTimeGraphView), where the viewer gets all the children traces of trace (experiment in this case) and calls the data provider for each child trace to collect data. This causes that there are multiple rows added, as you have already relealized. However, there might be a way around it which I'll describe below as third option.
   
3. Create a new entity “Composite Trace Type” which can be configured to read different events sources (already known trace types) but will remain a “trace”.
4. This sounds like a good idea. Create a new trace type that is feed by a directoy, like a "directory trace", i.e. a directory with children traces. The trace resource in Trace Compass would be the parent directory. It then will read each child trace and return each event from each child trace in time-ordered way. Maybe the new composite trace implementation contains an TmfExperiment as a member and delegates the interface calls to the experiment member (see attached file).
   If it doesn't work to contain the experiment, then you will have to implement methods yourself, like the CtfTmfTrace which is similar (directory trace with binary files).
   Once you have composite trace, you will update or create a data provider factory that will return the correct data provider for such instance. Also, you have to make sure that your analyses are scheduled for the composite trace as well.

The third option comes into my mind because I have an use case of a data provider that can be with used with different traces/trace types. In my case, one trace creates the main rows with states, another trace type addes children rows to the main rows and a third trace is adding symbols (annotations) on top of the main row.

What you need is an experiment (generic experiment works). The data provider will have to create the same entry ID for each main row when the data provider is called for each children trace. The implementation in BaseDataProviderTimeGraphMultiViewer.buildEntryList() will aggregate the entries when they have the same entry ID. However, in my use case only one trace creates the states for the main row. I'm not sure if the current implementation will combine the states for the main row from different traces. This you would have to try.

Option 3 is only valid for Gantt chart type views (timegraph). For XYCharts, I don't think there is something similar in place like option 3. A composite trace like option 2, would work there or some updates to the view classes to combine the data of each trace.

I hope this feedback gives you something to start looking into.

Best Regards

Bernd

---

From: tracecompass-dev <tracecompass-dev-bounces@xxxxxxxxxxx> on behalf of Grinenko, Ivan <ivan.grinenko@xxxxxxxxxx>
Sent: February 22, 2022 1:38 PM
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Subject: [tracecompass-dev] Experiments vs Composite TraceTypes

 

Hi,

 

We use Trace Compass to deal with issues encountered within medical devices. Trace Compass is a platform for us. We’ve implemented a plugin that adds support for our trace types and analyses. So, we have a bunch of trace types and analyses for them. Some of our devices leave more than one trace behind. Each file/trace can be opened with Trace Compass using our plugin. All went pretty good until we faced a necessity to work with more than one file at a time.

 

We have three multifile use cases when files come from a single device:

1. All the files are of the same trace type. They just represent a different period of time each. It occurs when devices rotate log-files, e.g. by size limits.
2. The files are of different trace types. Their time borders are not necessarily strictly bound. Still, they contain events from the same device and we want to work with them as with one trace.
3. A combination of first two.

 

All three cases could be resolved by using experiments if we used the events view only, but If we open a set of files as a generic experiment we have some issues with charts.

 

If we open one trace with a state in it we’ll see a Gantt chart with that state’s changes.

State: (---on---)(---off---)

 

If we use multifile case #1 with two files and open a Gantt chart with the state we’ll see something like this:

State:           (---off---)

State: (---on---)

 

The number of lines is determined by the number of traces with such data in the experiment. Of course, we want to see these states on one line. XYCharts are worse. Using existing TmfTreeCompositeDataProvider makes it possible to see data only when one trace of a given trace type exists in the experiment. So, it works only for multifile case #2.

 

I think we have two ways of resolving the issue:

1. Create our own experiment types and add new analyses to them.
2. Create a new entity “Composite Trace Type” which can be configured to read different events sources (already known trace types) but will remain a “trace”.

 

Of course, we want to reuse our existing code as much as possible, since, trace types and analyses are working already.

 

What are pros and cons of given two solutions? What am I missing? Are there other ways to cope with our issues? Please, share.

 

Thanks!

 

--

Best regards,

Ivan Grinenko

Software Engineer

Auriga

 

package org.eclipse.tracecompass.tmf.core.trace;

import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IResource;
import org.eclipse.core.runtime.IStatus;
import org.eclipse.tracecompass.tmf.core.event.ITmfEvent;
import org.eclipse.tracecompass.tmf.core.exceptions.TmfTraceException;
import org.eclipse.tracecompass.tmf.core.request.ITmfEventRequest;
import org.eclipse.tracecompass.tmf.core.trace.experiment.TmfExperiment;
import org.eclipse.tracecompass.tmf.core.trace.indexer.ITmfTraceIndexer;
import org.eclipse.tracecompass.tmf.core.trace.location.ITmfLocation;

/**
 *
 */
public class CompositeTrace extends TmfTrace {
    private TmfExperiment fComposite;

    @Override
    public void initTrace(final IResource resource, final String path, final Class<? extends ITmfEvent> eventType)
            throws TmfTraceException {
        /*
         * Set the cache size. This has to be done before the call to super() because
         * the super needs to know the cache size.
         */
        int cacheSize = 50000;
        setCacheSize(cacheSize);

        super.initTrace(resource, path, eventType);

        // find children traces
        int nbTraces = 2; // TODO
        ITmfTrace[] traces = new ITmfTrace[nbTraces];
        // create all children ITmfTrace and add them to the array.

        fComposite = new TmfExperiment(eventType, path, traces, cacheSize, resource);
    }

    @Override
    protected ITmfTraceIndexer getIndexer() {
        return fComposite.getIndexer();
    }

    @Override
    public IStatus validate(IProject project, String path) {
        // TODO needs to be implemented
        return null;
    }

    @Override
    public ITmfLocation getCurrentLocation() {
        return fComposite.getCurrentLocation();
    }

    @Override
    public double getLocationRatio(ITmfLocation location) {
        return fComposite.getLocationRatio(location);
    }

    @Override
    public ITmfContext seekEvent(ITmfLocation location) {
        return fComposite.seekEvent(location);
    }

    @Override
    public ITmfContext seekEvent(double ratio) {
        return fComposite.seekEvent(ratio);
    }

    @Override
    public ITmfEvent parseEvent(ITmfContext context) {
        return fComposite.parseEvent(context);
    }

    @Override
    public synchronized ITmfEvent getNext(final ITmfContext context) {
        return fComposite.getNext(context);
    }

    @Override
    public synchronized ITmfContext armRequest(final ITmfEventRequest request) {
        return fComposite.armRequest(request);
    }

    @Override
    public void indexTrace(boolean waitForCompletion) {
        fComposite.indexTrace(waitForCompletion);
    }

    @Override
    public synchronized void dispose() {
        fComposite.dispose();
        super.dispose();
    }
}