LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Change UDP Socket.ReceiveBufferSize under Windows

Solved!
Go to solution
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 ...

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

MSDN Windows Socket.ReceiveBufferSize property info


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 1 of 8
(7,214 Views)
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.
Brian K.
0 Kudos
Message 2 of 8
(7,188 Views)
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


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

0 Kudos
Message 3 of 8
(7,174 Views)
Solution
Accepted by topic author PhillipBrooks

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.

Brian K.
Message 4 of 8
(7,153 Views)

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


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Download All
0 Kudos
Message 5 of 8
(7,113 Views)
This is very usefull for my application.  Does anyone have something that will work in 7.1. 
0 Kudos
Message 6 of 8
(7,015 Views)
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



Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 7 of 8
(7,011 Views)
Thanks Phil, Where you work at DRC we may be using this for the same application.
0 Kudos
Message 8 of 8
(7,005 Views)