-
Notifications
You must be signed in to change notification settings - Fork 136
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
Have JDS ping local mempool less frequently #1299
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1299 +/- ##
=======================================
Coverage 19.30% 19.30%
=======================================
Files 164 164
Lines 10849 10849
=======================================
Hits 2094 2094
Misses 8755 8755
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Bencher Report
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
nACK on setting it to I'm running some tests to find the most accurate value, I'll keep you posted |
Do you expect anyone to run the local config example on mainnet? Because on testnet4 and the custom signet the transaction frequency is pretty low. |
We are doing it in the benchmarking-tool, which leads to an increased bandwidth usage because of |
Maybe the benchmarking-tool should have its own config file though? |
Yes, it already has its own config file, my point was that we shouldn't put an high value because otherwise we are going to have too many PMT messages. I'm ok with putting the value back to 1s at most, but not 5s. |
Otherwise Bitcoin Core -debug=rpc logging becomes too noisy.
Ok, changed to 1s. |
@@ -28,4 +28,4 @@ core_rpc_pass = "password" | |||
# Time interval used for JDS mempool update | |||
[mempool_update_interval] | |||
unit = "secs" | |||
value = 0.1 | |||
value = 5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @GitGab19 did some experiments and found an optimal value for this
value = 5 | |
value = 0.5 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A typical terminal on macOS is just 25 lines, so you can't see any other log messages, like SubmitSolution after just 12 seconds with that default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1s is perfect to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tack
Otherwise Bitcoin Core
-debug=rpc
logging becomes too noisy.It's probably also too high for production on mainnet, "distracting" the node from its other work, but that's something that benchmarking might find.