LabVIEW
UDP write error 55 when sending video over network
benO-IT wrote: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.
Most likely VLC does some internal smart data merging for small packets before passing them to the TCP/IP socket. So a large part of the speed difference you see is likely due to the smarts of the VLC developers how they use the TCP/IP sockets and in order to get a similar performance you would have to have the same smarts to do something similar in LabVIEW. LabVIEW's TCP/IP and UDP functions do have some internal overhead compared to calling the socket API directly but also offer quite a bit of ease of use in comparison to use socket functions directly. But for really big performance differences you really should search it in the implementation on top of those functions.
I'm 100% that VLC is not simply dumping the data to the network socket as is but has some pretty involved software to optimize that, based on packet size, underlaying network speed determined from earlier transmission, and probably half a dozen other parameters that are dynamically adapted to the actual situation.
JohnSantaFe wrote:My first attempt was to use a 1 ms delay between each call to UPD write. That resulted in a net data transfer rate of ~ 2 Mbps on a 10/100 network. Changing packet sizes etc. does have some affect.
I then modified my code so that when I receive an error, I go into a while loop and keep trying to send the same data until the error goes away. That resulted in a net data transfer rate of ~ 20 Mbps for the same packet sizes.
It seems to me using a timeout can severely impact throughput and may not solve the problem anyway.
Looking at the details of the Winsock sendto() function, the default behavior is to block if there is no internal buffer available. It then returns the number of bytes written. The NI UDP write function returns right away with the error 55.
I agree there needs to be a more advanced UDP write function and knowing the number of bytes written would be useful.
John.
While blocking operation for sendto() is indeed default behaviour (not just for Winsock but for all Berkely based socket implementations AFAIK) it is seldom used for more involved data transfer protocols. Blocking operation is nice because it allows to do traditional sequential programming without having to deal much with error handling and nothing at all about retrying but it takes out all control from the application. It leaves it to the socket to do more or less efficient waiting on the final event but that is about it. The application thread is fully blocked and that has many other not so nice implications for an application.
In order to get the maximum performance one has to implement in most cases non-blocking operation which in the case of sockets is a bit of a hassle. But most somewhat advanced communication libraries take the bite and use non-blocking socket operation and handle the waiting and all the rest themselves. LabVIEW does that too and passes the non-0blocking behaviour mostly to the application level. And that is a fairly smart move. You can fairly easily implement blocking behaviour on top of a non-blocking implemention but the reverse is basically impossible.
And this is on the same computer you are running the VI on?
Because the only address you enter with UDP Open is the local network address. You only need to wire that address if you want the UDP socket to be bound to a specific internal network card on your computer, for instance when you have more than one network interface in your computer and want to make sure, the traffic will always go over a specific network interface.
But since you use the same address also as address to specify to whom you want to send the message, this is almost 100% wrong. If you would want to send to the local computer you would enter 127.0.0.1 or localhost, not the IP address of a local network interface. Since you enter a normal IP address this likely is the remote address and there is of course no way that the socket driver could bind the local side of the network socket to a remote address and it properly returns a "bad address" error.
This should be the same in the LabVIEW development environment.
