Optimize LLMQs sending of sig shares #2704
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Profiling has shown that optimistic send causes measurable slowdowns when many messages are pushed, even if the sockets are non-blocking. Better to allow disabling of optimistic sending in such cases and let the network thread do the actual socket calls.
This adds the reading side of a pipe to the read-set when calling select(). Writing to the writing side of the pipe then causes select() to wake up immediately. Otherwise it would wait for the timeout of 50ms, even if there is data that could possibly be sent. This is useful when many messages need are pushed with optimistic send being disabled. After all messages have been pushed, WakeSelect() can then wakeup the select() thread and force a re-check for pending data to send. This is currently only implemented for POSIX compliant systems as we assume that heavy-load daemons (like masternodes) are usually run on Linux.
And instead let the network thread do the actual sending.
Author
|
FYI, it's possible that disabling optimistic send for ALL messages would be the best actually, but I'm not sure how we would measure/test this. For this, we'd need to implement the wakeup logic for Windows as well (EDIT: can be done by using a force closed udp socket for example, which wakes up select due to an "error"). |
pipe2 is not supported on MacOS
UdjinM6
reviewed
Feb 15, 2019
panleone
pushed a commit
to panleone/PIVX
that referenced
this pull request
Nov 14, 2024
Fuzzbawls
added a commit
to PIVX-Project/PIVX
that referenced
this pull request
Nov 15, 2024
c7e2beb scripted-diff: Refactor llmq type consensus param names (dashpay#3093) (UdjinM6) af7bb99 Re-verify invalid IS sigs when the active quorum set rotated (dashpay#3052) (Alexander Block) be20a71 Remove recovered sigs from the LLMQ db when corresponding IS locks get confirmed (dashpay#3048) (Alexander Block) 802a933 Don't wake up select if it was already woken up (dashpay#2863) (Alexander Block) 436300d Disable optimistic send in PushMessage by default (dashpay#2859) (Alexander Block) 44ad484 Optimize LLMQs sending of sig shares (dashpay#2704) (Alexander Block) e01ad46 Fix db leaks in LLMQ db (dashpay#2914) (Alexander Block) d2a2d15 Print inputs on which we voted and quorums used for signing (dashpay#2907) (Alexander Block) dce46ad Bail out in few more places when blockchain is not synced yet (dashpay#2888) (UdjinM6) 965a4a7 Use lazy BLS signatures more often and don't always verify self-recovered sigs (dashpay#2860) (Alexander Block) f4a5a04 cherry pick dashpay#2889 (UdjinM6) Pull request description: each commit backports a different PR ACKs for top commit: c7e2beb Duddino: utACK c7e2beb Liquid369: utACK c7e2beb Tree-SHA512: 86425039d01990ff04eea95f5ea4bee4821eaa80c33bab147d5b9407589c799c8293c2da5d5faf10e7e66b65d568444318c87fc274f39b42d2b69b80abafb417
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Profiling has shown that in the
CSigSharesManager::WorkThreadMainthread a lot of time (10%-20%) is spent in the socketsend()method. I assume this is not CPU intensive and simply blocking/waiting time, even though the sockets are in non-blocking mode.It happens because
CConnman::PushMessagedoes "optimistic sending" when thevSendMsgbuffer is empty. One would assume that callingsend()is cheap on a non-blocking socket, but this seems to not be the case.With this PR,
WorkThreadMainwill always push sig shares related messages intovSendMsgand then let the network thread handle the actual sending.