Check out my first novel, midnight's simulacra!

Counterforce: Difference between revisions

From dankwiki
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
Counterforce is my project for next-level computer cooling, management, modeling, and visualization, borne out of a few years spent watercooling. My first nascent writeup was posted to reddit's [https://www.reddit.com/r/watercooling/comments/wr667q/automated_modeling_of_cooling_system/ r/watercooling] on 2022-08-18. I want to bring Linux to the same levels of hardware awareness long available to Windows users through tools like HWInfo...and then wildly surpass those levels. The ambitious end goal is to <i>automatically model the physical cooling system, and associate it with sensors without human interaction.</i> The rapid rise in power consumption and heat generation driven by recent CPUs, GPUs, and SSDs mean more users concerned with what was once considered "extreme cooling" (AMD's second generation Threadripper processors, for instance, were explicitly marketed with an expectation of water cooling). I expect this project to require several years, along with some custom hardware, and it might prove infeasible for arbitrary builds.
Counterforce is my project for next-level computer cooling, management, modeling, and visualization, borne out of a few years spent watercooling. My first nascent writeup was posted to reddit's [https://www.reddit.com/r/watercooling/comments/wr667q/automated_modeling_of_cooling_system/ r/watercooling] on 2022-08-18. I want to bring Linux to the same levels of hardware awareness long available to Windows users through tools like [https://www.hwinfo.com/ HWiNFO]...and then wildly surpass those levels. The ambitious end goal is to <i>automatically model the physical cooling system, and associate it with sensors without human interaction.</i> The rapid rise in power consumption and heat generation driven by recent CPUs, GPUs, and SSDs means more users concerned with what was once considered "extreme cooling" (AMD's second generation Threadripper processors, for instance, were [https://www.amd.com/en/thermal-solutions-threadripper explicitly marketed with an expectation of water cooling]). I expect this project to require several years, along with some custom hardware, and it might prove infeasible for arbitrary builds.


The core principles of this effort include:
The core principles of this effort include:
Line 10: Line 10:
This is less a single software project than a movement, perhaps a manifest. Changes will be necessary in a variety of tools. A single database of coolant hardware is likely to emerge, though that is not an explicit goal.
This is less a single software project than a movement, perhaps a manifest. Changes will be necessary in a variety of tools. A single database of coolant hardware is likely to emerge, though that is not an explicit goal.


==Stage I: Linux sensor/control support==
github: [https://github.com/dankamongmen/counterforce dankamongmen/counterforce]
 
==Goals==
 
===Stage I: Linux sensor/control support===
Various coolant elements require closed source to properly use them. Perhaps foremost among these are the excellent products of Germany's [https://shop.aquacomputer.de/index.php?language=en Aquacomputer] and California's [https://www.corsair.com/us/en/ Corsair]. Almost all overclocking management requires closed-source Windows-only tools. This is ridiculous: the space of controls and data exported by these devices is fairly small. A fan exposes a single scalar control (PWM level) and generates a single scalar datafeed (revolutions per unit time). A pump is the same. A thermistor generates a single scalar datafeed (measured temperature).
Various coolant elements require closed source to properly use them. Perhaps foremost among these are the excellent products of Germany's [https://shop.aquacomputer.de/index.php?language=en Aquacomputer] and California's [https://www.corsair.com/us/en/ Corsair]. Almost all overclocking management requires closed-source Windows-only tools. This is ridiculous: the space of controls and data exported by these devices is fairly small. A fan exposes a single scalar control (PWM level) and generates a single scalar datafeed (revolutions per unit time). A pump is the same. A thermistor generates a single scalar datafeed (measured temperature).


Line 21: Line 25:
* Development of a cross-platform UI for control and data import
* Development of a cross-platform UI for control and data import


==Stage II: Data discovery and visualization==
===Stage II: Data discovery and visualization===
Logging and visualization of time series data is thankfully pretty much a solved problem, and I expect to leverage various open source tools such as [https://oss.oetiker.ch/rrdtool/ RRDtool], [https://prometheus.io/ Prometheus], [https://grafana.com/ Grafana], and others. Anything that can work with a time series ought suffice for our needs; I do not expect to personally spend time on development of such tools.
Logging and visualization of time series data is thankfully pretty much a solved problem, and I expect to leverage various open source tools such as [https://oss.oetiker.ch/rrdtool/ RRDtool], [https://prometheus.io/ Prometheus], [https://grafana.com/ Grafana], and others. Anything that can work with a time series ought suffice for our needs; I do not expect to personally spend time on development of such tools.


What <i>does</i> come under the purview of this project is discovery of applicable sensors, automatic extraction of that data, and storing it on disk. Furthermore, it is expected that custom microcontroller setups will be in use; defining a lightweight protocol by which those micros can publish structured data, and making it easily integrated into e.g. [[Arduino]] projects, will be critical.
What <i>does</i> come under the purview of this project is discovery of applicable sensors, automatic extraction of that data, and storing it on disk. Furthermore, it is expected that custom microcontroller setups will be in use; defining a lightweight protocol by which those micros can publish structured data, and making it easily integrated into e.g. [[Arduino]] projects, will be critical.


==Stage III: Volume-based coolant control==
===Stage III: Volume-based coolant control===
Competent watercooling has three advantages over a pure air solution:
Competent watercooling has three advantages over a pure air solution:
* more total heat can be removed from the system
* more total heat can be removed from the system
Line 33: Line 37:
For many people, the second advantage (a quieter system) is the primary goal. Yet I know not a single coolant manager that takes noise into account. <i>Noise ought be a fundamental concern of coolant management!</i> It ought be possible to measure ambient noise, possibly taking that into account for a "noise budget". It ought furthermore be possible to determine the noise being generated by cooling, and actively use that as feedback. Once this is accomplished, the user can specify a "cost of noise" function.
For many people, the second advantage (a quieter system) is the primary goal. Yet I know not a single coolant manager that takes noise into account. <i>Noise ought be a fundamental concern of coolant management!</i> It ought be possible to measure ambient noise, possibly taking that into account for a "noise budget". It ought furthermore be possible to determine the noise being generated by cooling, and actively use that as feedback. Once this is accomplished, the user can specify a "cost of noise" function.


==Stage IV: Intelligent coolant control==
===Stage IV: Intelligent coolant control===
Over time, the system will be able to build a <i>predictive</i> noise model, and optimize cooling based off of that. Doing so requires discovery of noise-to-perf relationships of various components by themselves and in combination.
Over time, the system will be able to build a <i>predictive</i> noise model, and optimize cooling based off of that. Doing so requires discovery of noise-to-perf relationships of various components by themselves and in combination.


==Stage V: System discovery and visualization==
===Stage V: System discovery and visualization===
The most speculative part of the project requires establishing the relationship of various cooling and heating components in space. Discovery of absolute geometry is probably not necessary, but effective topology is. In my current design, this will be accomplished through internal microphones and thermal imaging controlled by custom microcontroller firmware.
The most speculative part of the project requires establishing the relationship of various cooling and heating components in space. Discovery of absolute geometry is probably not necessary, but effective topology is. In my current design, this will be accomplished through internal microphones and thermal imaging controlled by custom microcontroller firmware.


I dream of a consumer product, produced at commodity prices, made up of two discrete pieces. Each combines a microphone, an infrared camera, a visual spectrum camera, and wireless data transfer with a microcontroller. The devices are placed in opposite corners of a case. Software can then display the machine's internals, overlaying sensor data and computer heat flow atop that image. The user can simulate the effects of adding or rearranging components. All analysis is fully dynamic, and performed in realtime.
I dream of a consumer product, produced at commodity prices, made up of two discrete pieces. Each combines a microphone, an infrared camera, a visual spectrum camera, and wireless data transfer with a microcontroller. The devices are placed in opposite corners of a case. Software can then display the machine's internals, overlaying sensor data and computer heat flow atop that image. The user can simulate the effects of adding or rearranging components. All analysis is fully dynamic, and performed in realtime.


Noble work, that, work not unbecoming men who strove with Gods.
Noble work, that, [https://www.poetryfoundation.org/poems/45392/ulysses work not unbecoming men who strove with Gods].
 
==Implementation==
My current implementation is set up on [[Schwarzgerät_III|Schwarzgerät]]. Control and visualization takes place on a Libre Computing [[Libre_Le_Potato_AML-S905X-CC|Potato]] using a [[Waveshare_AMOLED|Waveshare AMOLED]].


==See also==
==See also==
* [[Fan Dank]], my custom controller for the [[MO-RA3]] external radiator.
* [[inaMORAta]], my custom controller for the [[MO-RA3]] external radiator.
* [[Waveshare AMOLED|AMOLED]], my custom frontbay 1920x1080 display, and software for it.
* [[Waveshare AMOLED|AMOLED]], my custom frontbay 1920x1080 display, and software for it.
* [[Schwarzgerät_III|Schwarzgerät III]], the machine which inspired this effort, and on which it is being developed.
* [[Schwarzgerät_III|Schwarzgerät III]], the machine which inspired this effort, and on which it is being developed.

Latest revision as of 23:56, 23 November 2022

Counterforce is my project for next-level computer cooling, management, modeling, and visualization, borne out of a few years spent watercooling. My first nascent writeup was posted to reddit's r/watercooling on 2022-08-18. I want to bring Linux to the same levels of hardware awareness long available to Windows users through tools like HWiNFO...and then wildly surpass those levels. The ambitious end goal is to automatically model the physical cooling system, and associate it with sensors without human interaction. The rapid rise in power consumption and heat generation driven by recent CPUs, GPUs, and SSDs means more users concerned with what was once considered "extreme cooling" (AMD's second generation Threadripper processors, for instance, were explicitly marketed with an expectation of water cooling). I expect this project to require several years, along with some custom hardware, and it might prove infeasible for arbitrary builds.

The core principles of this effort include:

  • Users ought not need to know (or pretend to know) the relationships between hardware control and cooling effect.
  • Control of audible noise is almost as important as control of cooling effect.
  • Changes within and without the system ought be integrated into control in realtime, and without user intervention.
  • Quality visualization is critical for understanding the generation and elimination of heat.
  • Closed source has no place in the coolant loop.

This is less a single software project than a movement, perhaps a manifest. Changes will be necessary in a variety of tools. A single database of coolant hardware is likely to emerge, though that is not an explicit goal.

github: dankamongmen/counterforce

Goals

Stage I: Linux sensor/control support

Various coolant elements require closed source to properly use them. Perhaps foremost among these are the excellent products of Germany's Aquacomputer and California's Corsair. Almost all overclocking management requires closed-source Windows-only tools. This is ridiculous: the space of controls and data exported by these devices is fairly small. A fan exposes a single scalar control (PWM level) and generates a single scalar datafeed (revolutions per unit time). A pump is the same. A thermistor generates a single scalar datafeed (measured temperature).

There ought be a single API to access these various hardwares, with unified open source TUI/GUI apps atop them. Linux ought support these controls, including writes to firmware.

Major efforts here would include:

  • Dusting-off and enhancement of the it87 driver for ITE chips
  • Improvement of Linux's smbus and i2c layers
  • Reverse engineering of Aquacomputer and Corsair products to produce Linux drivers
  • Development of a cross-platform UI for control and data import

Stage II: Data discovery and visualization

Logging and visualization of time series data is thankfully pretty much a solved problem, and I expect to leverage various open source tools such as RRDtool, Prometheus, Grafana, and others. Anything that can work with a time series ought suffice for our needs; I do not expect to personally spend time on development of such tools.

What does come under the purview of this project is discovery of applicable sensors, automatic extraction of that data, and storing it on disk. Furthermore, it is expected that custom microcontroller setups will be in use; defining a lightweight protocol by which those micros can publish structured data, and making it easily integrated into e.g. Arduino projects, will be critical.

Stage III: Volume-based coolant control

Competent watercooling has three advantages over a pure air solution:

  • more total heat can be removed from the system
  • less noise can be generated to achieve the same temperatures
  • it looks cool

For many people, the second advantage (a quieter system) is the primary goal. Yet I know not a single coolant manager that takes noise into account. Noise ought be a fundamental concern of coolant management! It ought be possible to measure ambient noise, possibly taking that into account for a "noise budget". It ought furthermore be possible to determine the noise being generated by cooling, and actively use that as feedback. Once this is accomplished, the user can specify a "cost of noise" function.

Stage IV: Intelligent coolant control

Over time, the system will be able to build a predictive noise model, and optimize cooling based off of that. Doing so requires discovery of noise-to-perf relationships of various components by themselves and in combination.

Stage V: System discovery and visualization

The most speculative part of the project requires establishing the relationship of various cooling and heating components in space. Discovery of absolute geometry is probably not necessary, but effective topology is. In my current design, this will be accomplished through internal microphones and thermal imaging controlled by custom microcontroller firmware.

I dream of a consumer product, produced at commodity prices, made up of two discrete pieces. Each combines a microphone, an infrared camera, a visual spectrum camera, and wireless data transfer with a microcontroller. The devices are placed in opposite corners of a case. Software can then display the machine's internals, overlaying sensor data and computer heat flow atop that image. The user can simulate the effects of adding or rearranging components. All analysis is fully dynamic, and performed in realtime.

Noble work, that, work not unbecoming men who strove with Gods.

Implementation

My current implementation is set up on Schwarzgerät. Control and visualization takes place on a Libre Computing Potato using a Waveshare AMOLED.

See also

  • inaMORAta, my custom controller for the MO-RA3 external radiator.
  • AMOLED, my custom frontbay 1920x1080 display, and software for it.
  • Schwarzgerät III, the machine which inspired this effort, and on which it is being developed.