Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Experiments vs Composite TraceTypes
Hi Ivan and Bernd,

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.

For a simple solution to this, you can override AbstractTimeGraphView#getTracesToBuild to avoid returning the leaf traces of an experiment:

    @Override
    protected @NonNull Iterable<ITmfTrace> getTracesToBuild(@Nullable ITmfTrace trace) {
        return (null != trace) ? ImmutableSet.of(trace) : ImmutableSet.of();
    }

This way, your view creates a single data provider for the experiment as a whole, assuming your analysis is set to be able to run on the experiment itself, as Bernd mentioned. This might not solve all the issues, but should definitely work with time graph views with use-case #1.

Regards,


Christophe

On Mon, Feb 28, 2022 at 7:47 AM Grinenko, Ivan <ivan.grinenko@xxxxxxxxxx> wrote:

Bernd,

 

Wow! The idea in the attached file is brilliant at first glance. It was hard for me to choose between my two options, but the decoration of an experiment looks really cool here! I’m definitely going this way.

 

I think I didn’t completely get the idea and possible issues of the data provider. According to the decoration my expectation was that I don’t have to change anything for my data providers. I’m expecting that I’m just expanding a number of sources of events for a new trace type, but data providers work with state systems anyway. And these state systems are going to be filled by a composite trace thus having one entry point.

 

Still, thanks a lot! I’m going to try it and report.

 

--

Best regards,

Ivan Grinenko

Software Engineer

Auriga

 

 

 

From: tracecompass-dev <tracecompass-dev-bounces@xxxxxxxxxxx> On Behalf Of Bernd Hufmann via tracecompass-dev
Sent: Friday, February 25, 2022 8:00 PM
To: tracecompass developer discussions <tracecompass-dev@xxxxxxxxxxx>
Cc: Bernd Hufmann <bernd.hufmann@xxxxxxxxxxxx>
Subject: Re: [tracecompass-dev] Experiments vs Composite TraceTypes

 

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

 

_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tracecompass-dev

Back to the top