Universe capacity, CPU and temperature fields await a reviewed run.
CUE/IO engineering · Reliability
CUE/IO Art-Net reliability testing for Raspberry Pi.
This page documents how CUE/IO is evaluated on Raspberry Pi 4 and Raspberry Pi 5. It covers Art-Net load, synchronized audio, temperature, long-duration operation, recovery and storage. Numeric results are published only after controlled runs are complete and their logs have been reviewed.
Evidence status
Published method. Results still under review.
The test categories and reporting rules are defined now. Each result will remain marked pending until its hardware configuration, software version, raw log and pass/fail decision have been checked together.
Universe capacity, CPU and temperature fields await a reviewed run.
Continuous-operation logs and the final integrity check are still required.
Extended-operation logs and recovery observations are still required.
CUE/IO will not turn an unreviewed benchmark, a single short run or the built-in benchmark estimate into a public performance claim.
Benchmark methodology
A repeatable test, not a best-case screenshot.
Every published run must identify the exact device and workload so another operator can understand what the number does—and does not—represent.
Freeze the configuration
Record the Raspberry Pi model and RAM, CUE/IO release, operating-system image, kernel, power supply, cooling, ambient temperature, network layout and storage model.
Define the workload
Record the Art-Net universe count, packet rate, show duration, output mode and whether synchronized audio is off or on. Use the same show data for comparable runs.
Capture system data
Log CPU use, temperature, memory, process state and relevant CUE/IO errors throughout the run—not only at the start and finish.
Test both audio states
Repeat the workload with audio disabled and enabled. Document the audio interface, sample rate and channel configuration used for the audio-enabled run.
Run endurance stages
Complete a 24-hour run before the 72-hour run. Keep the same acceptance criteria and archive the full log, interruption record and final show-file check.
Review before publishing
Publish a result only when the configuration, logs and outcome agree. Keep failed runs and deviations in the report instead of silently discarding them.
Pi 4 & Pi 5 benchmark
Verified results will appear here.
The table intentionally contains no estimated capacities. Separate rows preserve the difference between storage type and audio state.
| Device | Storage | Audio | Duration | Verified universes | CPU | Peak temperature | Status |
|---|---|---|---|---|---|---|---|
| Raspberry Pi 4 | microSD | Off | — | — | — | — | Pending verification |
| Raspberry Pi 4 | microSD | On | — | — | — | — | Pending verification |
| Raspberry Pi 4 | USB SSD | Off / on | — | — | — | — | Pending verification |
| Raspberry Pi 5 | microSD | Off | — | — | — | — | Pending verification |
| Raspberry Pi 5 | microSD | On | — | — | — | — | Pending verification |
| Raspberry Pi 5 | USB SSD | Off / on | — | — | — | — | Pending verification |
A future result will include the tested CUE/IO version, hardware details, workload, pass criteria and report date beside the measurement.
Load & endurance
What each test must answer.
Capacity, temperature and uptime are related, but they are not interchangeable. Each category has its own observations and acceptance decision.
Art-Net universes
Find the highest tested workload that meets the documented integrity and stability criteria on that exact configuration.
- Record universe count and packet rate
- Use a defined Art-Net source and network topology
- Review errors, process state and output integrity
- Do not extrapolate beyond the tested workload
CPU & temperature
Track system load for the full run and report the cooling and ambient conditions beside the figures.
- Report sustained and peak CPU observations
- Report peak temperature and any throttling event
- Identify cooling, enclosure and power supply
- Keep warm-up data separate from steady-state data
Audio off / audio on
Repeat comparable Art-Net workloads in both states so the cost of synchronized audio is visible rather than hidden.
- Use the same lighting show for both runs
- Identify the USB audio hardware
- Record sample rate and channel configuration
- Check playback synchronization after the run
24 / 72-hour operation
Use continuous runs to expose errors that a short benchmark cannot show.
- Complete and review the 24-hour stage first
- Log restarts, warnings and resource growth
- Record every planned or unplanned interruption
- Verify the show and audio after completion
Restart & watchdog
Recovery is tested as a sequence.
A restart is not considered successful merely because a process exists again. The interface, selected startup behaviour and required outputs must return to a known state.
| Scenario | What the test must verify | Published result |
|---|---|---|
| Planned application restart | The local interface returns, system status is readable and the saved startup configuration is handled as documented. | Pending verification |
| Unexpected process stop | The watchdog detects the stopped process, restarts it and leaves an observable recovery record. | Pending verification |
| Device power restored | The Raspberry Pi boots and CUE/IO follows the explicitly configured startup action only after required resources are ready. | Pending verification |
| Network interruption | The interruption is visible and the application returns to a defined state when the Art-Net network becomes available again. | Pending verification |
| Missing audio device | CUE/IO reports that the required audio path is unavailable instead of presenting an unverified successful start. | Pending verification |
Storage & operations
microSD versus SSD—and a backup you can restore.
The storage comparison will use identified media and the same workload. The operational backup procedure is usable now and stays separate from future performance results.
Storage comparison
No winner is declared until matching microSD and USB SSD runs have been reviewed.
- Media identityManufacturer, model, capacity and interface
- WorkloadSame Art-Net show, universe count, duration and audio state
- ObservationsWrite behaviour, errors, temperature and recovery after restart
- Integrity checkExport, reopen and play the completed show
- Current resultPending verification
Recommended backup procedure
Back up shows before changing storage, updating a production device or modifying an unattended installation.
- Stop recording and playback, then wait for CUE/IO to confirm that the active operation has finished.
- Use File Manager to export or download each required show and its associated audio to an operations computer.
- Store the site name, backup date and CUE/IO version with the exported files.
- Keep a second copy on storage that is not attached to the production Raspberry Pi.
- Import the backup during a planned maintenance test, then open and play a short section to confirm the restore.
- Document licence activation or transfer separately; a show-file backup is not a licence backup.
Known limitations
What this page does not promise.
Clear boundaries make a reliability result useful. These constraints apply even after verified benchmark figures are published.
A result for one Raspberry Pi, storage device, cooling setup and software release is not a guarantee for every installation.
CUE/IO records and plays Art-Net lighting data. Physical DMX512 equipment requires an appropriate Art-Net node or interface.
CUE/IO receives incoming LTC to trigger prepared shows; it is not presented as an LTC generator.
Audio is optional. Audio-enabled results apply to the identified Linux-compatible USB audio device and configuration.
Local recording, control and playback can continue on the local network after activation, but initial licence activation requires internet access.
A CUE/IO benchmark cannot validate the reliability of a site's network switch, Art-Net nodes, fixtures, audio hardware or power infrastructure.
The safe workload depends on the exact setup. An empty result field is not a claim of unlimited universes.
Built-in benchmark output and short test runs remain operational guidance until the complete evidence package is reviewed.
Plan the installation. Then test the real system.
Read the operating guide or get a CUE/IO licence for one Raspberry Pi.
