Benchmark · 15-minute capture
Fifteen minutes of 4K60, ten of them under full load
We recorded 15 minutes of 3840×2160 HDMI at 60 fps on an NVIDIA Jetson Orin NX and counted every frame in the file. For 10 of those minutes, a separate program kept all six CPU cores at 100%, to see whether the capture holds up and whether the board stays cool. Outside the stress test, not one frame was lost.
$ ecurl rec lt300:/0/hdmi-in/0 -d framerate=60 -d duration=15mSecond by second
900 seconds, one frame counter
Each point is the number of frames the recording holds for that second. The shaded band is the 10-minute stress test, from 3:00 to 13:00, when a separate benchmark drove all six cores to 100%.
Frames captured per second
target 60CPU load
% of 6 coresBoard power
wattsJunction temperature
°CHover or drag across any chart to read every measurement at that second. With the keyboard, focus a chart and use the arrow keys (hold Shift to jump a minute).
In the 5 minutes without the stress load (the first 3 and the last 2), the recording kept all 18,000 frames, each one 16.7 ms after the last. The CPU stays at about 14% of capacity, leaving most of the board for your own application.
For 10 minutes with every core at 100%, the recording kept 35,984 of 36,000 frames, an average of 59.97 fps. Six of the ten minutes lost nothing at all. The 16 missing frames came in six short gaps, the longest 100 ms, and no second dropped below 55 fps.
Under full load the junction temperature rose from 54 °C, passed 60 °C after about two minutes, then held around 60 °C for the rest of the test, peaking at 60.9 °C. The CPU stayed at its top clock speed of 1.98 GHz the whole time, with no thermal throttling.
The stress test
What we threw at the CPU
To find the worst case, we ran a second program alongside the recording that keeps every CPU core fully busy. It stands in for a customer application that takes all the processing power the board has.
$ openssl speed -multi 6 -seconds 300 -bytes 16384 sha256 aes-256-cbc- What it is
- OpenSSL's built-in benchmark, a standard tool that ships with Linux. It measures how fast the processor can hash and encrypt data.
- What it does
- Six copies run at once, one per core. Each one hashes (SHA-256) for 5 minutes, then encrypts (AES-256) for 5 minutes, over and over on 16 KB blocks held in memory.
- When it ran
- From 3:00 to 13:00 of the 15-minute recording, 10 minutes without a break. The capture was already running and was not restarted or touched.
- Why this test
- It is pure processor work with a fixed, repeatable load, and it reports a throughput figure. That figure also shows how much CPU is left for your application while the LT300 records.
This is a deliberate worst case. Most real applications do not keep all six cores at 100% without pause. The test loads the CPU only. GPU, disk and memory bandwidth were not stressed.
Headroom
How much CPU is left for your application
We ran the same 10-minute, 6-thread benchmark (
openssl speed
, 16 KB blocks) twice: once on an idle board, and once while the LT300 was recording 4K60. The CPU kept about 89% of its throughput with a 4K60 recording running.
Storage
What the recording writes to disk
The LT300 hands the Jetson a compressed H.264 stream, so a 4K60 recording needs only a few megabytes per second of storage. We measured the recorded file second by second, then measured how fast the Jetson's NVMe drive can write.
Over the 15 minutes the file averaged 32.5 Mbit/s (4.1 MB/s). The busiest single second reached 42.3 Mbit/s (5.3 MB/s). Keyframes averaged 158 KB, the largest 335 KB; the frames between them averaged 67 KB.
At this rate a 4K60 recording takes about 14.6 GB per hour, or roughly 68 hours of continuous recording per terabyte of storage.
The 1 TB NVMe drive in our Jetson wrote 1.7 GB/s with direct I/O and 888 MB/s through the normal file cache, over 150 times what the recording needs. The test wrote 8 GB, short enough to fit in the drive's fast write cache; much longer writes run slower, still far above the recording rate.
Method
How we measured
Frame counts come from the presentation timestamps of every video packet in the recorded file, not from the recorder's own counters. System figures come from
tegrastats
, sampled once per second. It skipped 9 of the 900 seconds, which are filled from the neighbouring samples.
| Host | NVIDIA Jetson Orin NX (Engineering Reference Developer Kit Super), 6 × Arm cores, 8 GB |
|---|---|
| Software | Jetson Linux R39.2.1, kernel 6.8 (tegra), LT300 agent and kernel driver (build of 12 November 2026) +
ecurl
1.0.0 |
| Source | HDMI input 0, 3840 × 2160, 60 fps |
| Command |
ecurl rec lt300:/0/hdmi-in/0 -d framerate=60 -d duration=15m
|
| Output file | H.264 High, 4:2:0, 3840 × 2160, 900.0 s, 3.7 GB, 32.5 Mbit/s |
| Frames | 53,984 of 54,000 (99.97%) over the full run. All 16 missing frames fall inside the 10-minute stress window. The last frame is stamped 1 ms after the 15:00 mark, so the chart's final second shows 59. |
| Storage | Crucial P310 1 TB NVMe. Write speed:
dd
of 8 GB with
oflag=direct
(1.7 GB/s), and buffered with
conv=fsync
(888 MB/s), measured on 13 November 2026. Recording rate from the size of every video packet in the file. |
| Stress load |
openssl speed -multi 6 -seconds 300 -bytes 16384 sha256 aes-256-cbc
, from 3:00 to 13:00 of the recording |
| Baseline | Same command on the idle board before the recording, then 2 minutes to cool down |
| Date | 12 November 2026 |
Per-second data (900 rows)
Enciris LT300 · Measured on 12 November 2026. Results apply to the configuration listed above.
Building an edge recording product?
Let's size your system together
Number of inputs, resolution, codec and Jetson module: our engineers help you choose the right board and host.