LabVIEW
How to increase UDP packet transmission speed
@Rock.cse wrote:
The string indicator is for just verify the data. Ignore it.
I thought that, if i use the UDP timeout each packet may send within timeout period. So i can receive the packets within time. But it doesn't work.
Opening a socket certainly takes time, not as much on UDP than on TCP but it does. So doing that in every loop iteration will slow you down considerably.
As to the timeout of the write function (or any other function of the LabVIEW VIs) this is an upper limit! If the operation can't be finished in that time then it will be aborted and an error gets returned. So it definitely doesn't work like a throttle which will define the time the function needs. In addition the TCP Write and UDP Write will simply dump the data to the network socket and let it manage the transmission itself. This dumping is normally very fast so the only reason that even a micro-mini timeout may fail on the write is that the socket is blocked because of any internal buffers being exhausted. Quite an unlikely scenario on a modern desktop system. The TCP Write and UDP Write usually return control back to your program long before the data has actually been transmitted out of the network interface.
Do you know that it only sends two packets or are only two packets received at the other end?
If you are sending UDP data at a high rate, packet loss will be significant?
Also, you should make a distinction between "packets" and the data transmission. Since there is fragmentation, each 6442 byte transmissoin will be fragmented into several packets. You seem to apply the word "packets" indiscriminately.
How does the receiver program look like? Is it LabVIEW based?
Here is a quick rewrite that seems to do about the same as your code (more or less). It even includes a loopback receiver for testing using localhost.
I read the file only once. What good is it to read and process the same file at a high rate with the same outcome?
@Rock.cse wrote:
If the udp can able to send a packet within micro seconds, my problem will be solved. For example, 1st packet should send in 0.00, then 2nd packet in 0.25ms ,3rd packet in 0.50ms, and so on.. If it sends like this means, in 2ms i will receive 8 packets at the receiver end.
You are trying to get deterministic behavior from a general purpose OS (or are you running LabVIEW RT for this?) over a shared network connection using an unreliable protocol (UDP). Your expectations are very misguided.
I am not aware of a DAC card that does network communications. Is this an embedded system? Do you have some documentation? I still don't understand the purpose of all this.
@Rock.cse wrote:
I have to sample the sine wave into 16 samples. Each sample will have the 24 bit resolution. I am storing these 16 samples into an 32 bit array. I am getting an input for sending the no. of samples per packet. For example, if i give 2 samples per packet means, it will send the first packet with first 2 samples then, the 2nd packet will have next 2 samples and so on. This process will routine until i hit the stop button. This is for one channel. Next, the input is no. of channel. If i give the input as 128 means, each sample will repeat 128 times. consider the input like 128 channel, 16 samples per packet then the packet size will be ( 128*3 = 384 bytes for 1 sample, 384 * 16 = 6144 bytes) This is my original data. Along with, i am adding 256 bytes( A text file will have 256 bytes constant data) in front of these original data. So my packet size will be (256 + 6144 = 6440 bytes).
And what does the receiving end do with all this data? And why does timing matter?
@Rock.cse wrote:
For sending the bulky amount of data, UDP is the suitable protocol. And UDP is faster than TCP. So that, i choose UDP. Earlier, i was stored all these data in a file. After i read the file to send the data. Now i modified all these as below.
UDP is only suitable if lost packets are acceptable.
