Why the execution times of VISA write is not linearly proportional with Byte sent

[Robert L]

Hello,

I am using LabView 6.1 on winXP and working on building an application with a function to detect the propagation delay of serial connection. I am using VISA and I have followed the example "Timing template" shipped with LabView 6.1 to generate the time elapsed.

My application sends the tick count value as data packet and receives it from the loopback path then compares it with the current tick count value. However, I found out that the Time elapsed for VISA write to send out all the data packet does not increase linearly with the size of data. The execution time of VISA writes actually increment every 14-byte data increase.

I am subtracting the value from "tic
k count value received" (which is a linear line) to the execution time of VISA write to obtain the path delay (which should be linear). The path delay I obtained from my application has a sudden drop when there is an increase in VISA write's execution time.

How do I correct this?

Any help is appreciated,

Robert

[Nick Reinhart]

Hi Robert,

Yes, the "14-byte phenomenon" you are seeing is indeed the FIFO effect. Serial ports, to prevent unnecessary interruption of the CPU, are implemented with hardware FIFO buffers.

Considering the transmit circuitry, the CPU can put a number of bytes in the FIFO rapidly in sequence. On any sort of modern computer architecture, the CPU can put bytes into the FIFO *far* faster than the serial port can transmit them out. That's why it makes sense to use FIFOs...if the CPU is going to be interrupted, it might as well use it's time effeciently and do a lot of work so it won't get interrupted until much later (than when it would be interrupted if it only put one more byte in).

Setting the first FIFO fill aside for a given large write, the CPU wi
ll be interrupted to refill the FIFO once the FIFO only contains N bytes to send (where N is less than the total FIFO size, S). Once the number of bytes falls below N, the serial port will interrupt the CPU and ask for more data to be sent out. At this point, the CPU can put S-N more bytes into the FIFO for transmission.

When you consider the last remaining bytes to be transmitted, it's going to cost almost the same amount of application time (what you see with the Tick Counts) to send out one more byte as it will to send fourteen more bytes. Again, the CPU can write these bytes is much faster than the serial port can actually send them out; but as far as the driver, VISA and LabVIEW are concerned, they only know the write is finished because all data has been written to the FIFO.

Hope this helps!

-Nick

[KizKas]

Hello Nick;

I'm encoutering the same situation. I'm finding a RS232 propagation delay of 20 ms (with MAX Tx FIFO size =64 Rx FIFO size=64 on both Tx -COM4 and Rx-COM5).

I can not explain this 20 ms. To make things worse, sometimes I'm getting 0.0001 ms (or less). I'm sending a 15 bytes packet that apparently takes 20 ms to trave !!!.

Please refer to my attachments TXside.vi and RXside.vi.

Please refer to the folllowing link for my exact situation and what is my problem:

                http://forums.ni.com/ni/board/message?board.id=170&message.id=54343&query.id=97644#M54343

I re-attach the code here. My results with this code are:.

                        1)  19.9 ms -20 ms when using 64 bytes both Tx and RX FIFOs at both ports. Rarely, I'm getting also 0.0001 ms (or less).

                        2) As described in "Loopback_Test_from_COM4_to_COM5_Using_Different_SerialFIFOconditions.txt"

Thank you very much for your help;

KizKas.

[smercurio_fc]

You are following up on a six-year old thread.  Plus, Nick hasn't logged in since 2003, so he's not likely to even see your message. Your best bet is to start a new thread and reference this as one that you saw as having a similar problem.

Nevermind, I see that you've started one. 

Message Edited by smercurio_fc on 02-03-2009 09:24 AM