On Fri, 2015-09-25 at 15:17 -0400, Andy Walls wrote: > > From: David Halls > >Subject: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send > error:send_to: Message too long > >Date: Fri, 25 Sep 2015 09:05:56 +0000 > > >Dear All, > > > > > >When I increase my packet length in a transmission flow graph to over > >16,000 bits, I get the following error > > > > > >"ERROR: send error:send_to: Message too long​" > > This looks like the underlying sendto() system call is returning > EMSGSIZE. From man sendto: > > EMSGSIZE > The socket type requires that message be sent atomically, and > the size of the message to be sent made this impossible. > > > > > >this is from the UDP block which I am using in order to send the > >transmitted bits to the destination in order to perform BER. I am > >sending the packets in bursts, one packet every two seconds. > > > >I currently have the Payload size set to 147.2k and Send Null Pkt as > >EOF set to true. > > > >Is this some fundamental limit, or can I overcome the issue? > > 16,000 bits is 2000 bytes. The default MTU is usually 1500 bytes (for > IP header, UDP header, and payload together). Try modifying the MTU on > your machine's network interface to something larger, say 4000. > > The MTU of the receiving machine or other network hardware might still > be only 1500, so the the UDP packet could get IP fragmented. I'm not > sure how well UDP works when fragmented.
A little more Linux specific detail: http://man7.org/linux/man-pages/man7/udp.7.html " By default, Linux UDP does path MTU (Maximum Transmission Unit) discovery. This means the kernel will keep track of the MTU to a specific target IP address and return EMSGSIZE when a UDP packet write exceeds it. When this happens, the application should decrease the packet size. Path MTU discovery can be also turned off using the IP_MTU_DISCOVER socket option or the /proc/sys/net/ipv4/ip_no_pmtu_disc file; see ip(7) for details. When turned off, UDP will fragment outgoing UDP packets that exceed the interface MTU. However, disabling it is not recommended for performance and reliability reasons." -Andy _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
