I've solved the problem with multi queue on kernel 5.15, but since kernel 6.x the problem is back. I can't figure out where, why and how. The only workaround is to start with the old kernel again.
Really frustrating
As you can't change the ring buffer size from virtio interfaces in the vm, I've allocated an e1000 interface to it and here I could changed the size with ethtool from 256 to 1024.
That's why I've tried with multiqueue afterwards.
Ok, nice!
I tried with an e1000 adapter, and changed the rx- and tx ring-buffer in the vm to 1024, which helped in the first step. Then I figured out that multiqueue on the virtio interface also fixes my issue. Maybe you could verify this?
So you finally increased the ring buffer size of the physical network interface and the bridge interface to tx 4096 rx 4096 and the issue has gone?
I'm also having problems with losing udp/rtp packets since the upgrade to version 7.
Thanks in advance!
Ich bin in einer nested VM und habe dort den Container am Laufen, das macht hald das ganze nochmal komplexer... :/
Hab jetzt mal versucht NW-Interface auf E2000 zu ändern - mal gucken, hab langsam keine Hoffnung mehr.
DONT CHANGE A RUNNING SYSTEM ;)
Das ist nur der Workaround für RAM-Überlauf.
Hmm... Bin jetzt auf einem Debian 11 Image, aber nach ca. 1 Stunde bekomme ich bei mehreren parallelen Streams auf einem Transponder nur noch Continuity Errors und die Streams freezen. Ich verstehs nicht
Mein Fokus lag auch auf den RAM Überlauf. Nachdem ich dieses jedoch behoben habe, kamen nach ca. einer Stunde streamen auf dem gleichen Transponder wieder Continuity Errors, welche ab dem ersten Zeitpunkt dann einfach weiter und weiter ansteigen, was ein Streamen so gut wie unmöglich machen...
Endlich bin ich auf diesen Thread gestoßen und weiß jetzt somit endlich mal wo der Fehler liegt. Ich habe den Sat2Ip Receiver ausgetauscht, neue VMs installiert, verschieden Container ausprobiert: Alles ohne Erfolg und bei Proxmox 6.4 keinerlei Probleme. Jetzt ist hald die Frage wie wir das...
Now what of all the output values is the current hard limit for memory usage?
edit: I guess you meant
cat /sys/fs/cgroup/lxc/CTID/memory.high ?
Used this and calculated 90 percent of the memory, then written to /sys/fs/cgroup/lxc/CTID/memory.high and /sys/fs/cgroup/lxc/CTID/ns/memory.high -...
Ok, to reproduce the issue a bit faster, I've changed the memory of the container to 512 MB.
root@ct-tvh-02:~# cat /proc/meminfo
MemTotal: 524288 kB
MemFree: 208 kB
MemAvailable: 406652 kB
Buffers: 0 kB
Cached: 406444 kB
SwapCached: 0...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.