You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Clock properties of the traces are adjusted with respect to the first trace's clock properties in the list. We are computing the ratio (relative clock factor) of time resolution of respective trace to the time resolution of the first trace. The relative clock factor and global offsets of the first and respective trace are used to adjust the timestamps of the events.
I propose to either use the smaller clock resolution of the two. Or maybe even use an approximated greatest common divisor so that if you have clock period 0.780s and 0.312s, you'll get something like 0.156s.
The text was updated successfully, but these errors were encountered:
I really appreciate your suggestion
The method which is used here is one of the ways of adjusting the clock resolutions.
There can be many possibilities/ways to adjust clock resolutions and that also highly depends on applications/scenarios. So we have decided to keep this as default for now, until and unless we encounter any other application behaviours which are wide-used and common. Then we will decide on that.
If you have applications which need/require different clock arrangements, feel free to share with us.
I propose to either use the smaller clock resolution of the two. Or maybe even use an approximated greatest common divisor so that if you have clock period 0.780s and 0.312s, you'll get something like 0.156s.
The text was updated successfully, but these errors were encountered: