What does recording cost your application?

At this workload

750 sample blocks/second; three 60-second runs per build; the same application and board.

At this workload, CPU busy averaged 8.29% with recording off, 10.41% with ViewAlyzer and 10.80% with Percepio. The increases are 2.12 and 2.51 percentage points, respectively. These include active probe collection, not just recorder instructions.

Mean receive-to-summary time was 56.52 us off, 62.62 us with ViewAlyzer and 62.85 us with Percepio. The largest timer errors were 2 / 4 / 4 us, respectively, on a 10,000-us interval, with mean absolute errors of 0.02 / 0.42 / 0.26 us. These are observed maxima, not worst-case guarantees.

The comparison is specific to these recorder configurations and this collection path. Event formats and coverage differ. A lower CPU number alone does not establish a better recorder. Application loss and trace loss are separate outcomes: missing application replies total 0 / 0 / 0 for Recorder off / ViewAlyzer / Percepio; post-sync missing trace events total 0 / 210 for ViewAlyzer / Percepio.

Application impact

Each entry is the average of three run-level values, followed by their observed minimum to maximum. Delta = that recorder minus Recorder off; the last column is ViewAlyzer minus Percepio, so a negative value means ViewAlyzer measured lower. Its tag reads the difference from ViewAlyzer's side: better or behind when the two recorders' three-run ranges do not overlap, slightly better or slightly behind when they do, and equal when the means agree. CPU deltas are percentage points; other deltas use the row's units. Smaller timing values mean shorter measured times; higher delivery means more replies. These ranges are not confidence intervals.

Graphs and variation

Three runs per recording mode, with all three modes on the same axis for each metric. Lines connect repetitions, not elapsed time. The numbers below each graph are the means of the three run-level values.

Download graphs · SVG ↗ · Exact values are in the measurement data. Three repetitions are not a broad statistical characterization; observed ranges are not confidence intervals.

What the application does

The board is a small FreeRTOS telemetry gateway. A PC supplies repeatable sensor-like data: 512-byte blocks, each containing 31 samples on eight channels. Three application tasks receive blocks, process them, and handle commands. Two queues manage a 16-block pool and pending work. The worker applies gain and a low-pass filter, computes peak and mean-square summaries, and returns an 88-byte UDP reply. A mutex protects settings; 20 gain commands/second exercise it. A 10-ms software timer checks input freshness. Network, idle, timer-service and startup tasks also run. No physical ADC is used.

No custom per-block user trace or ISR entry/exit logging is present. Both recorders use the ordinary RTOS hooks. The same small independent measurements stay enabled in all builds; this is minimal instrumentation, not zero instrumentation.

Measurement notes

Board-side times are read from a free-running microsecond counter at the points named above; the host round trip is timed by the PC. Timer error describes the callback interval, not interrupt-entry latency. Delivery compares host sends, firmware receive/processing/send counts and unique replies; loss is retained, not filtered out of the report.

TIM2 provides the same nominal 1-MHz measurement clock in all builds; recorder timestamps are not used for application timing. CPU/timer counters cover reset to final status, including brief host startup/drain; throughput uses the requested send interval. p99 and observed maxima are not worst-case bounds. No application deadline or acceptable loss budget was supplied, so these results cannot establish deadline compliance.

Recorder settings and collection

ViewAlyzer's periodic setup retransmission is disabled in this comparison: setup packets go out at startup and once when the reader attaches, the same host-started model as Percepio. Retransmission exists for hosts that attach to an already-running target without a reset, which this RAM-loaded flow never does. ViewAlyzer's housekeeping runs in the application's existing priority-3 heartbeat task. The stock Percepio FreeRTOS port adds its own trace-control task (priority 1, 10-ms period). Memory, object and ancillary hook coverage/encoding are not identical between products; event counts are not units of equivalent information. Percepio uses the stock C RTT writer, no extra internal stream buffer and a 32-byte down-command buffer. Its stream buffers lie in AXISRAM1 under a non-cacheable MPU overlay; ViewAlyzer's ring and the RTT control block lie in AXISRAM2. Recorder code was not optimized for this comparison.

Both recording modes are drained continuously through the same local ST-LINK, same probe-rs 0.30.0 reader, requested/accepted 24-MHz SWD and requested 1-ms polling. Each read collects available contiguous bytes and acknowledges consumption. A poll can take longer than 1 ms; the report includes actual collection totals. Non-halting debug reads still generate bus traffic. Raw files are decoded/checked after measurement, so neither mode performs live GUI decoding. The off build has no reader attached during measurement.

Trace health

Capture windows include startup, warmup and stopping; application measurement lasts only the specified send interval. Percepio checks use its public PSF header, entry table, event lengths, sequence numbers and timestamps. This is structural validation, not full Tracealyzer semantic analysis. Its firmware drop counter is unsupported; sequence gaps, not the zero placeholder in firmware status, measure missing events. The 16-bit sequence check assumes fewer than 65,536 consecutive missing events; the collector is continuously active and observed gaps are far below that, but a whole unobserved sequence wrap cannot be ruled out by sequence numbers alone. ViewAlyzer uses the existing offline decoder; discarded startup bytes before synchronization are reported separately.

All completed recording runs must also remain active, return zero internal error flags and finish the reader successfully; those conditions are checked independently of event loss. Counts and full reader statistics are retained in measurements.json.

Load selection

The offered load is the highest rate at which both recorders' streams fit this collection path. Percepio's stream is about twice the byte rate of ViewAlyzer's, and at 2,000 blocks/s it exceeds what the local ST-LINK reader sustains:

Those checks lose roughly 48% of Percepio events despite active recording and continuous reading. That is a limit of this transport and collection setup, not proof that Percepio cannot handle the application rate; a larger ring would absorb bursts but not a sustained byte-rate deficit. All three builds are therefore compared at 750 blocks/s, where the Trace health table above shows the retention each recorder actually achieved.

Every application run

Code and RAM cost

This is a RAM-loaded application: executable code and constants also occupy RAM. Delta is the selected recorder minus Recorder off. Fixed RTOS heap and stack reservations are allocations, not measured peak usage.

The Percepio total includes stock RTT terminal-channel storage and recorder tables; its control task consumes part of the already reserved RTOS heap. Comparing the 5,120-byte up-ring alone omits other recorder storage. Flash-resident builds would move code/read-only storage out of RAM, but this report does not predict their timing or memory layout.

Reproduce and interpret

All runs use the same STM32N6570-DK at 600 MHz, GCC -O2, no LTO, the same FreeRTOS/lwIP application source and two seconds of traffic warmup. The nine runs interleave the three builds (Recorder off / ViewAlyzer / Percepio, then ViewAlyzer / Percepio / Recorder off, then Percepio / Recorder off / ViewAlyzer), each starting from a fresh RAM load. Three repetitions expose some variation; they are not a broad statistical characterization.

The host is a general-purpose Windows PC, not an isolated latency-test host, so host round trip describes this setup and cannot attribute small differences to recorder code. Application timing is measured on the board, but request arrival patterns still depend on the host.

Percepio is the public TraceRecorder source with v4.11.0 headers. Compiler: arm-none-eabi-gcc.exe (GNU Tools for STM32 13.3.rel1.20240926-1715) 13.3.1 20240614. Host: Windows-11-10.0.26200-SP0, Python 3.12.10. Exact image, source and reader hashes and the effective configuration macros are in the machine-readable data.

The practical conclusion should follow the application's own CPU budget, response deadlines and trace requirements. This experiment measures overhead and retention under one documented configuration. It does not establish universal recorder rankings, maximum throughput or timing guarantees. Host p99 differences alone cannot identify a recorder-code cause.

Put it to work

See the behavior behind the numbers.

Explore ViewAlyzer’s timelines, communication analysis, and repeatable capture workflows.