Updated:
Update: Solved
After receiving some useful input from the developer of VARA (José) a number of tweaks have been made to try and get the RPI4-to-RPI4 multi mode working, the news is pretty good in that we have got them to actually link and transfer data.
In short, tweaks:
- Adding realtime process limits to
/etc/security/limits.conf - Changing the thread priority of the
VARA.EXEbinary running under Wine/Box86 to maximum - Utilizing the “P2P SESSION” VARA command.
Initial Report: Latency with VARAHF on RPI4 and VMs
We have been doing some experiments not for the want but for the need to cut power usage and so far things have gone well, especially concerning the popular Winelink project that initially got VARA working on the Raspberry Pi4.
Unfortunately, there are some drawbacks to this setup when it comes to link establishment between hosts that introduce latency from both sides.
Below is a table where VARA HF connection “TXDelay” lag threshold is exceeded in situations, tested on real world HF links over 1000km
| Host A | Host B | VARAHF Status | Participants |
|---|---|---|---|
| RPI4 | Native Windows | ABLE | PE1RRR<>UT1HZM PE1RRR<>IR2UFV |
| VM Win10/11 | Native Windows | ABLE | EI2GYB<>UT1HZM EI2GYB<>IR2UFV |
| RPI4 | VM Win10 | PE1RRR<>EI2GYB | |
| RPI4 | RPI4 | ABLE** | PE1RRR<>PE1RRR |
- RPI4 = Raspberry Pi4 clocked at 2GHz, 4GB with Box86 & Wine
- Native Windows = Normal Windows 10 installation on native x86 CPU.
- VM Win10 = Virtualized Windows 10 on an otherwise idle i7 CPU, Proxmox Debian host.
Each step away from the native environment introduces a subtle amount of latency that if only affecting one host is still within linkable parameters, however when latency is introduced from both sides, the link establishment fails persistently.
The effects of only a few additional (tens of) milliseconds is enough for both hosts to timeout even though both hosts are responding to the VARA link signals.
| Host A | Host B | ARDOP Status | Participants |
|---|---|---|---|
| RPI4 | Native Windows | ABLE | PE1RRR<>EI2GYB |
| RPI4 | VM Win10 | ABLE | PE1RRR<>EI2GYB |
| RPI4 | RPI4 | ABLE | PE1RRR<>PE1RRR |
| VM Win11 | VM Win10 | UNLIKELY | Theory<>Theory |
In comparison, as ARDOP runs natively on Linux and Windows, latency is still introduced from one half of the link in our experiment on the VM.
For instance- I cannot connect to EI2GYB via VARA since his move from native Windows to a VM. In this situation, we were still able to link via ARDOP as that is native on all platforms, but is still running inside a VM on EI2GYB’s system.
Update 1 – Further Testing & Some Tweaks
Enable Realtime Thread Priority
Tweaks to the host operating system file /etc/security/limits.conf
@audio - rtprio 95 @audio - memlock 512000 @audio - nice -19
The rtpriosetting is the maximum priority a user of the audio group can run a task. The memlock setting is the maximum amount of memory that a member of the audio group can lock with a realtime task. This should be less than the maximum physical amount of memory, some recommend it to be half. nice is the minimum “nice level” a task can be run as (the willingness of a task to give up it’s cpu time).
ALSA Project (https://www.alsa-project.org/wiki/Low_latency_howto)
After a reboot, verify that the new limits are working with:
ulimit -r pi@superbox:~/bin $ ulimit -r 95
Thread Priority
sudo chrt -p 99 <pid of VARA.exe>
File: /home/pi/bin/startvara
#!/bin/bash cd /home/pi/bin DISPLAY=:2 export DISPLAY echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor (sleep 20; sudo chrt --pid 99 `pgrep VARA.exe` ) & /usr/local/bin/wine /home/pi/.wine/drive_c/VARA/VARA.exe
File: /home/pi/bin/startardop
!/bin/bash
cd /home/pi/bin/
(sleep 10; sudo chrt --pid 99 `pgrep piardopc` ) &
/home/pi/bin/piardopc 8515 ARDOP2IN ARDOP2OUT
P2P SESSION
at 3 RIJEN:PE1RRR-7} Ok P2P SESSION VARA} OK C PE1RRR-10
Test result for VARA RPI-to-RPI so far:
When the chrt tweak is applied to the ardopc process, converting it from default ‘20’ priority to realtime, link establishment success rate observed so far appear to improve.
If you find the articles, or content in general posted here useful, enjoyable or maybe even something else, please consider making a small contribution towards my hosting fund so that I may continue to provide my services for free to as many people as possible.
Eindhoven.space 
One thought on “VARA HF & Latency Issues With RPI4 Gateways”
Comments are closed.