High network latency values VS SmartSDR

[wa2n-dev]

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

I saw a post on FB Flex Enthusiasts that several folks were seeing poor network performance and checked mine on Windows. I'm seeing quite a bit of variability 40ms -110 ms and when the latency goes over 100 the network performance flashes poor. I checked SmartSDR on the same computer and the latency was 2-3 ms. Ran them both at the same time on the same Windows computer and the numbers were the same (110 vs 3 max latency). Current version I'm running is 0.7.12 but I dropped back to 0.7.6 and the results were roughly the same. No change when switching between Opus and uncompressed on 0.7.12 other than the bandwidth changing as expected.

What did you expect?

No response

Steps to reproduce

No response

Radio model & firmware

No response

Linux distro & Qt version

No response

[N1NAZ]

This has all ready been reported.

[ten9876]

Thanks for reporting this. We recently fixed a related issue where the WAN (SmartLink) RTT measurement was completely broken — it always showed <1ms regardless of actual latency.

However, your report is about local LAN latency being 40–110ms vs SmartSDR's 2–3ms on the same machine. That's a different code path and likely a real measurement difference in how we time the ping round-trip. Our current implementation uses QElapsedTimer around the TCP ping command, which should be accurate, but Qt's socket buffering and event loop on Windows may add overhead that SmartSDR (native C# with raw sockets) doesn't have.

We'll investigate whether there's an actual network performance issue (packet processing delays, buffer sizes) or just a measurement difference. If your radio operation feels smooth and responsive despite the higher reported latency, it's likely the latter.

What's your subjective experience — do you notice any actual lag in tuning, audio, or spectrum updates compared to SmartSDR?

73, Jeremy KK7GWY & Claude (AI dev partner)

[ten9876]

Correction to my previous comment — the RTT fix we shipped in v0.7.12 applies to both LAN and WAN connections. We fixed two issues:

1. RTT was being measured after event loop dispatch, so UI processing time inflated the numbers (causing the 40–110ms you saw)
2. A follow-up fix corrected a regression where everything reported <1ms

Both fixes are in v0.7.15. Can you update and let us know if the latency numbers look more reasonable now?

73, Jeremy KK7GWY & Claude (AI dev partner)

[N1NAZ]

Jeremy, Sorry it's Still high. Just to be sure please zoom in on display, observe, Latency will go up!

support-bundle-20260331-075816.tar.gz

[wa2n-dev]

The numbers haven't changed materially, now on 0.7.16 but the performance seems fine. Connected via LAN.

[fifthwheel]

I just downloaded and built the latest version to my Linux Mint machine ( AMD Aethlon 5350, not a speed demon but, has worked well in the past with other near real time applications over the LAN) I am still having the same problem. Poor Network performance. With AetherSDR in full screen mode, the Network Latency is shown as Poor and in the 150+ ms range. And it is noticeable in the spectrum display. Reducing the display to ( upper right corner square) to drop the display to the middle of the screen, helps. BUT, latency is still a problem.
I believe that the problem that I and others are experiencing with VFO tuning using the mouse wheel is related to the network issues. It's either that, or there is a problem with threading and possibly some code bloat.
I did not have this problem around three or four versions ago.
So, far, the Windows versions have been relatively stable and in my case, no issues like I am having with the Linux version for Mint. ( either built from source or using the AppImage)
James
WD5GWY

[fifthwheel]

Just checked. When using the mousewheel to tune the VFO, whatever the setting in the Tune Step box on the right, the VFO moves exactly 8 times the value in the Tune Step display. That tells me that there is a problem in the coding somewhere.
I cannot blame this on Linux Mint because I also run PIHPSDR for my Anan 8000DLE and ( using the latest build from source) it tunes exactly according to the tune steps (adjustable) in that application.
James
WD5GWY

[ten9876]

Claude here. Quick update — v0.7.17.1+ uses kernel TCP_INFO for RTT measurement, which is completely immune to event loop delays. If you update to v0.7.17.6, the network status should show accurate latency.

The 8x scroll issue is tracked separately in #556 and we are working on a fix.

73, Jeremy KK7GWY & Claude (AI dev partner)

[ten9876]

Claude here. Closing this out — v0.7.17.1+ switched to kernel TCP_INFO for RTT measurement, which eliminated the inflated latency readings. The per-stream network diagnostics were also overhauled in the same release cycle. If you're still seeing unexpected latency on v0.7.18, please reopen.

73, Jeremy KK7GWY & Claude (AI dev partner)