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.

[laur89]

I suggest that you --disable-dynamic-sleep and instead experiment to find a --sleep-multiplier value that works best for you.

Are --sleep-multiplier & --enable-dynamic-sleep (the default opt) conflicting in any way? If so wouldn't it make sense to make using --sleep-multiplier to default to --disable-dynamic-sleep instead, or at least mention the (possible) conflict in manpages? Note this page mentions:

Therefore --sleep-multiplier should generally not be used along with --dsa.

I'm assuming --dsa is same as --enable-dynamic-sleep? --dsa is not described in manpages that ship w/ debian package.

Is it generally safe to use --skip-ddc-checks option? Faffing around with dynamic-sleep & sleep-multiplier options made no measurable difference in my case; if anything, --sleep-multiplier made execution slower. But --skip-ddc-checks improves it wildly:

$ hyperfine 'ddcutil --skip-ddc-checks setvcp  10 20 --bus 11'
Benchmark 1: ddcutil --skip-ddc-checks setvcp  10 20 --bus 11
  Time (mean ± σ):     203.2 ms ±  42.6 ms    [User: 5.5 ms, System: 26.2 ms]
  Range (min … max):   170.3 ms … 288.1 ms    17 runs
 
$ hyperfine 'ddcutil setvcp  10 20 --bus 11'
Benchmark 1: ddcutil setvcp  10 20 --bus 11
  Time (mean ± σ):     347.5 ms ±  56.4 ms    [User: 7.7 ms, System: 41.3 ms]
  Range (min … max):   274.9 ms … 460.2 ms    10 runs

[rockowitz]

There are 4 cases:

--sleep-multiplier not specified, with --enable-dynamic-sleep: The accumulated statistics are used to calculate a sleep multiplier.; the current execution adds to the stats.

--sleep-multiplier specified, with --disable-dynamic-sleep: The specified sleep multiplier is used for the command. The previously accumulated statistics are preserved. New stats are not accumulated.

--sleep-multiplier specified with --enable-dynamic-sleep. Existing stats are discarded. Dynamic sleep starts with the specified value, and new stats are accumulated

--sleep-multiplier specified with --disable-dynamic-sleep. The specified sleep-multiplier value is used, existing stats are not erased. New stats are not accumulated.

Option --discard-dynamic-sleep-cache forces existing stats to be erased at the start of a command.

The page you reference does mention that --dsa is a synonym for --enable-dynamic-sleep. That was the initial name for the option. As the number of options has grown, I've generally transitioned to using --enable-XXX and --disable-XXX for symmetry. However, the old name is still valid in case it is still being used. Option --help reports a reduced set of options in an attempt to be less overwhelming. It reports the favored names --enable-dynamic-sleep and --disable-dynamic-sleep. Option --hh on the other hand reports the full set of options recognized by the parser, including deprecated variants such as --dsa. The man page generally only reports the reduced set of options.

Finally, when ddcutil starts it looks for monitors and tests whether they support DDC. Those tests are expensive, and there's no point in doing them over and over again if we know the monitor supports DDC. Hence --skip-ddc-checks. Note however that if you set an overly low sleep-multiplier, whether or not you specify --skip-ddc-checks DDC operations will fail.

[laur89]

Thanks! First case is the default right?

Note however that if you set an overly low sleep-multiplier, whether or not you specify --skip-ddc-checks DDC operations will fail

Expected this to be the case as well, but even with 0.1 value it never seems to fail, but will always increase the execution time. Only decreasing the value by a few orders of magnitude to .001 or .0001 there's some improvement in time but I'd say it's still rather minor:

$ hyperfine 'ddcutil setvcp  --sleep-multiplier .001 10 20 --bus 11'
Benchmark 1: ddcutil setvcp  --sleep-multiplier .001 10 20 --bus 11
  Time (mean ± σ):     320.7 ms ±  47.3 ms    [User: 7.6 ms, System: 35.5 ms]
  Range (min … max):   269.5 ms … 392.9 ms    10 runs

Using explicit --{enable,disable}-dynamic-sleep options make no obvious difference, but perhaps longer term stats collection could make a meaningful difference. So at least for me I'll go with defaults with just --skip-ddc-checks added, unless there's some other potent performance boost out there.

[laur89]

@rieje just FYI I was pondering with pretty much the same issues as you, so ended up writing a trivial python daemon to take care of brightness control that depends on ddcutil for external displays: https://github.com/laur89/bctl

Doesn't depend on desktop environment, in fact it has no GUI component to it; also controls laptop displays.

It has a daemon service that caches current brightness values in memory, so bumping brightness up or down is less error prone slow compared to when done in bash.

Quick start:

$ pipx install bctl

# start the daemon
$ bctld

# bump up brightness:
$ killall -s SIGUSR1 bctld

If you bind your brightness change keys to the killall commands sending SIGUSR1 & SIGUSR2 signals, it's safe to spam them. Events are consumed within msg_consumption_window_sec window and accumulated, so ddcutil is really invoked at minimum every msg_consumption_window_sec seconds.