VPN degradation on 2.3.7 When I run 2.3.7 remotely on a VPN I get at best two yellow bars. I down graded back to 2.2.8, I get 5 green bars. It appears the newer version might be hogging more bandwidth than the previous version.
If you are running a VPN, then there is a possibility that the packets exceed your network path MTU once the encapsulation (wrapper) is done on the VITA-49 data. I would look at your VPN endpoints and see what their performance metric tell you between using 2.2.8 (the old method) and 2.3.7 the new one.
The Network Health indicator shows VITA-49 packets the client expects to receive from the radio and if one is missing, it shows it as a drop, but as Michael indicates, that is not necessarily a bad thing operationally if you are not hearing gaps on the audio or seeing display frames not refreshing (blank display).
Thank you, Tim.
Strangely, when I get one red I am getting a latency of 34 ms on the VPN. This is about what I was getting before when I had 4 to five green bars on the previous version. When I switch to Smarlink I get an indication or three yellow bars but my latency reads 116 ms. There doesn't seem to be a correspondence to the number of bars showing and the latency.
start whit Triangle on display , then got panadapter but run in red whit > 25% packet loss
this time i do a cold reboot before and after update and not better
VPN is SoftEther runing on Small Atom Win10 PC on remote site
I would like have this fixed.
Any way, I can use my radio on digital modes via VPN on the remote PC with this hybrid setup:
-First I start SmartSDR without VPN, using SmartLink.
-When SSDR is running. I open VPN tunnel to the radio. Immediately DAX and other clients connect to the radio normally. SSDR keeps running via SmartLink!
No need to downgrade, I think.
73, Timo OH5KW
I do not notice any difference in the actual performance of SmartSDR however, so I assumed that perhaps the bars were "re-normed" so that only a direct LAN connection or similar would earn a green "very good" status.
I am seeing 0.26% packet loss at present over my SoftEther VPN with 25ms RTT average and worst case 165ms.
Two quick product suggestions that I think are relevant to this issue which would be very helpful:
Suggestion 1: Improved network latency "histogram": Instead of just showing real time latency and Max Latency, show the max latency for several different rolling time windows. I suggest real time, 1 minute, 5 minute, and 30 minute. If it shows 120ms as the max latency in the 30 minute window but say 40ms in the 1 and 5 minute windows, that is not cause for concern, but if it routinely shows 120ms max in the 1 minute window that indicates a much more unstable network.
Suggestion 2: Create a "latency health check" view that measures all aspects of the system latency including DSP filter skirt settings, PC audio hardware, network latency, VPN latency, etc., that are relevant to SmartSDR performing optimally. This would help those setting up remote stations to figure out where to focus attention. This could even be a command line script that prints information to the console. I suggest this since I suspect Flex has already created tooling to measure many of these one way or another. In digging into this in my own station, it seems that consumer grade internet is the major culprit, but given the amount of time I've invested so far (not much) it has been difficult to get tot the bottom of which components of the internet link need attention.
One question about packet fragmentation that I've been wondering about in reading this: Is the approach to packet fragmentation adopted by IPV6 impactful for this kind of issue? Is SmartSDR likely to perform better or worse (all else being equal) on a mediocre connection over IPV4 or IPV6? Why?
One other question since others in this thread use SoftEther: Is anfyone using traffic shaping on their VPN interface? I recently set up SQM on the tap_soft interface (bridged to the LAN interface at the remote site) and now the buffer bloat results are much improved, but I can't tell if the setting ought to improve SmartSDR performance.