Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merged clock resolution #3

Open
mxmlnkn opened this issue May 23, 2019 · 1 comment
Open

merged clock resolution #3

mxmlnkn opened this issue May 23, 2019 · 1 comment

Comments

@mxmlnkn
Copy link

mxmlnkn commented May 23, 2019

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.

@anuragdogra2192
Copy link
Collaborator

anuragdogra2192 commented May 24, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants