DDC/CI wait times, optimizing for brightness control

[rieje]

I have a simple shell script that controls brightness of monitor, bound to hotkey to increase/decrease brightness by a set interval. Performance is not great, trying to see if I can get noticeably improved performance. Taking a look at https://www.ddcutil.com/performance_options/, still trying to figure out which makes sense.

Noob questions:

• Does the physical monitor store any configure settings set by ddcutil or similar utilities? E.g. is --sleep-multiplier and similar settings only affecting the command it was used on? I'm not sure what's the point of sleep intervals introduced by the specification. It seems like --enable-dynamic-sleep is the default, so I suppose --sleep-multiplier probably doesn't help.

• Can I set $HOME/.cache/ddcutil to a different path at leas for dsa cache? I prefer to set it to /tmp (tmpfs) so it clears on system boot. I would rather not have persistent storage have files get written to it every time I change monitor brightness (especially when it involves multiple invocations to get to a satisfactory brightness value.

Right now I have exec ddcutil --bus=5 --skip-ddc-checks --noverify --lazy-sleep setvcp 10 + 10 but honestly if I omit --skip-ddc-checks --noverify --lazy-sleep I'm not sure if there's any difference in performance, especially if I run the command multiple times (i.e. held down on a hotkey it's bound to). So it's doubtful I can get anything better than simply the defaults with a --bus, in which case I guess my only question is whether path for cache is customizable.

[rockowitz]

The only information stored in a monitor are the values of persistent features, e.g. brightness.

In general a DDC/CI operation takes one of two forms: (a) send a request packet to the monitor, and after a specified delay read a response packet, or (b) send a request packet and delay a specified time before initiating another operation. The purpose of the delay is to give the monitor sufficient time to process the request and possibly create a response.

If ddcutil simply follows the DDC/CI specification, approximately 90% of its estimated time is spent sleeping to allow for the required delays. The processors in monitors have in general gotten much, much faster in the years since the DDC/CI spec was published, and it is usually possible to use significantly shorter delays, reducing the time ddcutil spends sleeping. That's the purpose of the sleep multiplier.

The sleep multiplier can be specified explicitly using option --sleep-multiplier. That requires some trial and error to find a value that works best. The newer --enable-dynamic-sleep lets ddcutil find an optimal value by slowly adjusting the sleep-multiplier down and up, based on data from prior requests. It requires data accumulated over many operations. If the cache file doesn't exist, the dynamic sleep adjustments start with a value of 1.0. So erasing the cache with each boot essentially makes makes dynamic sleep useless. I suggest that you --disable-dynamic-sleep and instead experiment to find a --sleep-multiplier value that works best for you.

Option --lazy-sleep improves performance by causing ddcutil to sleep not immediately after an operation, but instead prior to the next operation on the monitor, taking into account the time that has elapsed. As practical matter the performance gains turn out to be minor.

Without --bus and --skip-ddc-checks each ddcutil invocation essentially performs a full dectect operation. Especially with multiple monitors, more time is spent in the detection phase than actually performing the requested operation.

ddcutil is extensively instrumented. Option --stats lets you see the effect of the options you've set.