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.

Raspberry Pi 4
Dataset not published

Universe capacity, CPU and temperature fields await a reviewed run.

Pending verification
Raspberry Pi 5
Dataset not published

Universe capacity, CPU and temperature fields await a reviewed run.

Pending verification
24-hour run
Report not published

Continuous-operation logs and the final integrity check are still required.

Pending verification
72-hour run
Report not published

Extended-operation logs and recovery observations are still required.

Pending verification
Publication rule

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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

An em dash means that no reviewed measurement has been published.
DeviceStorageAudioDurationVerified universesCPUPeak temperatureStatus
Raspberry Pi 4microSDOffPending verification
Raspberry Pi 4microSDOnPending verification
Raspberry Pi 4USB SSDOff / onPending verification
Raspberry Pi 5microSDOffPending verification
Raspberry Pi 5microSDOnPending verification
Raspberry Pi 5USB SSDOff / onPending 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.

Recovery acceptance criteria and current publication status.
ScenarioWhat the test must verifyPublished result
Planned application restartThe local interface returns, system status is readable and the saved startup configuration is handled as documented.Pending verification
Unexpected process stopThe watchdog detects the stopped process, restarts it and leaves an observable recovery record.Pending verification
Device power restoredThe Raspberry Pi boots and CUE/IO follows the explicitly configured startup action only after required resources are ready.Pending verification
Network interruptionThe interruption is visible and the application returns to a defined state when the Art-Net network becomes available again.Pending verification
Missing audio deviceCUE/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.

  1. Stop recording and playback, then wait for CUE/IO to confirm that the active operation has finished.
  2. Use File Manager to export or download each required show and its associated audio to an operations computer.
  3. Store the site name, backup date and CUE/IO version with the exported files.
  4. Keep a second copy on storage that is not attached to the production Raspberry Pi.
  5. Import the backup during a planned maintenance test, then open and play a short section to confirm the restore.
  6. 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.

Results are configuration-specific

A result for one Raspberry Pi, storage device, cooling setup and software release is not a guarantee for every installation.

Art-Net is Ethernet-based

CUE/IO records and plays Art-Net lighting data. Physical DMX512 equipment requires an appropriate Art-Net node or interface.

LTC is an input

CUE/IO receives incoming LTC to trigger prepared shows; it is not presented as an LTC generator.

Audio hardware varies

Audio is optional. Audio-enabled results apply to the identified Linux-compatible USB audio device and configuration.

Initial activation needs internet

Local recording, control and playback can continue on the local network after activation, but initial licence activation requires internet access.

External systems remain external

A CUE/IO benchmark cannot validate the reliability of a site's network switch, Art-Net nodes, fixtures, audio hardware or power infrastructure.

Capacity is not “unlimited”

The safe workload depends on the exact setup. An empty result field is not a claim of unlimited universes.

Unreviewed data stays unpublished

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.