topic Re: Change UDP Socket.ReceiveBufferSize under Windows in LabVIEW

Change UDP Socket.ReceiveBufferSize under Windows

PhillipBrooks — Mon, 26 Feb 2007 14:37:56 GMT

I've previously used a LabVIEW LLB that allows customizing a TCP socket (TCP_NODELAY LLB) to enable and disable delayed acks. This NI LLB contains a pasword protected VI that returns a raw TCP socket ID that is in turn used as an input to a Call Library Function node. A previous post on the NI forums indicates to me that the Windows default buffer size is used (8192 bytes).

I would like to increase the Socket.ReceiveBufferSize for a LabVIEW UDP Connection ID.

MSDN Windows Socket.ReceiveBufferSize property info

Re: Change UDP Socket.ReceiveBufferSize under Windows

Brian_K. — Wed, 28 Feb 2007 00:52:22 GMT

Hi Phillip,

So are you calling a DLL like the LLB does, or are you using the built in UDP VIs from LabVIEW. If you are using the built-in VIs then the operating system and LabVIEW implement buffers that the user cannot configure. If you are using a DLL call, then which one is it in particular. Thanks for the extra information.

Re: Change UDP Socket.ReceiveBufferSize under Windows

PhillipBrooks — Wed, 28 Feb 2007 15:12:44 GMT

Sorry for the confusing post. I'm using the LabVIEW UDP VIs. My situation is:

I am running three UDP receivers (Reentrant VI & VI Server) using three point-to-point Gigabit Ethernet connections. I drop data when sending rates are > 2.4 Mbit/sec. Data is only sent in one direction. I have used a TCP version of my application where the CPU load is ~ 50%, with (of course) no dropped data because of TCP. I have also used TCP_Nodelay.llb to disable nagling, and see 80 to 90% CPU utilization.

I've simply replaced the TCP Open, Receive and Close functions with UDP functions. While running, my CPU load fluctuates from 80 to 100%, and I drop data. UDP has no sequencing or acks to manage, so I can't imagine why the CPU load would be higher AND that I would drop data. I've run the UDP version at half my goal (1.2 MBit/sec) without dropping data. I do use a 1 ms timeout on the UDP and TCP reads.

I would like to use the same technique to retrieve a UDP raw socket ID, then use that ID to configure SO_RCVBUF instead of TCP_NODELAY to try and eliminate the data loss. I would like to increase the buffer size, or even possibly set it to zero after reading this CodeGuru forum entry.

Message Edited by Phillip Brooks on 02-28-2007 10:13 AM

Re: Change UDP Socket.ReceiveBufferSize under Windows

Brian_K. — Thu, 01 Mar 2007 21:42:09 GMT

HI Phillip,

So I am still not 100% sure what we are trying to do, but I did find something. In the [LabVIEW X.X]\vi.lib\Utility\tcp.llb there is a VI called UDP Get Raw Net Object.vi. I think it is the equivalent to the TCP version you were talking about. Tell me if I am on to something.

Re: Change UDP Socket.ReceiveBufferSize under Windows

PhillipBrooks — Tue, 06 Mar 2007 17:38:58 GMT

That was the piece of information that I needed. I am now able to increase the buffer size for a UDP socket (from default of 8192 bytes), and my data loss problems have gone away for now.

I'll share my simple VI (LV 8.0) for those who may be interested in the future...

Message Edited by Phillip Brooks on 03-06-2007 12:39 PM

Message Edited by Phillip Brooks on 03-06-2007 12:40 PM

Re: Change UDP Socket.ReceiveBufferSize under Windows

Draper_Lab — Thu, 29 Mar 2007 15:39:59 GMT

This is very usefull for my application. Does anyone have something that will work in 7.1.

Re: Change UDP Socket.ReceiveBufferSize under Windows

PhillipBrooks — Thu, 29 Mar 2007 17:24:30 GMT

I've saved and attached the file in 7.1 format. I do not have 7.1 on a computer where I can easily test it though. Note that the DLL call is to wsock32.dll.

If you are using LabVIEW for Linux, you may need to modify the DLL call...

Phillip Brooks
Dynamics Research Corp - ETO
West Newton, MA

Re: Change UDP Socket.ReceiveBufferSize under Windows

Draper_Lab — Thu, 29 Mar 2007 17:37:55 GMT

Thanks Phil, Where you work at DRC we may be using this for the same application.