On Fri 21 Feb 2025 at 16:53:54 -0000, Michael van Elst wrote:
> gdt%lexort.com@localhost (Greg Troxel) writes:
>
> >FWIW, on two of my systems N9 and N10, SNDBUF fails.
>
> The default kern.sbmax is 256kB. People that have "tuned" their TCP
> usually bumped that value, without you cannot use 1MB buffers.
>
> The default kern.somaxkva is 16MB. That might be not enough if you
> start using 1MB buffers.
We might actually want to do just that, or even bigger.
In another mail I mentioned a use case of piping (actually,
tcp-socketing) audio and video data from emulators/vice to the ffmpeg
command line program. The scenario goes somewhat as follows:
vice forks/execs "ffmpeg -f rawvideo -i tcp://127.0.0.1:10000?listen ... \
-f s16le -i tcp://127.0.0.1:10001?listen ..."
vice starts writing some video frames to port 10000, because ffpmeg
starts pre-reading some input from the first given input stream.
How much pre-reading is done is not documented.
Once ffmpeg has read some data from the first stream it will start
pre-reading from the second stream.
Note that so far this is all blocking I/O in a single thread.
Meanwhile Vice writes some data to the first stream to get it going,
then some data to the second one. This is also using blocking I/O.
Since it's unknown how much data needs to be written, people have made a
guess that happens to work on Linux. The amount of data is several 100s
of kilobytes up to maybe some megabytes. Apparently this data fits in
the available socket buffers.
On NetBSD however this amount of data blocks Vice, and if I recall right
it was on pre-writing the first stream. (Some analysis with gdb and
netstat shows that at that time the second one hasn't been opened yet).
If this also means that on NetBSD, the ffmpeg program pre-reads a
different amount of data than on Linux, I don't know, but I won't
exclude the possibility. This might well vary between major versions of
ffmpeg.
I tried adding code to Vice to increase the size of socket buffers to a
measly megabyte, but like in this thread, this failed... it would not
properly have solved the problem (that would likely require full async
buffering), but it would be a workaround.
-Olaf.
--
___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl>
\X/ There is no AI. There is just someone else's work. --I. Rose
Attachment:
signature.asc
Description: PGP signature