IP camera snapshot update period: why polling looks sluggish

A camera tile fed by a snapshot URL feels slow for a reason you can compute: every redraw costs one full HTTP round trip, and the update period only adds to it. A half-second update period against a 0.45 s fetch settles at roughly one frame per second, however patient you are. Below is the arithmetic behind that, three ways to measure your own fetch time, the period to set for a target cadence, and the point where polling is the wrong tool and a stream is the answer. The numbers fit an HMI tile, a wall dashboard or a SCADA view fed by an IP camera's snapshot URL.

The update period is a gap between fetches, not a frame rate

An update period of 0.5 s does not mean 2 frames per second. It means the gadget starts a new fetch every 0.5 s, and the screen only changes when a JPEG arrives complete. Between request and redraw sit the camera's capture and encode, its HTTP server, the network path and the viewer's decode and draw, and every cycle pays all of it again.

All times are in seconds. Most HMI snapshot gadgets behave the first way: the next request leaves only after the last image lands. Both the still-image-on-a-timer pattern and its HTTP snapshot URL form work like this in their plainest shape, which is why the arithmetic below uses the first rule. With a half-second period and a 0.45 s fetch, either rule lands between 0.5 and 0.95 s per frame.

Where the seconds go: a fetch-time budget

Added up, a wired fetch lands at about 150-500 ms, which is what slow tiles show in practice. The 350 KB is an example weight for a 1080p-class JPEG at usable quality; yours may weigh half or twice that. The copper is not the culprit: signals move through a data cable at about 200,000 km/s, so a 15 m camera data cable run adds 75 ns, a rounding error beside a 200 ms encode. A long exposure stretches the capture stage instead, which is why cutting a camera's snapshot time starts with exposure and light, not with the network.

Measure the fetch before you touch the period

Open the snapshot URL in a browser tab on a PC wired to the same switch as the camera, and refresh twice a second by hand. If each image takes half a second to appear, no gadget setting will beat that; the tab is your lower bound. Do this first, before changing anything in the HMI.

For a number that goes into the formula, fetch the URL ten times in a row and divide the total by ten. curl prints the request-to-last-byte time per fetch with its time_total figure:

for i in 1 2 3 4 5 6 7 8 9 10
do curl -s -o /dev/null -w %{time_total}\n http://192.168.1.10/snapshot.jpg
done

Say the ten runs total 4.6 s: T_fetch = 0.46 s. Run it from the HMI's own host when you can, because the panel's path is the one that sets the cadence; the same test from a laptop on Wi-Fi tells you a different story.

To measure the finished tile rather than its parts, point the camera at a running stopwatch and count distinct frames across 10 s of the HMI screen. Frames counted divided by ten is the effective rate you actually have, gadget, network and camera included.

Worked example: a half-second period against a 0.46 s fetch

Take the measured T_fetch = 0.46 s and the half-second update period, in a gadget that waits for each fetch:

• T_eff = 0.5 s + 0.46 s = 0.96 s per frame, about 1.0 fps.
• Bandwidth per tile: 350 KB × 8 bit/byte = 2,800 kbit per frame, × 1.04 fps ≈ 2.9 Mbit/s.

Eight such tiles move about 23 Mbit/s, under a quarter of a wired 100 Mbit/s link. Bandwidth is not what makes the page feel slow; the serialized round trips are.

Set the period to 0 and the tile runs at its hard ceiling: T_eff = 0.46 s, about 2.2 fps, with requests stacking whenever a frame runs long. Cameras that cap concurrent HTTP sessions start stalling or dropping tiles there, which surfaces later as a snapshot that stops loading altogether. Keeping the period above twice the fetch holds that failure mode closed.

On Wi-Fi the same settings decay: a 10-100 ms round trip plus retransmissions turns the same fetch into 0.8-1.2 s, and the tile crawls at one frame per 1.3-1.7 s although the desktop test looked fine. When the tile feeds a remote dashboard, measure from the dashboard's host, because that path is what sets the cadence.

The settings that actually fix it

1. Pick the target cadence first. A tank level or a door state reads fine at one frame per 2-5 s; a person or a moving part does not read at any polling rate.
2. Set the period to target minus fetch. For a 2 s tile with a 0.46 s fetch: T_period = 2 - 0.46 ≈ 1.5 s, which lands at a 1.96 s real cadence.
3. Keep the period at or above twice the measured fetch, so 0.46 s sets a 1 s floor and one slow frame cannot overlap the next request.
4. Shrink the JPEG before shrinking the period. Image files scale with pixel count: 640×480 holds 6.7× fewer pixels than 1920×1080, so a 350 KB frame drops to about 52 KB and its transfer falls from 28 ms to 4 ms, with the encode shrinking too.
5. Read the camera's own snapshot interval or rate setting before tuning anything else; if the camera only produces one frame per second, no period value beats it.

When polling is the wrong tool

Polling tops out at 1/T_fetch, so a fetch of 0.3-0.5 seconds caps a tile near 2-3 fps, and motion needs an order of magnitude more. A stream holds one connection open and sends frames down it continuously. An MJPEG feed at VGA size and 20 fps costs about 40 KB × 20 = 800 KB/s ≈ 6 Mbit/s, and 1080p MJPEG at 15 fps is roughly 42 Mbit/s; both sit comfortably on a wired 100 Mbit/s link, and typical LAN streams run 10-30 fps at these sizes against 1-3 fps for the best-behaved snapshot tile.

If the HMI offers a video or stream gadget, use it. Displaying an RTSP camera stream in an HMI covers the URL forms, and an MJPEG viewer that shows no video covers the case where the stream URL points at a snapshot endpoint. The decision in one line: a static scene at 1 fps or slower stays on snapshots with the computed period; anything that moves goes to a stream the same day, and you stop tuning the period.

Five checks when the tile still crawls

1. Camera-side cap: the snapshot interval or event-rate setting in the camera's own pages sets the ceiling; a 5 s camera-side interval wins over any gadget value.
2. Wrong path measured: you timed from a wired laptop while the tile rides Wi-Fi or a server VLAN; measure from the tile's host.
3. Stacked requests: the period sits below twice the fetch and the camera is shedding connections; frozen tiles rather than laggy ones point here.
4. Oversized JPEG: the tile pulls the recording profile at full size; set a tile-sized snapshot and re-measure.
5. Double polling: a page auto-reload and the gadget both fetching the same URL; leave one driver and let the other sleep.

The decision, and the next move

Commit to this: measure T_fetch once per camera and path, set the period to target minus fetch with a floor of twice the fetch, and expect 1-2.5 fps from a well-tuned snapshot tile. If the scene moves faster than that, move the tile to an MJPEG or RTSP stream; no period value recovers motion from polling, and chasing one costs an afternoon for nothing.

If the camera at the station is a machine-vision smart camera rather than a surveillance camera, it publishes live video and results through its own tools: the guide on streaming smart camera live video and metrics to a dashboard walks that path, and the smart cameras finder lists devices that inspect on the device. If a tile still will not settle, ask us with the measured fetch, the JPEG size and the path, and we will size it with you. More snapshot and stream fixes sit on the systems topic page.