Non regular size on event producers hierarchy

[dbeniamine]

I'm having a weird issue with Ocelotl: I'm visualizing a Moca trace and the size (height) of the event producers seems to be related to the number of events in it. It results on an incoherent interpretation of the trace a some data structures seems to be larger than other while they are not ...

There is a screenshot where we can identify 3 data structure (second level event producers) which have the same size (and the same number of event producers in their hierarchy), yet one of the three data structures is way larger than the others ...

[dosimont]

Just looking at this figure is not enough to know what's the problem. However, we can start by checking if the hierarchy is correctly defined in your trace. Be aware that the last hierarchy level is sometimes not shown, so it's possible that the weight of the data structures varies according to this hidden hierarchical level. Can you confirm that the hierarchy level number is the same than what you expect, or that some items are missing? Moreover, I remember that we used aggregation when the event producer size was too small. This behavior is not visible here. Have you disabled this option? What happens if you enable it again? Do you get the same weighting?

[dbeniamine]

Just looking at this figure is not enough to know what's the problem. However, we can start by checking if the hierarchy is correctly defined in your trace. Be aware that the last hierarchy level is sometimes not shown, so it's possible that the weight of the data structures varies according to this hidden hierarchical level.

Yes it is never show for theses traces as there are too many producers. I stop the aggregation a 100 producers (using the maximum number of leaves parameter).

Can you confirm that the hierarchy level number is the same than what you expect, or that some items are missing?

I'm counting with sqllite the total number of nodes in the hierarchy for each of the three data structures, and the indeed have a different number of event producers. So I guess the problem comes from here. Still the last time I visualized the trace (in february), the size of the data structures were comparable, did you modify something in Ocelotl about this ?

I remember that we used aggregation when the event producer size was too small.

Do you speak of visual aggregation ? I yes it is disabled I can't see anything if I enable it.

[dosimont]

Still the last time I visualized the trace (in february), the size of the data structures were comparable, > did you modify something in Ocelotl about this ?

I don't remember having modified anything about this. Is it exactly the same trace ?

Yes it is never show for theses traces as there are too many producers. I stop the aggregation a 100 producers (using the maximum number of leaves parameter).

If you have always too many producers, you should think about modifying the way you organize the trace. This aggregation feature may help punctually, but I would avoid using it systematically.

Do you speak of visual aggregation ? I yes it is disabled I can't see anything if I enable it.

Same problem. There is plenty of visualization artifacts if you disable the visual aggregation.

I think you should perform yourself the aggregation of the bottom levels of the hierarchy, instead of letting Ocelotl doing it naively (during the import, for instance).

[ycorre]

I made two modifications in February about the event producers aggregation following the issue #189 of Framesoc. The first one fixed a bug where no aggregation of the Event Producers (EP) was made and the second one enhanced the performances.

The first modification should not modified the final view, unless the screenshot in your first post is a subselection of EP.

It is possible that the second modification leads to a different result, since it is assuming that the lower level in the hierarchy tree always contains more producers than the level just above. If this is not the case then the final results might be different.

Could you provide us with the trace?

[dbeniamine]

@ycorre: I just tried using the last version of ocelotl before these commit, it does not change my issue.

@dosimont: I agree the EPs should be merged during the import, I tried using the Max Hierarchy Depth parameter that ycorre implemented in the Moca importer, still it does not seems to merge the last level EPs thus the issue persists. I will try to modify Moca importer to fix that.

Is it exactly the same trace ?

It is a trace I already imported, I'm pretty sure that I would have remembered such a visual artifact ... Still I will also try to generate and import new traces just in case.

[dosimont]

Since the problem seems to depend on your trace, I close the issue.