Tappas GstShark negative CPU values

General
,
1

Hi everyone,

I have recently been running the Tappas GStreamer pipeline, and I wanted to add debugging. To do this, I used GstShark, but I noticed that I get weird values for the CPU usage in my graph.

image
image1823×950 78.8 KB

I also noticed that the Tappas GstShark debugging materials example exhibits the same behavior (tappas/docs/write_your_own_application/debugging.rst at master · hailo-ai/tappas · GitHub).

My pipeline:

gst-launch-1.0 pylonsrc cam::ExposureAuto=Continuous cam::GainAuto=Continuous cam::AutoExposureTimeUpperLimit=100000 name=cam ! \
    video/x-raw,width=1920,height=1080,framerate=30/1,format=RGB,pixel-aspect-ratio=1/1 ! \
    videoscale name=scaler ! \
    video/x-raw,width=640,height=640,pixel-aspect-ratio=1/1 ! \
    videoconvert name=converter ! \
    hailoexportzmq name=zmq_exporter ! \
    queue name=buffer_queue leaky=downstream max-size-buffers=30 max-size-bytes=0 max-size-time=0 ! \
    ximagesink name=display

Has anyone encountered a similar issue?

Best regards,

2

Hey @Remigiusz_Pomorski ,

What you’re experiencing is a known interaction between our cpuusage and threadmonitor tracers when they’re both enabled simultaneously.

Our default TAPPAS debug configuration (via gst_set_debug in the debugging docs) activates all available tracers:

export GST_TRACERS="cpuusage;proctime;interlatency;scheduletime;bitrate;framerate;queuelevel;threadmonitor;…"

The issue is that our plotting logic treats any tracer emitting load=… fields as CPU usage data. The threadmonitor tracer reports raw CPU-time deltas in microseconds, not percentages, but these get plotted on the same “CPU Usage” axes as the actual percentage values from cpuusage. Those massive spikes and negative values you’re seeing are just thread CPU-time readings being misinterpreted as percentage data.

This was actually reported upstream in the gst-shark tracker (Issue #99) - Ubuntu users were seeing similar negative “CPU usage” values due to delta calculation quirks in the raw timing data.

Here’s how to fix it:

Option 1: Use only cpuusage tracer

export GST_DEBUG="GST_TRACER:7"
export GST_TRACERS="cpuusage"
export GST_DEBUG_FILE=/tmp/gst-shark.log
gst-launch-1.0 … your-pipeline …

This gives you clean 0-100% curves per core without the artifacts.

Option 2: Filter the plot output
If you need threadmonitor data, you can either configure it to emit percentages instead of raw times:

GST_TRACERS="threadmonitor(period=1,filter=your_queue_name)"

Or just filter the plotting to cpuusage only:

gst-shark-plot -t cpuusage -p /tmp/profile

Going with Option 1 is usually the quickest fix for getting clean CPU usage plots.

Hope this helps!

1 Like