| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Replace specific bandwidth numbers with clearer practical advice: discourages wireless connections and notes fiber works well. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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.
|
I don't know a lot about these buffers, but I deploy to very small Linux instances, and it wouldn't surprise me if they face resource starvation in the way described. |
Sorry, something went wrong.
…pouts 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 <noreply@anthropic.com>
As written, the verification grep matches the socket for port 22108 -- nothing -- so it prints empty output where the page promises a drop counter. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
Summary
Adds a short section to the Server Administration page documenting a Linux kernel tuning step that prevents silent UDP packet drops under load.
The problem
Linux's default UDP receive buffer is ~208 KB (net.core.rmem_default = 212992). When a Jamulus server is busy, this buffer fills and the kernel drops incoming UDP packets without any log entry or warning. The server and service appear healthy; the symptom is complete audio interruptions for connected clients that look like network packet loss.
Evidence from production
Measured on two public Jamulus servers before applying the fix:
After increasing the buffer to 4 MB, drops fell to zero within seconds of restarting the service on both servers. Server B's audio interruptions resolved completely. The fix has since been applied and verified on a fleet of 16 servers across DigitalOcean, AWS, Oracle Cloud, Hetzner, and Linode — x86_64 and aarch64 — all clean.
The fix
Three shell commands, no downside, persists across reboots:
Changes
This section is English-only in the source; translation pipeline will handle localisation as usual.