Intermittent TCP delay in RT to RT communication

[Ben]

You could define your own protocol if you choose. TCP/IP packets are guarenteed to be delivered in intact and in the order you sent them.

"...where is your start packet and where is your end packet? Or is that something you'd have to include on your own?"

Pretty much. Define a fixed length field at the head of your packet that tells you what you need to know when decoding, thnigs like;

Btyes

0-3       Packet Type i.e. "0" = Finite packet, all data follows, "1" = Init Packet, first of many, ...

4-7       Num of bytes that follow

8-?       Data

What happens if the PC is disconneted?

Does your switch show any sign of collisions?

Please try the bench-marking of packet-size vs performance.

The Trace Execution tool kit run on both sides (both RT mahcines) should reveal if your delays are really happening waiting for the TCP stack to do its job or something else that causing these hits.

Just trying to help,

Ben

[Sima]

Communication seems to be going much better after sending 250-element subsets of the 8000-element array at a time, and also sending and receiving over different ports. I'm running my send and receive loops at 10 ms and haven't seen those long pauses. I may do this for the PC <--> RT communication, too.

For the header info, I included the current packet number, which would let me know where to place the subset into the original array. My header size is 12 bytes, and with the data at 250x8(for DBL), my packet size is 2012. I know it's not a "round" or "even" (?) number in terms of bytes, but it seems to work. I wonder if there'll be any issues running over several days. I'm sure there can be some more fine tuning later down the line.