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
DAQ optimized usage of FU file locking (12_0_X backport) #35221
Conversation
exclusive lock, so it is ensured to be written in the same order as notified from the file broker service. Creation of EoLS was moved out of the shared section. Check of directory existing was moved out of the critical section * silence warnings of TCDS FED mismatch when using test TCDS range * set file locking monitoring state at the correct location
A new Pull Request was created by @smorovic (Srecko Morovic) for CMSSW_12_0_X. It involves the following packages:
@jpata, @cmsbuild, @emeschi, @smorovic, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here
|
@cmsbuild please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-09a507/18468/summary.html Comparison SummarySummary:
|
+1 |
+reconstruction
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_12_0_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_12_1_X is complete. This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
backport of #35218 |
+1 |
PR description:
A local file lock on the filter unit machine is used in online HLT when acquiring a file from a builder unit (via file broker service), ensuring that files appear locally in the same order they are acquired (otherwise it is a race between threads in process acquiring it). Order is important to ensure proper local bookeeping of events processed in a lumisection.
An exclusive file lock has been used for this, but it turns out this can be relaxed in most cases to a shared lock, while only end-of-lumi marker needs to remain exclusive. This is implemented in this PR.
Test module for generating fake data also gains ability to generate random payload, which will be useful for storage and transfer tests in the future, as it generates data with low compressibility.
PR validation:
It has been tested in DAQ3 system which is currently in commissioning. Performance of HLT readout appears improved, especially in conditions of increased network latency due to saturated network bandwith. Functionally no issues are seen with this patch.
Unit test was modified to use the new feature for creating input data using rand(), so validity is verified by this test.
if this PR is a backport please specify the original PR and why you need to backport that PR:
Backport of #35218