From b08809027e1b936aed68a7d2395794a606fa63d0 Mon Sep 17 00:00:00 2001 From: jrd Date: Tue, 23 Jun 2026 17:42:44 +0000 Subject: [PATCH 1/4] Improve home server connection guidance Replace specific bandwidth numbers with clearer practical advice: discourages wireless connections and notes fiber works well. Co-Authored-By: Claude Sonnet 4.6 --- wiki/en/Running-a-Server.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wiki/en/Running-a-Server.md b/wiki/en/Running-a-Server.md index a10b94dde..ebfd71d04 100644 --- a/wiki/en/Running-a-Server.md +++ b/wiki/en/Running-a-Server.md @@ -33,7 +33,7 @@ Using a public Server might introduce you to strangers. If you want an undisturb Usually, problems are on the _Client_ side and should be fixed there. Have a look at the [Troubleshooting page](/wiki/Client-Troubleshooting) if needed. -However, various problems can also arise when setting up Servers - especially when run on a low-bandwidth home connection. It's usually fine to have less than 5 players on a slower-speed home connection (eg 10 Mbit/s down and 1 Mbit/s up). You can read more about network requirements at [different quality settings here](Server-Bandwidth). +However, various problems can also arise when setting up Servers - especially when run on a low-bandwidth home connection. It can work to have less than 5 players on a slower-speed home connection. A wireless internet connection is discouraged for a server in your home, while a fiber connection should work well. You can read more about network requirements at [different quality settings here](Server-Bandwidth). Consider using a cloud host, not your home internet connection, to get better ping times if you're having problems. From 4fbc66e25727de2455912bf4d9fcc7c62c143086 Mon Sep 17 00:00:00 2001 From: jrd Date: Wed, 24 Jun 2026 23:27:36 +0000 Subject: [PATCH 2/4] Document Linux UDP receive buffer tuning for server operators The Linux default UDP receive buffer (~208 KB) is too small for a Jamulus server under load. The kernel silently drops packets when the buffer fills, causing complete audio interruptions that are indistinguishable from network problems. Measured on production servers: 9,103 drops in 6 days on one host, 14,035 drops in 5 days on another. Increasing to 4 MB resolved the issue. Adds a new section to Running-a-Server.md with the three-command fix and a drop-counter verification step. --- wiki/en/Running-a-Server.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/wiki/en/Running-a-Server.md b/wiki/en/Running-a-Server.md index ebfd71d04..d45d002d0 100644 --- a/wiki/en/Running-a-Server.md +++ b/wiki/en/Running-a-Server.md @@ -365,6 +365,30 @@ When a Server is running in GUI mode, the operating system will show an icon in - Headless Servers do not use `.ini` files. All configuration is given as command line options. If you are running a Server in GUI mode, after reading any command line options on start, it will store its configuration in the `Jamulusserver.ini` file. +## Increasing the UDP receive buffer (Linux) + +The Linux kernel's default UDP receive buffer (~208 KB) can be exhausted on a busy Server, causing the kernel to **silently drop incoming packets**. The result is complete audio interruptions for connected Clients — symptoms that look like a network problem but originate on the Server itself. + +This is especially likely with five or more simultaneous players. Increasing the buffer to 4 MB costs nothing and prevents it: + +~~~ +sudo sysctl -w net.core.rmem_max=4194304 net.core.rmem_default=4194304 +printf 'net.core.rmem_max=4194304\nnet.core.rmem_default=4194304\n' | sudo tee /etc/sysctl.d/99-jamulus.conf +sudo systemctl restart jamulus-headless +~~~ + +Restart the Server after running these commands so that the new socket picks up the larger buffer. The setting in `/etc/sysctl.d/` persists across reboots. + +To verify the buffer is not being overwhelmed during a session, find your Server's port in hexadecimal (e.g. the default port 22124 = `565C`) and check the drop counter: + +~~~ +grep -i ':565C' /proc/net/udp | awk '{print $2, $NF}' +~~~ + +The last number is the drop count. It should be near 0 immediately after restart and remain low during normal use. You can convert your port to hex with `printf '%X\n' `. + +--- + ## Troubleshooting If you are having other problems, [see this guide](Server-Troubleshooting). From 942b69d327afe15a2543fc94a73b6789bdd69438 Mon Sep 17 00:00:00 2001 From: John Dempsey <1750243+mcfnord@users.noreply.github.com> Date: Wed, 15 Jul 2026 12:45:37 -0700 Subject: [PATCH 3/4] Update wiki/en/Running-a-Server.md --- wiki/en/Running-a-Server.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wiki/en/Running-a-Server.md b/wiki/en/Running-a-Server.md index d45d002d0..c895d1c5e 100644 --- a/wiki/en/Running-a-Server.md +++ b/wiki/en/Running-a-Server.md @@ -369,7 +369,7 @@ When a Server is running in GUI mode, the operating system will show an icon in The Linux kernel's default UDP receive buffer (~208 KB) can be exhausted on a busy Server, causing the kernel to **silently drop incoming packets**. The result is complete audio interruptions for connected Clients — symptoms that look like a network problem but originate on the Server itself. -This is especially likely with five or more simultaneous players. Increasing the buffer to 4 MB costs nothing and prevents it: +This is especially likely with five or more simultaneous players. Increasing the buffer to 4 MB prevents it: ~~~ sudo sysctl -w net.core.rmem_max=4194304 net.core.rmem_default=4194304 From bd60e5364580fc547d2708b236848cab5ae7b0f6 Mon Sep 17 00:00:00 2001 From: jrd Date: Thu, 20 Aug 2026 19:34:49 +0000 Subject: [PATCH 4/4] Add background-service OOM kills as a second server-side cause of dropouts Same symptom as the exhausted receive buffer, different mechanism and fix. Measured across an 11-host fleet: hosts at 1 GB+ recorded zero OOM kills; three hosts below 512 MB accumulated 749, victim fwupd every time, each kill stalling the audio thread 2-3 seconds. Co-Authored-By: Claude Fable 5 --- wiki/en/Running-a-Server.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/wiki/en/Running-a-Server.md b/wiki/en/Running-a-Server.md index c895d1c5e..17674dacf 100644 --- a/wiki/en/Running-a-Server.md +++ b/wiki/en/Running-a-Server.md @@ -387,6 +387,24 @@ grep -i ':565C' /proc/net/udp | awk '{print $2, $NF}' The last number is the drop count. It should be near 0 immediately after restart and remain low during normal use. You can convert your port to hex with `printf '%X\n' `. +## Background services and out-of-memory kills (Linux) + +A second Server-side fault produces the same symptom as an exhausted receive buffer: brief audio interruptions for everyone connected, with no packet loss and a Server that looks completely healthy. Here the cause is memory rather than networking. When a background service grows large enough that the kernel's out-of-memory killer has to intervene, the kernel stalls other processes while it reclaims memory — and on a small instance that stall is long enough to interrupt audio. Measured on a 458 MB single-core cloud Server, each event blocked the Jamulus audio thread for **2 to 3 seconds**, with nothing in the Jamulus log and the service `active (running)` throughout. This is the concrete reason for the 1 GB memory minimum recommended above: Servers with 1 GB or more recorded no out-of-memory events at all, while Servers below 512 MB accumulated hundreds. + +The usual culprit on Ubuntu cloud images is `fwupd`, the firmware update service, which is enabled by default and can grow to around 145 MB. A cloud or virtual Server has no firmware for it to update, so it is safe to disable there. To check whether this has been happening: + +~~~ +journalctl | grep "Out of memory: Killed process" +~~~ + +Any output means the kernel has been killing processes on this machine, and your Clients will have heard it. The last field on each line names the process that was killed. If it is `fwupd`, disable it: + +~~~ +sudo systemctl mask fwupd.service fwupd-refresh.service fwupd-refresh.timer +~~~ + +Masking takes effect immediately, does not require restarting Jamulus, and persists across reboots. On a physical Server, where firmware updates are useful, leave `fwupd` alone and add memory instead. + --- ## Troubleshooting