Is there a way to speed up a UDP connection?

[pawel]

Hello All

I receive a UDP packets over a network generated on full speed by another (C#) application.

Even with the "UDP read" placed alone in the while loop in a vi running in separated thread and with highest priority, it happens that "UDP read" does not read on time all packets.

I was wondering if there is some way to speed up the UDP readings, without changing my PC (1.5GHz, W2k, Dell-dimention).

I tried to use .NET sockets, and UDPClient (also from System.Net.Sockets) but it turned out that they are much slower than native LabVIEW "UDP read" function.

Does anybody have a nice trick to speed up the UDP reading?
Thanks a lot in advance.

cheers
Pawel

[altenbach]

UDP does not guarantee delivery of packets. You are demanding something that is beyond the capabilities of UDP and not in the spirit of its intended use.

How do you know if LabVIEW is really the problem. If you generate packets at full speed, you might saturate all kind of other bottlenecks (e.g. in switches and routers), especially if there is other traffic.

What is your packet rate? How big are the packets? If the packets are very small, your routers might be maxed out way below the theoretical wire speed limit.

I have an application that receives UDP packets, but the rates are probably lower than yours (up to ~2000 packets/s) and I have never lost a packet (I would know because the packets are serially numbered). I use a tight loop containing only the UDP read (with infinite timeout) and a FIFO buffer inplemented as a subVI with uninitialized shift registers.

What is your system CPU load when receiving? I was running into some receiving bottlenecks on very slow systems ('486, Pentium I). How clean is your system? Make sure to disable all other network use (AV updates, Windows updates, spyware, P2P applications, etc).

[pawel]

Hello Altenbach

Of course UDP does not quarantee delivery of packets from the protocol point of view, but it is simply to use and have small redundancy comparing to TCP, so it is faster. Anyways, I need to use UDP and that can not be changed.

I use two computers connected via one switch, and I also use the same machine to generate UDP packets and to receive, so there are no switches or network involved.

Now, why I am sure it is LabVIEW?
I am sure that all packets are delivered to the computer, because I captured them using EtheReal. This program allows to see all packets comming and going out from the PC. All packets are there.

You said you have about 2000 packets/s, with UDP packet size 1514 bytes it gives 3MB/s. My packets are generated with speed above 10MB/s. On top of that, all packets are fragmented (one big packet is about 60kB and I receive up to 100 of those packets), so UDP needs to concatenate them, which migth take time as well.

But, what I found out is that on the faster computer (2.5G) almost every time I got all packets.

The most important observation is that by using a C# and .NET sockets I receive all packets every tim, even on my "slow" 1.5G PC.

So it is something connected with LabVIEW.

I checked the processor usage while receiving, and it hardly ever is more than 60%.
And, as I wrote, I made a test with only UDP in the while loop, and still it is too slow.

Thanks anyways.
Pawel