This is a strange one. I run pipelines on a Quest 3 VR headset and I’ve noticed that every hour on the dot I experience lag that lasts around 8 seconds. During that time framing is very inconsistent, it’s like in between frames are being dropped randomly and latency flies out of control until it finally catches up and continues normally only to occur exactly an hour later.
I feel as if the cause is something I can’t control. Something like deeply routed router settings my router UI doesn’t expose or it’s something like hourly telemetry hogging the wifi causing these bursts which I can’t disable. I’ve noticed that during these bursts my ping 192.168.0.16 jumps from normally 2-5ms to 200-500ms peaks.
I don’t think the pipeline is the issue but this is the pipeline running on the headset. I’ve tried many variations of this and none of them have succeeded at reducing this hourly lag.
udpsrc port=%d buffer-size=4194304 caps=“application/x-rtp,media=video,encoding-name=H265,clock-rate=90000,payload=96” ! rtpjitterbuffer latency=30 do-lost=false ! rtph265depay ! h265parse disable-passthrough=true ! queue leaky=downstream max-size-buffers=20 max-size-bytes=0 max-size-time=0 ! amcviddec-c2qtihevcdecoderlowlatency name=decoder discard-corrupted-frames=false automatic-request-sync-points=false ! video/x-raw(memory:GLMemory) ! glimagesink sync=false name=unity enable-last-sample=false qos=false rotate-method=horizontal-flip
Does anyone have any good debugging tips for what I can do pipeline wise? I can calculate when the lag is happening based on increased latency but I’m not sure there’s anything I can do with that pipeline wise that won’t cause a noticeable gap in playback.
As an example here’s what I see happening every hour
2026-07-07 17:18:57 64 bytes from 192.168.0.16: icmp_seq=752 ttl=64 time=3.93 ms
2026-07-07 17:18:57 64 bytes from 192.168.0.16: icmp_seq=753 ttl=64 time=7.90 ms
2026-07-07 17:18:57 64 bytes from 192.168.0.16: icmp_seq=754 ttl=64 time=2.67 ms
2026-07-07 17:18:58 64 bytes from 192.168.0.16: icmp_seq=755 ttl=64 time=2.71 ms
2026-07-07 17:18:58 64 bytes from 192.168.0.16: icmp_seq=756 ttl=64 time=2.85 ms
2026-07-07 17:18:58 64 bytes from 192.168.0.16: icmp_seq=757 ttl=64 time=3.70 ms
2026-07-07 17:18:58 64 bytes from 192.168.0.16: icmp_seq=758 ttl=64 time=2.82 ms
2026-07-07 17:18:58 64 bytes from 192.168.0.16: icmp_seq=759 ttl=64 time=33.3 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=760 ttl=64 time=592 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=761 ttl=64 time=491 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=762 ttl=64 time=389 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=763 ttl=64 time=313 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=764 ttl=64 time=208 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=765 ttl=64 time=149 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=766 ttl=64 time=48.0 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=767 ttl=64 time=9.35 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=768 ttl=64 time=251 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=769 ttl=64 time=145 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=770 ttl=64 time=40.1 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=771 ttl=64 time=2.59 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=772 ttl=64 time=89.0 ms
2026-07-07 17:18:59 64 bytes from 192.168.0.16: icmp_seq=773 ttl=64 time=4.71 ms
2026-07-07 17:19:00 64 bytes from 192.168.0.16: icmp_seq=774 ttl=64 time=147 ms
2026-07-07 17:19:00 64 bytes from 192.168.0.16: icmp_seq=775 ttl=64 time=48.6 ms
2026-07-07 17:19:00 64 bytes from 192.168.0.16: icmp_seq=776 ttl=64 time=2.22 ms
2026-07-07 17:19:00 64 bytes from 192.168.0.16: icmp_seq=777 ttl=64 time=217 ms
2026-07-07 17:19:00 64 bytes from 192.168.0.16: icmp_seq=778 ttl=64 time=115 ms
This also coincides with a wifitelemetry process on the Quest 3 starting
07-07 17:18:58.133 0 0 I init : starting service ‘wifitelemetry’…