TCP packet size from real time PXI chassis?

[odrulz]

Hello,

I've created a TCP/IP with XML server and client to be used as our standard connection between any remote systems and the main running application using the vi's described at http://zone.ni.com/devzone/conceptd.nsf/we...6256F170079411E. I've tested it out using localhost on a single computer as well as on two separate PC's running Windows on our intranet and everything works great. But when I send the target vi to a remote PXI chassis and run the host vi on a laptop connected only to the remote system (I've used a crossover cable linking the two directly and a patch cable with a hub in between, but either way the only two pc's on the system are the remote PXI and the laptop) I'm getting a failure.

I'm using a PXI 1045 chassis with an embedded 8187 processor running LV7.1 RT only - no Win OS on the remote system. The laptop is running Win XP with LV 7.1. At this point I'm not making any attempt to utilize anything on the PXI chassis other than the TCP communications.

The problem I'm seeing is the Read Meta.vi (located in the host vi running on the laptop) is only getting 4096 bytes, then the I get error 66, connection closed by peer (the remote PXI running the target vi - Write Meta.vi). The bytes to read value within the Read Meta.vi is 5450, which is the correct number of bytes needing to be read, but then it only reads 4092 bytes (4096bytes minus the 4bytes telling how many bytes to read) and so the XML data gets corrupted and the resulting error stops the vi's before they really get started.

1. Why would this do that?

2. Does anyone know anything about a packet size limit for PXI - TCP? I understand that LV 7.1.1 has a fix to allow packets to be up to 65536 bytes, which would solve my problem I believe, but we will want this to be used by hosts and remotes that run with LV 7.1 (and possibly earlier versions), so I need to resolve this 4096 byte issue as it is.

3. Do I need to rewrite the Read Meta & Write Meta code so that it breaks the data packets into maximum sizes? I was under the impression that TCP/IP communication did this automatically, is that incorrect?

I just downloaded the Maximum TCP Transfer vi's and will play with those, maybe I'll find something there.

Thanks for any help,

Scott

[Brant at VIE]

In my experience TCP communication in RT has some serious issues, but I haven't benchmarked anything after 7.0 so my advice might be out of date...

But have you tried setting the windows box to half duplex or a better method using a 10 mbit hub (not switch) in the path between the RT controller and the host? I resisted this insane idea for the longest time and when I finally did it, the communication between the host and RT was actually faster. Also, the RT TCP stack had some performance issues. At one time the Maximum TCP Transfer vi's would report my max bandwidth to be about 504.56 kbytes/sec. It was easy to point to RT as this controller still had Windows 2k installed and could easily surpass this max bandwidth.

Again, hope this isn't too out of date to be helpful. Please keep us informed. I was hoping NI had fixed some of these TCP issues in RT by now.

[odrulz]

Well I adjusted those Maximum TCP Transfer vi's and verified that I was able to send and receive up to 16kBytes reliably from the PXI target to the laptop host, with the best transfer rate occuring around 4kByte packet sizes. So there doesn't seem to be an issue with packet size limit, but something else within the Meta vi's. My TCP vi's work great between two pc's as well as when I just use localhost, so what's the difference in running the server from the RT target vs a pc? The only difference I can see in the block diagrams is that the Max vi's are sending arrays of numerics and the Meta vi's are sending an array of clusters. I'll tweak the Max vi's to send the same array of clusters that I use in my program and see what happens next.

I've tried using a crossover cable directly between the target and host and with a hub (not a switch) at 100mbit and both ways the packet was getting clipped. I haven't done anything with the duplexing, and I'll have to look that up to even know how, but will look into it and check it out. Did you ever find out the reason why half duplex and 10mbit gave you faster rates TobyS?

Thanks for the help

[Brant at VIE]

Did you ever find out the reason why half duplex and 10mbit gave you faster rates TobyS?

The reason I was given was that RT couldn't auto negotiate at full duplex correctly. Therefore, packets are lost, collide etc. It looks from several discussions out there that 7.1.1 RT update solves this problem. I couldn't find the original article, but if you do a google search for

2IHG7FZ8

and have google translate the page for you, it gives you an idea (in broken english) what your problem might be.

If someone out there can get the same article in native english that would be great. Hope this helps.

[odrulz]

From what I could gather from the googled 2IHG7FZ8 article, it was saying that the full duplex is only an issue with a crossover cable and that with a hub it works fine. Did you take it that way?

I'm seeing the exact same results every single time, with both a crossover cable or using a hub. And the article seemed to say the connection becomes unstable. I was getting error 66 during the Meta element transmission from the server to the client after 4096 bytes every time - the very first thing I transmit once the connection is established. And the max vi's were fine up to 16kbyte packets. So I was getting the same error at exactly the same point every time. I'm not sure if that's quite the same thing.

Thanks for the post though. I will keep that in mind if I run out of ideas that's for sure - which I've only really got one more idea to try out at the moment.

[odrulz]

Well the good news is that I was able to resolve the problem. The bad news is I'm not entirely sure why or how. I created much smaller TCP Host & Target vi's that only sent and received one thing each, but it used the same Meta data that I was using for my application. That worked fine. So then I set up the small test vi's to work with my app vi's. When I replaced my app target vi with the test vi and ran it to my app host, it worked. When I replaced my app host vi with the test and used my app target, I got the same error. So I replaced some of the Meta related elements and vi's on the target and now everything works fine. I think something must have gotten corrupted. I also noted that when I received the packet and everything worked the "bytes to read" value I was getting was 5445, when it failed the value was 5450. So the failure was related to an extra 5 bytes of something (linefeeds or carriage returns would be my guess - something that caused at least one empty line in the middle of my data) getting placed at the 4097byte mark. That's as much as I could figure out as to why it was failing.

If anyone has any better guesses or more information as to what I was seeing I would appreciate it just for further understanding.

Thanks for the help TobyS.

Scott

[crelf]

I also noted that when I received the packet and everything worked the "bytes to read" value I was getting was 5445, when it failed the value was 5450. So the failure was related to an extra 5 bytes of something (linefeeds or carriage returns would be my guess - something that caused at least one empty line in the middle of my data) getting placed at the 4097byte mark.

I'd love to see the actual data

[odrulz]

I'd love to see the actual data

Sorry, I didn't save any of the raw data. I mostly just used probes and indicators. I'd like you to see the data too, now that you brought it up.

[Rolf Kalbermatter]

From what I could gather from the googled 2IHG7FZ8 article, it was saying that the full duplex is only an issue with a crossover cable and that with a hub it works fine. Did you take it that way?

I'm seeing the exact same results every single time, with both a crossover cable or using a hub.

This is only really true for modern hubs. Older dual-mode hubs frequently had trouble to auto negotiate the correct speed and/or handshaking too.

Rolf Kalbermatter

[rgwagner]

Hi Scott,

The TCP/IP protocol has packet size limitations that are enforced by routers and other equipment on the network. Your setup indicates that there is no other equipment that is in place. However, I would check that the MTU and RWIN settings of the the machines are not the problem. The settings often cause problems with large data packets. You can use DrTCP021.exe to view and set these settings on a 2000/XP machine. The fact that you reduced your data payload size to make the connection work would indicate that the settings may be an issue.

Regards,

Rick