JSI · Physical Security Engineering · Project EGA
Four hours of continuous measurement on the trailer gateway, running seven cameras through EGA and two through GeoVision at the same time. What the hardware can carry, what it cannot, and where the energy actually goes.
Nine cameras through EGA is comfortable. Nine cameras through the VMS is not possible on this hardware.
The gateway is the cheap half. Each D1 camera costs EGA about 0.21 of a processor core; the same camera costs the VMS about 0.36 — roughly seventy percent more. The limit on a trailer is not how many streams we can annotate, it is how many the video management system can record and watch.
Of the whole machine, for one D1 stream: decode, draw, encode, publish.
The same camera costs the VMS nearly twice what the gateway costs.
Today's 7 + 2 configuration, with peaks reaching 97%.
8.35 GB at the start, 8.29 at the end. Nothing leaks.
The trailer gateway ran its normal workload for four uninterrupted hours: seven cameras pulled, annotated and republished by EGA, and two of those same cameras recorded and monitored by GeoVision on the same machine. Samples every ten seconds, 191 of them.
| Measure | Mean | Median | 95th pct | Peak |
|---|---|---|---|---|
| Total CPU | 74.0% | 74.0% | 89.5% | 97.0% |
| EGA (7 cameras) | 45.7% | 45.6% | 48.7% | 60.1% |
| GeoVision (2 cameras) | 17.9% | 17.1% | 26.9% | 32.5% |
| Everything else | 10.4% | — | — | — |
| Clock speed | 1718 MHz | 1718 MHz | 1794 MHz | 1846 MHz |
| Memory in use | 8.2 GB | 8.2 GB | 8.3 GB | 8.9 GB |
Seven cameras stayed connected for the entire run. No stream dropped, no process restarted, and memory finished six hundredths of a gigabyte below where it started. The software is stable; the question is purely one of capacity.
We expected the gateway to be the expensive part. It is not.
This is worth stating plainly because it inverts the intuition. Annotating a stream — decoding it, drawing on it, re-encoding it, republishing it — turns out to be cheaper than what the video management system already does with the same stream today.
Every figure below adds the fixed 10.4% the operating system and its services consume regardless of our software.
| Configuration | Total load | Verdict |
|---|---|---|
| EGA 7 + VMS 2 (today) | 65% | Works, thin margin |
| EGA 9 + VMS 2 | 75% | Works, thin margin |
| EGA 12 + VMS 2 | 91% | Do not |
| EGA 9 + VMS 4 | 93% | Do not |
| EGA 6 + VMS 6 | 96% | Do not |
| EGA 9 + VMS 9 | 138% | Impossible |
The measured average of 74% is close enough to saturation that peaks already touch 97%. A system with no headroom has no room for a camera reconnecting, a Windows update, or a detection burst when three people cross at once.
Nine cameras through EGA, two through the VMS. That lands near 75% average, which is workable but should be treated as the ceiling rather than the target. Anything beyond it needs one of the changes in the next section.
On a solar and battery trailer the useful question is not whether the processor copes but what it draws. One measurement speaks directly to that.
The N150's base clock is 800 MHz. Across four hours it never once dropped below 1568 MHz, averaging 1718 — more than twice base, continuously. The processor spent the entire run in its boost range and never returned to a low-power state.
Power on this class of processor rises faster than clock speed, so a chip held at twice base frequency all day costs disproportionately more than the utilisation figure suggests. This matters more than the raw percentages: reducing load enough that the processor can step down to a lower state saves more energy than the utilisation drop alone would imply.
That reframes the target. The goal is not to fill the machine to 90% because it fits — it is to keep total load low enough that the processor is allowed to idle down between bursts.
Four honest limits on the numbers above.