UDP bandwidth issue

[richferrara]

I am coding a LabWindows 2013 application that is attempting to receive data from a VxWorks module over a gigabit ethernet connection via UDP.  The LabWindows program is running on Windows 7 (64-bit).  The VxWorks program transmits data at about 32MB/sec.  This should be well within the capability of our ethernet, but I am finding that the program is not reading all the datagrams.  At least half are being dropped.  The network statistics on the network page of the Windows control panel appear to indicate that all the data is being received by the PC.  Increasing the datagram size helps somewhat but not enough (the largest we've been able to transmit without incurring errors on the VxWorks side is 30KB).  Is there something we need to do on the PC or in LabWindows to get the actual gigabit performance out of our network?  Could it be a hardware issue?  Or is this just a weakness of UDP, and would TCP give us more reliable results?

[richferrara]

Just saw something very odd.

The UDP callback routine that processes the incoming message contains a call to SetCtrlVal to post the number of bytes in the datagram into a numeric indicator on the GUI.  I removed this call, thinking that maybe the time required to update the control was causing me to miss the next datagram.  To my surprise, the number of messages per second being processed by the program went down (from about 230 to 205; actual number being received per second from VxWorks is 416).  So I did the reverse and started lengthening the callback by performing the SetCtrlVal multiple times.  With 12 SetCtrlVal calls, I can get the messages per second into the 350-360 range.  If I add more than that, the rate starts going down again.

Why would making the callback routine longer result in the program missing fewer messages?