JSI · Physical Security Engineering · Project EGA
Five days of uninterrupted running, three avoidable stumbles while changing it, a security exposure found and closed, and a working alternative to GV-Mobile Server for Watchtower that costs a fraction of its processor and bandwidth.
The gateway works, and it is now safer and better understood than a week ago.
It ran five days untouched — 37.6 million frames, none dropped. The problems in this period came from changing it, not from running it, and each one has been fixed and written into the tools so it cannot recur the same way.
Two findings matter beyond the gateway itself. The streaming server was reachable from the internet with no password and would have accepted anyone's video in place of ours; it is now closed, verified from outside. And the figures behind the earlier Watchtower page were wrong: GV-Mobile Server uses far more bandwidth than recorded there. The gateway can serve Watchtower instead, measured at a small fraction of the cost, and a test copy of the portal is running.
No restart, crash or reboot.
Across eight cameras.
Not one frame lost by the reader.
Every one of them the one camera that was offline; the eight healthy cameras never once.
The one camera off the network exposed a flaw in the supervisor added on 9 September: it limited the rate of restarts but never gave up, and restarted that camera 1,512 times. It now reports a camera unreachable for 30 minutes once and leaves it to its reader. Two further gaps were closed at the same time: successful alert deliveries are now recorded (only failures were), and every log line carries its date.
Reported plainly, because each one was ours and each one changed how the tools work.
| What happened | Effect | What changed |
|---|---|---|
| First deployment went to the wrong folder — one level above the code. | None. The live gateway was untouched; its own preflight check exposed it. | Deployment now refuses any folder that does not already contain the gateway's config and pipeline. |
| Restarting it left it down. Only the main process was stopped; the scheduled task was started a second later and failed. | No annotated video from 07:38 until 19:14 on 14 September — 11 hours 36 minutes. | A relaunch tool stops the whole gateway, waits for its ports to be free, and does not report success until the log and the API confirm it. |
| It then ran from a console window for two days instead of under its task. | Worked, but wrote no log, and closing the window would have stopped it with nothing to restart it. | Back under the task since 16 Sep 19:39. The status tool now tells a console launch from the task's. |
| A DNS configuration change on the machine stopped name resolution for the mail server. | 505 crossing alerts could not be sent (1,038 were). Alerts are not retried. | DNS corrected. Alert failures are now visible in the status and the log. |
| Six outdoor cameras dropped off the network together, 17 Sep 04:42–05:50. Not a change of ours; recorded here because it happened in the period. | 68 minutes without those cameras. The gateway sent CAMERA LOST to GV-VMS the whole time, and took them back by itself when they returned. | Nothing on the gateway to change: they did not answer the office network either. The other three cameras stayed up. Worth checking what those six share on site. |
| The security change rolled itself back the first time, because of a fault in the script, not the change. | About one extra minute without annotated video. | Fixed, and the relaunch path is now tested end to end, not only the edit. |
Before any further change, the working version was snapshotted on both machines — code, camera configuration, streaming server settings, task definition and mail settings — with checksums tying the two copies together.
The gateway's streaming server answered on the internet with no password, over five protocols, and its default settings let an anonymous client not only watch but publish — replacing the video GV-VMS records and forwards to the monitoring centre.
A one-minute sampler ran from 16 September 19:11 (11.5 hours, to 06:43 on 17 September), with the gateway on nine cameras and GV-VMS recording seven cameras on motion — switched on 15 September at 13:26.
| Hourly averages | Until midnight | After midnight |
|---|---|---|
| Whole machine | 45–52% | 66–70% |
| Whole machine, 95th percentile | 55–73% | 75–100% |
| GV-VMS | 13–16% | 25–27% |
| Gateway, nine cameras | 23–24% | 27–28% |
| Disk writes | 0.1–0.2 MB/s | 3.5–4.6 MB/s |
Over the whole run the machine averaged 61% with a 95th percentile of 87%; committed memory never passed 63%.
At midnight the load stepped up and stayed up. GV-VMS roughly doubled, disk writes rose about thirty-fold to a steady 3.6 MB/s, and the machine went from comfortable to near its limit — the 05:00 hour averaged 82% with its 95th percentile at 100%, while six cameras were offline and the test portal was being used. A constant write rate that starts on the hour looks like a recording schedule rather than motion, but that has not been checked. Until it is, the capacity of this machine should be read from the after-midnight figures, not the evening ones.
These are the first continuous measurements of the machine in its real configuration; earlier figures came from single instants that disagreed by thirteen points.
The Watchtower page of 9 September put GV-Mobile Server at 1.3 MB per minute per camera and concluded that video from the gateway would cost about seven times as much. Measured directly on 16 September, Mobile Server sends every camera at 640×480 and 15 frames a second: 1.0–2.1 Mbps per camera, 7–16 MB per minute, at night. It sends its empty channels too — a still GeoVision logo at 1.4 Mbps. That page has been corrected.
Loaded on a timetable and read off the sampler: one camera watched adds about 5 points of the whole machine; two add about 14. Mobile Server decodes and re-compresses each viewed camera, with its own copies of GeoVision's codec process.
The gateway decodes every camera all the time. Its live view takes that frame before any box is drawn, compresses it once however many people watch, and serves the same URL shape Mobile Server does. The frame rate follows the scene — 2 per second when nothing is happening, 10 when the camera reports movement — at Mobile Server's own JPEG quality, so clients see the picture they see today.
| Per camera being watched | GV-Mobile Server | Gateway live view |
|---|---|---|
| Frame rate | 15, always | 2 quiet · 10 on motion |
| Bandwidth, night, measured | 1.0–2.1 Mbps | 0.08–0.34 Mbps |
| All nine cameras at once, measured | — | 1.87 Mbps total |
| Processor, one camera watched | +4.7 points | no measurable change |
| Processor, two cameras watched | +14 points | +0.9 points |
| Processor, nine cameras watched | not tested | +3.6 points |
| Picture | boxes and a debug timestamp burned in | clean |
| Access | as today | token held by the portal's server |
All nine cameras through the gateway cost less processor, and less bandwidth, than one camera through Mobile Server. Daytime scenes compress less well and movement raises the frame rate, so daytime figures will be higher — but on the same footing, at the same quality, the gateway sends 2 or 10 frames where Mobile Server always sends 15.
ega-watchtower.jatagan.app is the current Watchtower page, unchanged in look, with its own login and its own server, fed by the gateway on this trailer. The client portal, its server and its accounts were not modified. Moving a real unit over would be a per-unit setting in the production portal plus one small change so its server carries the gateway's token — a decision for after the test portal has been used.
The goal is a table anyone can use to configure a trailer: for a given number of cameras, frame rate and resolution, with or without recording and live viewing, is this N150 safe — yes or no, and with how much margin.
Processor is the constraint, and it is not a fixed number: it moved from 45% to 70% at midnight last night with no change on our side. Any limit set without understanding that would be a guess.
A configuration passes only if all of these hold through its worst hour, not its average one:
| Measure | Limit (proposed) | Why |
|---|---|---|
| Processor, 10-minute average | ≤ 70% | Leaves room for what we cannot schedule: movement, a viewer, an unexplained step like midnight's. |
| Processor, 95th percentile | ≤ 85% | Short peaks are normal; living near 100% is not. |
| Processor at 100% | never > 30 s | A saturated machine delays every camera at once. |
| Gateway frames dropped | 0 | The gateway's own counters, per camera. |
| Encoder frames skipped | ≤ 1% | Measured at 0.6% in normal running. |
| Recorder | no gaps | Recorded files checked for continuity where recording is on. |
| Committed memory | ≤ 75% | Memory, not processor, stopped this machine in August. |
| Processor speed | not throttled | A hot trailer slows the chip; limits found in a cool hour would not hold in a hot one. |
| Variable | Levels |
|---|---|
| Cameras in the gateway | 3 · 6 · 9 |
| Frame rate | 5 · 8 · 11 · 15 fps |
| Resolution | D1 (704×480) · 720p |
| GV-VMS recording | off · on motion · continuous |
| Live viewing | none · Mobile Server 1, 2, 4 viewers · gateway live view 1, 4, 9 cameras |
| Scene | quiet night · busy day (movement drives tracking and the live view's frame rate) |
Every combination would be over a thousand runs. Instead, the plan measures what each piece costs on its own, builds the limits from those costs, and then proves the limits with a small number of long runs at the edge.
| Stage | What | Time |
|---|---|---|
| 0. Controls | Explain the midnight step and anything else scheduled on the machine (recording schedule, antivirus scans, updates). Measure the machine with nothing of ours running. Improve the sampler: 10-second samples, Mobile Server separated from GV-VMS, processor speed and temperature, the gateway's drop counters, and a label for which test is running. | 1 day |
| 1. Unit costs | One variable at a time, 15–20 minutes per step, each step bracketed by a rest period: gateway cost per camera by frame rate and resolution; recorder cost per channel by recording mode; cost per viewer for Mobile Server and for the gateway's live view; the same steps repeated in a busy daytime scene. Every process is measured separately, so one run yields several answers. | 2–3 days, ~30 steps |
| 2. Limits | Add the unit costs into a first safe-operating table, and pick the handful of combinations that sit right at the proposed limits. | ½ day |
| 3. Proof | Run each edge combination for 2 hours, including one daytime peak and one midnight. Then run the chosen standard configuration untouched for 48 hours. A limit that fails in either is lowered, not argued with. | 4–5 days |
A one-page operating table for the N150 — cameras against frame rate, for each recording and viewing mode, marked safe, marginal or unsafe — with the measured margin behind each cell, and the same method ready to repeat on any other trailer hardware.