VARA HF & Latency Issues With RPI4 Gateways


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.EXE binary running under Wine/Box86 to maximum
  • Utilizing the “P2P SESSION” VARA command.

See Update 1 for the full details.

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 AHost BVARAHF StatusParticipants
VM Win10/11Native WindowsABLEEI2GYB<>UT1HZM
VARA Experiment Results

**See Update 1

  • 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 AHost BARDOP StatusParticipants
VM Win11VM Win10UNLIKELYTheory<>Theory
ARDOP Experiment Results

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 (

Ensure that the user running VARA.EXE is in the audio group in /etc/groups

After a reboot, verify that the new limits are working with:

ulimit -r

pi@superbox:~/bin $ ulimit -r

Thread Priority

Launch VARA with highest priority (99)- When done as root, chrt overrides the policy set earlier in the limits.conf, running the process as rt (realtime) which will be indicated when displayed in the top process monitor.


sudo chrt -p 99 <pid of VARA.exe>

Where <pid of VARA.exe> is the process ID.

A script that will fork chrt into a background subshell, wait 20 seconds while VARA is launched, then adjusts the process priority of VARA.exe is required.

The following script tweak is needed for the RPI4 TNC image for both the ARDOP and VARA TNCs:

File: /home/pi/bin/startvara

cd /home/pi/bin
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

cd /home/pi/bin/
(sleep 10; sudo chrt --pid 99 `pgrep piardopc` ) &
/home/pi/bin/piardopc 8515 ARDOP2IN ARDOP2OUT


This is a parameter for VARA that is for Flex software defined radios that have ~400ms latency, this may really does improve the link establishment- This was a crucial step for getting RPI-to-RPI linking to work while using dsnoop/dmix audio streams running simultaneous native+Wine/box86 TNCs.

P2P SESSION can be set in an a BBS connect script when used for inter-BBS forwarding. A manual example via the node:

at 3

Test result for VARA RPI-to-RPI so far:

Host AHost BVARAHF StatusParticipants
VM Win11Native WindowsABLEEI2GYB<>UT1HZM
VARA Experiment Results

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.

Host AHost BARDOP StatusParticipants
VM Win10VM Win11NO TESTTheory<>Theory
ARDOP Experiment Results


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.

One thought on “VARA HF & Latency Issues With RPI4 Gateways

Comments are closed.