Bei einem Überlauf im Ringbuffer würde ich vom VDR eine Fehlermeldung (im syslog) erwarten.
Ja, da war was im Log, darum bin ich überhaupt drauf gekommen.
Die Meldung kam aber eher selten, wenn ich das recht erinnere.
Irgendwie bin ich dann auch irgendwie an Füllstand vor Ringbuffer gekommen. (Ist jetzt ein halbes Jahr her, Details erinner nicht mehr.)
Der Füllstand war für meinen Geschmack jedenfalls immer verdächtig niedrig. Was aber mangels Vergleich auch eine Fehleinschätzung sein kann.
Wobei, ein leer gelaufener Ringbuffer ja auch Folge eines massiven (evtl. aber nur kurzen) Überlaufs im UDP-Socketbuffer sein, wenn man genau überlegt.
Vielleicht teste ich mal bei Gelegenheit die von Dir vorgeschlagenen größeren Werte.
Das wäre echt hilfreich!
Wenn ich das recht erinnere, hattest Du damals die meisten Probleme.
Bei mir geht es mit den Grundeinstellungen eigentlich.
Zumindest meist ein paar Minuten lang, bis es dann irgendwann zu mehr oder weniger schweren Fehlern kommt.
Das ist zum Testen nicht so wirklich ideal, da man nie weiß, ob die Einstellung was brachte, oder ob man einfach nur Glück hatte.
Dann scheint es tatsächlich an den Buffern zu liegen und ist eher eine Systemkonfiguration.
Die Voreinstellung ist AFAIK immer gleich niedrig 
.
Die 10ms im Code kann ich auch reduzieren, aber ich will die Systemlast nicht hochtreiben.
Das mögliche Minimum ist 3ms.
Ich denke nicht, das man das groß merkt.
Problematisch ist in dem Zusammenhang, das einem da auch der Scheduler einen Streich spielen kann und die Zeiten u.U. länger werden als gewünscht.
Bei Xine scheint man da einige Klimmzüge gemacht zu haben, das macht man nicht ohne Grund.
(Auch wenn das ganze Konstrukt bei mir momentan mehr Fragen aufwirft als zu beantworten.)
/* System calls are not a thread cancellation point in Linux
* pthreads. However, the RT signal sent to cancel the thread
* will cause recv() to return with EINTR, and we can manually
* check cancellation.
*/https://sourceforge.net/p/xine/xine-lib/ci/default/tree/src/input/input_rtp.c#
zu einem anderen Extrem (viel zu hoch, die Beispielwerte)
Viel zu hoch würde ich bei 25MiB nicht sagen.
Bei den Datenraten und wenn man ~1s puffern will wären 5-10MiB angemessen. (ffmpeg puffert auch 1 oder 2 Sekunden und die Daten sollten schon rein passen.)
Bei net.core.?mem_max=26214400 hätte ich keine Bedenken. net.core.?mem_default würde ich aber ungern auf 25MiB hoch jagen, das beeinflusst ja alle Puffer.
#define BUFFER_SIZE (1024*1024)
/* Try to increase receive buffer to 1MB to avoid dropping packets */
optval = BUFFER_SIZE;
if ((setsockopt(s, SOL_SOCKET, SO_RCVBUF,
&optval, sizeof(optval))) < 0) {
LOG_MSG(xine, _("setsockopt(SO_RCVBUF): %s.\n"), strerror(errno));
return -1;
}Xine scheint zu versuchen den Puffer zu erhöhen (was bei mir natürlich dank niedrigem net.core.rmem_max normalerweise nicht funktioniert hat).
Evtl. sollte man das so ähnlich auch rein nehmen, dann reicht net.core.rmem_max zu setzen?
Für TCP schadet ein größerer Puffer sicher auch nicht.
vermutlich obsolet sind,) also eher nicht mehr. 
.)
.)
.)