Intelligent Automated Stress Testing: Target-Power Modeling and Multidimensional Result Analysis
This project is a distributed server stress-testing system built around Golang agents and a controller. It uses pre-tests to model component load-to-power responses, estimates a workload mix for a target wattage, preserves telemetry and logs during execution, and presents long-duration results through Grafana with an optional AI-assisted review path.
This case belongs to my Advantech software engineering portfolio. The public version describes the method, architecture, and published charts without exposing equipment configurations, actual workload commands, model coefficients, internal thresholds, or test data.
Two Engineering Problems: Applying Load and Interpreting Results
A fixed burn-in script can create high load, but it does not necessarily bring total system power close to a requested target. CPU, memory, Ethernet, GPU, and storage I/O also have different power responses, so assigning the same percentage to every workload does not guarantee the desired system wattage.
Long-duration tests also produce temperature, fan-speed, power, frequency, and throttling data at the same time. Reviewing separate time-series charts makes it difficult to compare load regions, residence time, and potential thermal behavior quickly.
I therefore separated the system into two complementary paths: Predict/Control establishes the stimulus, while Analyze organizes and reviews the response.
Distributed Execution Architecture
- Golang CLI agent: Runs selected low-level workloads on each SUT, collects state, and keeps logs locally. The design includes local log buffering to reduce data-loss risk during temporary disconnection; the public material does not include a recovery test.
- Controller: Manages one-to-many connections, test commands, and reservations while receiving status and data from agents.
- Telemetry/analysis: Routes test data to Grafana dashboards and retains an interface for optional AI-assisted interpretation.
Concept diagram: operator, controller, agents/SUTs, and the Grafana/AI-backend data flow. It is not evidence of deployment scale or availability.
Pre-Test and Power-Response Modeling
The system first changes component load step by step and observes the relationship between load and power. The publicly described model forms include:
CPU: Approximately Linear Response
Within the observed range, CPU power can be represented by an approximate linear model:
$$P_{CPU}(x) \approx ax+b$$
Memory/Ethernet: Saturating Response
Memory and Ethernet rise quickly in the lower-load region and then approach saturation. The article describes this as an inverse-exponential or saturation curve, but does not publish the complete formula, coefficients, or residuals.
 Illustration: contrasts linear and saturating responses. The plotted points and curves are not treated as published measurement data.
GPU, RAM, FIO/storage I/O, and Ethernet can all be workload inputs. Because the public material defines curve forms only for CPU and memory/Ethernet, I do not extend those same models to GPU or I/O.
Deriving a Workload Mix from Target Wattage
After a user enters target system wattage, the algorithm uses pre-test responses and component weights to select candidate intensities for CPU, GPU, memory, FIO/I/O, and Ethernet scripts. The purpose is to approach the requested power condition more systematically than a fixed-percentage script.
The public material does not include the objective function, constraints, search strategy, model error, target-power tolerance, or cross-platform statistics. I therefore use “estimate” and “approach,” not “precisely hit.” A formal validation should compare requested and measured wattage using absolute/relative error and report configurations and ambient conditions separately.
Multidimensional Grafana Review
The original design aimed to combine temperature, fan speed, system power, and accumulated residence time/frequency in one view to reduce the reading cost of long-running tests.
Actual result screen: power, fan level, and multiple temperature series are visible. Because the public axes and legend do not map perfectly to the earlier textual “4D” definition, I do not assign one fixed meaning to every visual encoding.
Actual dashboard: the screen contains multiple temperatures, fan speed/level, power, frequency, and throttling state. It demonstrates the data shown in that run, not a universal field contract for every deployment.
Boundary of AI-Assisted Analysis
The architecture retains a path for sending charts or data to a vision-AI module for summaries and candidate risk observations. The public material provides no model name, prompt, output sample, ground truth, accuracy, or false-positive evaluation, so I do not claim autonomous diagnosis of thermal risk or performance bottlenecks.
The safer role is to let AI translate long-duration charts into observations that require engineering confirmation. Final conclusions must return to raw telemetry, test conditions, sensor validity, and engineering thresholds.
Verifiable Outcome and Limits
The public artifacts support the distributed agent/controller architecture, pre-test modeling method, target-power workload composition, and Grafana result surfaces. They do not include raw data, fit reports, power-error distributions, disconnection-recovery tests, AI evaluation, or cross-platform benchmarks.
A measurable next iteration should track at least:
- MAE/relative error and time-to-target for requested wattage.
- Stability of model coefficients and residuals across configurations.
- Log completeness and recovery time after an agent disconnects.
- Precision, recall, and edit rate after engineers review chart/AI observations.
Technology
Golang · Python · Linux · Server BMC/IPMI · Distributed agents · Mathematical modeling · Grafana · Stress workloads · CI/CD
