UDP write error 55 when sending video over network

[akang]

I am trying to send video over wireless network (IEEE 802.11b point to point link). I choose to use UDP because I do not need reliable transimission and do not
want the flow control of TCP to kick in.

I use the example UDP code and set up a simple example. I know I can compress the image, and I also need to deal with lost packet or out of order delievery problem.
But at this point I just want to see how fast the network can transmit. However, I find that labview always gives back an error, even I add 5ms wait between sending packets. The error turns out to be rare when the delay is larger.  But actually I expect to see much high rate than this. When I am just moving files using FTP by the same link, I can see the data rate reaches up to 5-6 Mb/s easily.  

I can understand that packets may get lost at high speed transmission rate while using UDP, but why do I get this code 55 error?

---------------
Error 55 occurred at UDP Write in TestUDPSender.vi
Possible reason(s):
LabVIEW:  The network operation is in progress.
---------------

I also used the code example to change the socket buffer size, but the same error occurs. It does not matter I run it over 1Gbs Ethernet, 54 Mbps WiFi link or even on the same machine.

I have attached my code.  Please help!

Thanks

Cindy



Message Edited by akang on 07-17-2008 11:23 AM

[NI-Bob]

Hello Cindy,

Thank you for contacting National Instruments.  I have been looking into this issue and I believe that this error may be occurring because you are trying to send out a packet before the previous packet has already been sent out.  This is why by increasing the wait within your while loop you are less likely to receive this error. 

In order to further troubleshoot this error and verify that this is the case I will need a little bit more information from you.  Can you tell me how large the packets are that you are trying to send?  Is it possible to make the packet size larger as well as the wait between sending packets? 

Another option would also be to try and move the 5ms wait within the while loop where the actual UDP Write node is located to see if that has an effect on the error.

Please let me know if you have any updates on this issue and we can continue troubleshooting from there. 

[JoeC]

Hey Bob,

I am having the same issue in an application that I am working on.  In particular, we want to be able to send a 30k packet via UDP as fast as we can, and at this time can not change how we transmit the data.  We are having an issue where we have to wait two to three milliseconds inbetween packets.  This data rate is backlogging UDP packets we have to send in our data queue, thus we have to run our system at a slower rate so as to not overflow the queue.

Thanks,

Joe

[Vivek_N]

Hello Joe,

As mentioned in Bob's previous post, I would recommend trying to send a larger packet size or/and placing a larger wait period between send commands. This error usually occurs when you are trying to send data when a send operation is already in progress. You could, of course, make sure that a faster processor is used and that as much processing power is dedicated to this VI as possible. Also, you could make sure that yoi

You could post your VI or a screenshot of it if have any questions on program architecture. 

[JoeC]

Vivek,

Thanks for the reply.  There is not too much to the VI.   The VI has a user input wait period in msec and a UDP send.

We will try placing the described functionality into a sub VI and setting it to a higher priority.

Joe

[benO-IT]

Hi,

Do you have a better rate with a higher priority for the VI calling the 'UDP send' ? How do you solve the problem ?

We try to test video transfert on UDP. We have to send 1kByte each ms by UDP to a video product. We can not go faster tahn 1 kBytes each 2ms. I konwn that your hardware can do it because if we run VLC, we have the expected rate. We must repect the 1kByte size. Can you help us ?

Thanks.

Ben.

[Vivek_N]

Hello Ben,

As the hardware is not the limitation, the lower speed must be due to the way your VI is programmed. Have you tried using any of the LabVIEW examples, such as 'UDP Sender'? You can find this in the Example Finder (Help >> Find Examples...). Try different examples out and see if you still observe the same rate.

[JohnSantaFe]

It looks like this problem was never resolved and unfortunately I've run across it too.

The problem is that the UDP Write function is not done sending the first packet before the next one shows up.  Putting a delay in can solve the problem but that's lame. It doesn't allow you to send at the maximum link rate.

I don't understand why the UDP write function 'returns' when it is not really done.

Is there a way to tell if the UDP write is complete?  Is it possible to try the next write, catch the error, backoff and try again? Would a sequence structure work to solve this?

I bet somebody has solved this......

Thanks.

[rolfk]

---

JohnSantaFe wrote:

It looks like this problem was never resolved and unfortunately I've run across it too.

The problem is that the UDP Write function is not done sending the first packet before the next one shows up.  Putting a delay in can solve the problem but that's lame. It doesn't allow you to send at the maximum link rate.

I don't understand why the UDP write function 'returns' when it is not really done.

Is there a way to tell if the UDP write is complete?  Is it possible to try the next write, catch the error, backoff and try again? Would a sequence structure work to solve this?

I bet somebody has solved this......

Thanks.

---

Playing with the dealy may be a solution. Also when you receive error 55 this means the send for this package has not been performed so a possible aproach would be to filter error 55 and in that case retry to send the same packet with some delay. Basically you would have more or less the same issues when doing this directly on Winsock level.

Generally you have to consider that an error in network communication does not always (actually quite often) mean that the operation was not successful and should/can/must be retried with some reasonable delay. So if you get an error, investigate it and decide based on the error what is the best course of action.

Troublesome? Well yes but that is how networking works. An application that wants to do robust networking has to deal with a lot of errors coming from the network communication layer and do various things based on those errors.those things can be abort everything, close and reopen connection, retry operation, drop operation and go on with the next operation, etc. What of these and in what cases is quite dependant of what you want to do, so LabVIEW can't do it for you as it has no idea what is your intended functionality.

Basically many network errors do not mean that your program should throw up its hands and scream BAD, (something that can often work for other operations in LabVIEW, since an error usually means there is something fundamentally bad with what you want to do), but not so in networking. An error indicates that there was a problem but such problems are very common in networking, due to different network topologies, conenction speeds, etc. Instead the program should intelligently retry the operation, attempt a reconnect or continue with the next operation depending on the error and the attempted operation. This is what makes robust network programming, and where a lot of sweat, late nights and what more goes into in network applications, also in LabVIEW.

[benO-IT]

Hello Rolf,

For my test bench, the tranfert with UDP message was a test for the Device Under Test. And i have to send lot of little packets to the DUT. I was working on the same PC with video player (like VLC) with the expectede rate, and with LabView, it was impossible to have the same transfert rate with little packets. There is a limitation on LabView. I think that N.I. should optimize the 'UDP write function'.

Regards,

Ben.