System76 recently announced their responsiveness optimizer, System76 Scheduler [0], which basically works as a daemon, adjusting the nice value and the CFS knobs for processes in the box for increased responsiveness. They've claimed that the responsiveness is therefore increased, which I'm also believed so.<p>However, this got me wondering, is there exists any tool that can report the "numbers" (e.g., scheduling latency) regarding to the responsivenss? Maybe Google has such tool for testing regression for Android or Chrome OS, sadly, I didn't managed to find one.<p>Thanks!<p>[0] <a href="https://github.com/pop-os/system76-scheduler" rel="nofollow">https://github.com/pop-os/system76-scheduler</a>
In addition to what others have said:<p>- eBPF script: <a href="https://www.brendangregg.com/blog/2016-10-08/linux-bcc-runqlat.html" rel="nofollow">https://www.brendangregg.com/blog/2016-10-08/linux-bcc-runql...</a><p>- perf sched: <a href="https://www.brendangregg.com/blog/2017-03-16/perf-sched.html" rel="nofollow">https://www.brendangregg.com/blog/2017-03-16/perf-sched.html</a><p>- schedlat: <a href="https://tanelpoder.com/posts/schedlat-low-tech-script-for-measuring-cpu-scheduling-latency-on-linux/" rel="nofollow">https://tanelpoder.com/posts/schedlat-low-tech-script-for-me...</a><p>The last one (written by me) is using /proc/PID/schedstat pseudofile for monitoring % time spent in the CPU runqueue of a single process (not systemwide). I don't always have (root) access for running perf or eBPF scripts (or the old Linux/kernel version don't allow that). But I can still measure how much time a process on a request's critical path (like a RDBMS transaction log writer on commit) spent waiting to get back onto CPU before doing any work.<p>Like others have already said, the OS CPU queuing/scheduling latency is just one component contributing to the total responsiveness/reaction latency of your app.
For input device to screen measurement, high frame rate camera on your phone. Accuracy isn't the best, but what you measure is as real as it gets.
Not sure if it's relevant but I liked the approach of Pavel Fatin in measuring editor latency [0]. It uses OS level input events and actual rendering on screen. So testing the same editor/file with different settings might yield results that are different depending on your scheduling config, while staying close to a "real world" example. He shared [1] the tool he made for the tests.<p>I'd be curious to know your results regardless of the technique used.<p>[0] <a href="https://pavelfatin.com/typing-with-pleasure/" rel="nofollow">https://pavelfatin.com/typing-with-pleasure/</a>
[1] <a href="https://github.com/pavelfatin/typometer" rel="nofollow">https://github.com/pavelfatin/typometer</a>
IIRC the Zen Linux kernel[0] is designed to be more responsive for desktop usage than the mainline Linux kernel. I wonder what metrics these tools would provide on the same exact system except with the 2 different kernels. (also see Liquorix patch set for additional patches on top of Zen[1])<p>[0] <a href="https://github.com/zen-kernel/zen-kernel" rel="nofollow">https://github.com/zen-kernel/zen-kernel</a><p>[1] <a href="https://liquorix.net/" rel="nofollow">https://liquorix.net/</a>
<a href="https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/faq" rel="nofollow">https://wiki.linuxfoundation.org/realtime/documentation/howt...</a><p>This is the goto tool for measuring SCHED_FIFO (realtime) scheduling performance. If you really care about responsiveness in a broad sense (not just user/GUI), this is likely to play some role your testing process.
I wonder if Ben Heck's "Controller Monitor" [1] would help. It's a dedicated low-level (microcontroller-driven) high-speed input sampling/logging platform, with support for reading a light sensor which I believe is used to sense on-screen changes.<p>It has the advantage of using game console joypads as inputs, and hacking them to read the buttons etc directly, i.e. without relying on USB. I imagine a specialized version that just sampled a mouse button would be more useful in the context of a computer running desktop apps.<p>Apologies if I completely misunderstood the intent of this post.<p>[1] <a href="https://www.benheck.com/xbox1monitor/" rel="nofollow">https://www.benheck.com/xbox1monitor/</a>
Weird, the measurement scale they use does not jive with the scale of the knobs being tweaked. For example, `sched_cfs_bandwidth_slice_us` is adjusted by the project's `bandwidth_size` knob. The default is 5000 us, or 5 ms. But the knob they mention it being '5 us'. Same goes for scheduling latency-- its not `us`, its `ms`.<p>And afaik, the 'sauce' used in Liquorix is MuQSS, by Con Kolivas. But the project has been put on ice somewhat recently[0].<p>[0]<a href="https://ck-hack.blogspot.com/2021/08/514-and-future-of-muqss-and-ck-once.html" rel="nofollow">https://ck-hack.blogspot.com/2021/08/514-and-future-of-muqss...</a>
The linux-rt project has a variety of test programs for this:<p><a href="https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/rt-tests" rel="nofollow">https://wiki.linuxfoundation.org/realtime/documentation/howt...</a><p>But beware, "scheduling latency" has very little to do with responsiveness as it would appear to a user of some desktop environment.
I've used `cyclictest` for this before, it's a simple command line application that measures how long it takes to wake up and run a user space process in response to an interrupt. I've used it in the context of minimizing latency for network and audio applications. I'm not sure how much this relates to desktop application responsiveness as there are additional layers involved.
My major latency hangups are not around happy path input to response in a single app but around memory management across multiple apps including multiple browser hosted apps. Optimizing swap to occur AHEAD of the user's next task switch is an entirely unsolved problem.
That would be some tough things to measure.<p>How much can you slow down a cpu anyway? Can you slow it to 1/10th its clock speed? I would think the best way to measure things like this is to slow down the overall system speed as much as possible.
If the computer is slow enough under load, you can use wall clock to count many seconds it takes to start a program that needs to load many libs and data (LibreOffice, Firefox, Blender, GIMP).<p>You can also watch FPS of supertuxkart when the system is under load: <a href="https://www.youtube.com/watch?v=c5bAOJkX_uc" rel="nofollow">https://www.youtube.com/watch?v=c5bAOJkX_uc</a> <a href="https://github.com/hakavlad/le9-patch" rel="nofollow">https://github.com/hakavlad/le9-patch</a><p>But yes, we need a popular well behaved benchmark to measure desktop responsiveness.
I can recommend this one: <a href="https://apps.apple.com/de/app/is-it-snappy/id1219667593" rel="nofollow">https://apps.apple.com/de/app/is-it-snappy/id1219667593</a><p>Was mentioned on HN some time ago.