-
Notifications
You must be signed in to change notification settings - Fork 201
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
Pr/189 update #258
base: trunk
Are you sure you want to change the base?
Pr/189 update #258
Conversation
Signed-off-by: Gert-Jaap Glasbergen <[email protected]>
Signed-off-by: Gert-Jaap Glasbergen <[email protected]>
Signed-off-by: Gert-Jaap Glasbergen <[email protected]>
Signed-off-by: Gert-Jaap Glasbergen <[email protected]>
Signed-off-by: Gert-Jaap Glasbergen <[email protected]>
a6fddab
to
837987e
Compare
In particular, several of the commits in this set assume their `blocking_queue`s will be empty by the time the destructor is called. However, this is not guaranteeable, and causes segfaults and/or indefinite hangs when encountered. This commit predominantly ensures that the queues are all `clear()`d appropriately. Signed-off-by: Sam Stuewe <[email protected]>
837987e
to
f86ef09
Compare
I've not yet addressed Anders's suggestion. Hoping to test that later this week. |
@anders94 I did some initial (read: not thorough) testing reducing the validation-thread-count in the coordinators/shards by 1, and see negligible difference (if anything slightly higher latency / lower throughput); but I've not tested at particularly large configurations. Do you have time later today or tomorrow to hop on a call and I can walk through the preliminary results I have and we can see if it feels like I should run a few more tests (i.e., just to eliminate the possibility of noise, or at larger configurations to potentially amplify the effects)? |
Yep, let's do it. |
This simply rebases and updates #189.
I've done a bit of local testing, and this dramatically reduces the impact of enabling sentinel attestations.
@anders94 had a suggestion to prefer
n_threads
==std::thread::hardware_concurrency() - 1
; I'm going to run a few tests to see if one or the other has an obvious performance benefit, and then I believe this is likely ready-to-merge.