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

ZeroMQ sending: Ensure data consistency between data and macro pulse number #14

Closed
mhier opened this issue Feb 13, 2019 · 3 comments
Closed
Assignees
Labels
enhancement readyForImplementation This ticket has been moved to the "ready for implementation" area on the MSK software group board review A ticket that has been finished and should be reviewed by another developer selected This ticket has been selected for the MSK software group board

Comments

@mhier
Copy link
Member

mhier commented Feb 13, 2019

Follow up for #12, depends on ChimeraTK/DeviceAccess#25
Use the data consistency group (see ChimeraTK/DeviceAccess#25) to ensure the macro pulse number is always consistent with the data.

If #15 is already done, make sure to ensure data consistency there as well.

@jhktimm jhktimm added the selected This ticket has been selected for the MSK software group board label Mar 21, 2019
@killenb killenb added the readyForImplementation This ticket has been moved to the "ready for implementation" area on the MSK software group board label May 21, 2019
@killenb killenb self-assigned this May 24, 2019
@killenb killenb added the review A ticket that has been finished and should be reviewed by another developer label May 31, 2019
@killenb
Copy link
Member

killenb commented May 31, 2019

There is a first implementation on the master. It calls updateDoocsBuffer twice: Once for each macro pulse update and once for the data itself. It does not have a "performance optimisation" that the function pointer dereferencing is only done after checking the consistency group.

Please check if the performance is sufficient. If so please close the ticket, otherwise assign it back to me.

@killenb killenb assigned mhier and unassigned killenb May 31, 2019
@mhier

This comment has been minimized.

@mhier
Copy link
Member Author

mhier commented Jun 3, 2019

Performance seems not bad right now. There is still potential for optimisation, I will create a separate ticket for this (#29).

@mhier mhier closed this as completed Jun 3, 2019
msk-jenkins-documentation pushed a commit that referenced this issue Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement readyForImplementation This ticket has been moved to the "ready for implementation" area on the MSK software group board review A ticket that has been finished and should be reviewed by another developer selected This ticket has been selected for the MSK software group board
Projects
None yet
Development

No branches or pull requests

3 participants