config: add commit time parameter #5187
Conversation
joostjager
force-pushed
the
config-commit-time
branch
2 times, most recently
from
0658893
to
9ca8c9c
Compare
| @@ -289,6 +293,8 @@ type Config struct { | |||
| MaxChanSize int64 `long:"maxchansize" description:"The largest channel size (in satoshis) that we should accept. Incoming channels larger than this will be rejected"` | |||
| CoopCloseTargetConfs uint32 `long:"coop-close-target-confs" description:"The target number of blocks that a cooperative channel close transaction should confirm in. This is used to estimate the fee to use as the lower bound during fee negotiation for the channel closure."` | |||
|
|
|||
| CommitTime time.Duration `long:"commit-time" description:"The maximum time that is allowed to pass between receiving a channel state update and signing the next commitment. Setting this to a longer duration allows for more efficient channel operations at the cost of latency."` | |||
|
|
|||
There was a problem hiding this comment.
nit: instead of "more efficient channel operations" you could write "larger channel throughput" as that may be more descriptive for this parameter.
There was a problem hiding this comment.
I considered that, but as it is currently, increasing this value doesn't yet increase throughput dramatically. There are just too many non-batched txes going on. I felt that 'larger channel throughput' would overpromise a bit, even though throughput should indeed be slightly larger.
sample-lnd.conf
Outdated
| ; The maximum time that is allowed to pass between receiving a channel state | ||
| ; update and signing the next commitment. Setting this to a longer duration | ||
| ; allows for more efficient channel operations at the cost of latency. | ||
| ; commit-time=50ms |
There was a problem hiding this comment.
small nit: would you be opposed to something more like channel-commit-interval?
two reasons in my head:
- increase specificity and indicate that this relates to channels (we already have
db.batch-commit-interval) and leave room for other types of commit paramters. could even be more specific, e.g.channel-sign-commit-interval - reuse the
intervalterminology already present indb.batch-commit-intervaland in the much of the code base
There was a problem hiding this comment.
I picked commit-time because it matches the option name in c-lightning. Not a particular good reason. Renamed to what you're suggesting.
joostjager
force-pushed
the
config-commit-time
branch
2 times, most recently
from
bd4d074
to
ae7863d
Compare
|
Should I also add |
joostjager
force-pushed
the
config-commit-time
branch
from
ae7863d
to
ffd346e
Compare
|
Added |
Channel state update batching is an important mechanism to increase the throughput of a Lightning node. With high degrees of batching many synchronous and expensive disk writes can be avoided. Batching comes at the cost of increased latency. For high-frequency (streaming) applications this may be an acceptable trade-off.
This PR simply makes the batch timer configurable to allow node operators to tune their node to a particular traffic pattern.
As a follow-up it could be worth to consider a dynamic batch interval based on system load ("commit on idle").