Re: Error sending UDP message: No buffer space available, not reproducible with truss

On 10/01/26 18:52, Damjan Jovanovic wrote:
>
>
> On Sat, Jan 10, 2026 at 5:18 PM Rodrigo Osorio <rodrigo@freebsd.org> 
> wrote:
>
>     Hi,
>
>     I have this strange behavior with an application I ported a couple of
>     weeks ago
>     multimedia/tsduck which can broadcast MPEG transport streams over UDP.
>
>     When I run the application as a regular user :
>
>     tsp -O ip 239.1.0.38:11112 <http://239.1.0.38:11112> -I file
>     media.ts I got an error on the
>     sendto() call
>
>     "No buffer space available"
>
>
> This is normal on FreeBSD: send() to a full UDP send queue causes the 
> ENOBUFS error.
>
> This can be surprising, because on other operating systems, the 
> behaviour is different. On Linux, a full send queue causes UDP packets 
> to get silently dropped - no error is reported back to the caller. 
> Many applications developed with Linux in mind are thus noisy about 
> ENOBUFS on FreeBSD, while they have no choice but to be silent about 
> Linux's dropped packets.
>
> Try calling ioctl() with FIONWRITE and FIONSPACE (see the ioctl(2) man 
> page) to see the used and free queue space, when you get ENOBUFS, and 
> if necessary, increase your send buffer size, or improve your network 
> performance.
>
>
>     When trying to analize the issue with ktrace or truss, sudenly I
>     got no
>     errors and
>     the application just works.
>
>       5798: socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP)    = 6 (0x6)
>       5798: setsockopt(6,IPPROTO_IP,IP_RECVDSTADDR,0x8205160a4,4) = 0
>     (0x0)
>       5798: bind(6,{ AF_INET 0.0.0.0:0 <http://0.0.0.0:0> },16)      =
>     0 (0x0)
>       5798: getsockname(6,{ AF_INET 0.0.0.0:63851
>     <http://0.0.0.0:63851> },0x820515ef4) = 0 (0x0)
>       5798: setsockopt(6,IPPROTO_IP,IP_MULTICAST_LOOP,0x820516088,1) =
>     0 (0x0)
>
>     [...]
>
>       5798: sendto(6,"G@\0\^Q\0\0\M-0\r\0\^B\M-A\0\0\0"...,1316,0,{
>     AF_INET
>     239.1.0.38:11112 <http://239.1.0.38:11112> },16) = 1316 (0x524)
>
>     Since the two calls are performed (without and with truss) are
>     performed
>     without any change, I wonder
>     what can explain this behavior. calling the application again without
>     truss leads to the same buffer error.
>
>
> The use of truss slows down the application, and maybe that causes 
> data to be sent slower, so the send queue doesn't fill up?
>
>
>     Here is the full trace using truss:
>     https://people.freebsd.org/~rodrigo/tsduck_no_buffer_space.txt
>
>     Thanks in advance for your help.
>
>     -- rodrigo
>
>
>
> Regards
> Damjan
>
Hi Damjan,

Thanks for you explanations who helps me to understand the issue.

I was able to make the application works by increasing the incresing the 
buffer size
or by decreasing the amount of packets sent per second.

For the record this is the way to decrease the packet throughput:
 > tsp -r -O ip 239.1.0.38:11112  -P regulate -I file  media.ts

Regards,
-- rodrigo