You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per-channel ring depth was hard-coded to 256 events, sized for the
SR-anchor consumer in #155 which reads cached state every ~5 s and
tolerates stale entries. For consumers that want every frame's
(pts_us, wall_ns) — frame-by-frame latency histograms, evidence
chains, multi-sensor sync correlators — 256 is too small when the
reader's dispatch latency is bursty.
Empirically on cv500 / hi3516av300_lite (#200 Obs 3): under
RTSP+RTCP load through libevent, ~52 dropped/s accumulate over
30 s sessions with the consumer draining in batches of 8 per
on_readable until EAGAIN. The consumer is not under-draining;
libevent just isn't dispatched often enough between the network
event ticks, and a 256-slot ring fills in the gap.
Convert OPENIPC_FT_DEPTH from a compile-time #define to a
ring_depth module_param (default 256, range 16..65536, rounded
up to next power-of-2 at init for the head/tail wrap mask).
Per-channel rings now kmalloc'd in __init; freed in __exit.
Operators wanting per-frame consumers under load can:
insmod open_openipc_frame_ts.ko ring_depth=4096
(16× default, ~8 s buffer at 240 fps × 2 types; 128 KiB/chn ×
8 chn = 1 MiB worst case). Default 256 keeps the memory footprint
identical for existing builds.
The fix is non-disruptive: at default params the binary behaviour
is identical to before (same depth, same wrap math, same drop
semantics). Only the storage moved from BSS to heap.
xref: #155 (chrdev introduction), #199 (cv500 / V4 / V4A MIPI_FS
push moved to ISP_INT_FE_FSTART — non-disruptive event source
that yields the high push rate driving the drops on cv500).
Co-authored-by: Vasiliy Yakovlev <vixand@openipc.org>
0 commit comments