Query re Minimum Ledger Time and Time In General for Deduplication

[quidagis]

In the DA_SDK, Page 248/577 it says re Deduplication:

Use generous values for the deduplication time. It should be large enough such that you can assume the command was permanently lost if the deduplication time has passed and you still don’t observe any effect of the command on the ledger (i.e. you don’t see a transaction with the command ID via the transaction service).

The setting of command IDs deterministically makes sense but after going through the in-document links from Deduplication > Ledger API > Deduplication Time > Google Protobuf I am still none the wiser.

@cocreature asked a question in relation to min_ledger_time_abs and min_ledger_time_rel in:

Semantics of min_ledger_time

I am a bit confused how I am supposed to use min_ledger_time_abs and min_ledger_time_rel. Let’s say I have a command that takes quite a long time (relative to the skew) to interpret and I’m running on a ledger with a relatively short min and max skew (e.g. the 30s defaults is Sandbox). My command does not use getTime and I am happy for it to take a while to be recorded. If I don’t set min_ledger_time, the submission fails because ledger time is before the allowed range. Now my understanding is…

I followed through that thread and see the mechanics behind min_ledger_time_abs etc. From that, it seems that the only way to accurately assess & implement these boundaries is to execute your commands, benchmarking their performance, then editing the time-related settings as required?

Is that a reasonable premise or is there a more acceptable start figure of 15 seconds etc?

[cocreature]

My recommendation would be to just start out with the defaults which should be good enough for most applications.

If you encounter errors due to violations of the time model, then you can try increasing it but note that as mentioned in the linked thread, you also need to change the max skew on the ledger for this to be effective.