TCP data passing speed

[knapkerd]

I am planning on passing a boolean using TCP.  The boolean will be used to tell the reciever to start writing data to a file.  The sender will also start writing to a file using the boolean as the trigger.  I was wondering what type of delay I might expect between the reciever seeing the boolean and the sender seeing the boolean?  Is it on the order of ms, microseconds, etc.?

Thanks.

--Robert

Message Edited by knapkerd on 05-14-2008 12:32 AM

[tst]

The delay probably depends a lot more on the network architecture (OS stack, physical network, actual load, etc.) than on LabVIEW. You can measure the the time by pinging the other system, but Windows will only give you 1 ms resolution and it would not be deterministic anyway. Your question is actually interesting and will probably be answered better by someone like Ben, but generally, the answer is probably in ms.

Of course, if your application waits before, while or after receiving the command, you will have an additional wait. What kind of synchronization do you need here? Can you trust the two systems to be synced in the first place?

[knapkerd]

Both computers are using a Producer/Consumer architecture.  So, I was planning on having the Producer loop send out the boolean from one computer (since the consumer may or may not be lagging) and then the Producer loop of the other computer loop recieving.  I would probably use some sort of indicator in the producer loop and a local in the consumer loop (again because using a queue might have to deal with consumer lag).  The producer loops usually operate in about 100-200ms, so I think that answers my question there.  I am guessing that the producer loops are the bottleneck on this one, but I was just checking.

Let me know if any of what I said sounds wrong (or if there is a better way), especially since I have not tested this yet.

I am also using two BNC2110 to collect the data and I guess I could use a trigger of some sort to pass the boolean, but I do not know how to do this, so if this is a better way, could someone point me in the right direction.

Thanks.

--Robert

[tst]

I still didn't understand how accurate your synchronization needs to be, and why you're actually using and logging on two computers. If your synchronization needs to be under a second, you should be fine, but since Windows is not a real-time OS, that will never be guaranteed.

As a side point, if you want to synchronize two different pieces of code (within a single LabVIEW instance), you can use the synchronization primitives, like a notifier with an infinite timeout, a rendevouz or an occurence. The advantage is that you don't have to loop.

[knapkerd]

We are actually using 3 computers.  The testing location is not near this office so the decision was made to use 3 laptops to aquire the data.  We are using 3 because of the limited screen size and the limited processing ability.  The synchronization needs to be on the order of 1ms and if possible we want all three synchronized, but the two that need a faster synchronization are more important.  I am guessing that this means I need to go with a hardware trigger.  What is the best way to go about using a hardware trigger?

Another question.  We want to pass one number (a double) by TCP.  What I am gathering from your post is that the passing of the data could take the better part of 1 second, and if we are writing data faster than that then we will miss this number every several while loops.  Am I correct on this?

Thanks.

--Robert

[tst]

---

knapkerd wrote:

What is the best way to go about using a hardware trigger?

No idea, not my area at all, and I'm not sure if you can get such synchronization (reliably at least) on a desktop OS. In any case, searching here should probably get you some answers.

What I am gathering from your post is that the passing of the data could take the better part of 1 second, and if we are writing data faster than that then we will miss this number every several while loops.

Not at all. For most communication systems, even doing a return trip around the world takes considerably less than a second and for a closed system it's usually under 1 ms. What I was saying is that because you have all kinds of unknowns (OS, network) you can't get a deterministic time, but you can be reasonably sure it will take less than a second unless something unexpected happens.

I can't say I understood your reasoning for not using a queue. Why not send all the data through the queue along with its timing information? That way you can log all the data without having to worry about the speed.

[knapkerd]

I think I realize why using a queue for the boolean would be a good idea.  And, the computer sending the signal is the only one that usually has any lag in the consumer loop and that is after the data is being recorded.  From what I understand we are only going to use that initial data startup once, so I think TCP should work assuming we get at least as fast as 1ms on the boolean passing.

Thanks for you help tst.

--Robert