TCP/IP response - MOD5234

[CelNB]

I used MOD5234 for our system. Our system is connected to a PC directly through a crossed Ethernet cable. PC continuously sends out TCP/IP packages (~1KB/package) to MOD5234; MOD5234 will return a package (~2KB/package) when it received one. I want to test the response time of MOD5234. I noticed if the PC sent out package frequently (for example, 20 packages per second), sometimes MOD5234 will take longer to return a package (could be longer than 500ms). Is there anything I can do to make MOD5234 response fast, or is it normal for MOD5234? Thanks.

[lgitlitz]

500ms sounds like a long time for a response time on closed network between the PC and a NetBurner. How are you calculating this time? I would make sure that you use a network capture application to record the times, Wireshark is a free and good application to use. This way you know exactly when the data leaves and enters your PCs interface.

Also, what type of computation are you doing on the data? Are there other tasks running in your application that could take priority over the calculations? Is this a continuously open TCP socket or do you close and open it for each packet?
I posted a stopwatch utility a few weeks ago which will work on the MOD5234:
http://forum.embeddedethernet.com/viewt ... ?f=7&t=397
You might want to use this utility to measure how much time it takes from when you first receive the packet to when you send it out of the module.

[rnixon]

It is equally possible that the delay has nothing to do the with mod5234. Wireshark is a great idea. That way you can see what is going on. A PC does a lot of stuff, and the delay could be there.

[CelNB]

Thanks for your suggestions. I downloaded Wireshark and captured an event. The screen capture file is as attached. PC ip address is 192.168.9.100 and instrument ip is 192.168.9.150. PC sent out a 128 bytes packages to instrument; and normally instrument could response (2048 bytes package) within several ms. Sometimes (for example: Package #4669), PC couldn't receive a correct package and will send out (by TCP/IP protocol) request again, then NB will response slow (~500 ms). Is there anything I can do on either PC or/and NB side to improve the communication reliability? Thanks.

[rnixon]

What type of pc and os are you using?

[CelNB]

What type of pc and os are you using?

I tried both Laptop (DELL Precision M4300) and Desktop (Dell Optiplex 755). Both run with WinXP SP3.

[rnixon]

A couple possibilities come to mind, both very difficult to debug. It looks like an ACK is being missed from the PC to the netburner. Question is, was the pc busy doing something and missed the sent data, or is there something in the netburner app you wrote that has a large critical section or non-maskable interrupt that is missing the ack from the pc? If it is either of the things on the netburner side, it would be an architecture issue, since no interrupt routines or critical sections should take more than some number of microseconds. If you did not add these yourself, then I would start looking on the PC side of things first.

[rnixon]

Or, maybe a intermittent/bad cable or connector? That would explain the behavior. Maybe as a test you should get completely new cables (not cross-overs) and a switch, and run the same test. If it were my time, I would definitely do this first.

[CelNB]

Or, maybe a intermittent/bad cable or connector? That would explain the behavior. Maybe as a test you should get completely new cables (not cross-overs) and a switch, and run the same test. If it were my time, I would definitely do this first.

Thanks rnixon.
I tried switch with regular cables, doesn't help.
I copied NB code for TCP/IP into a file, as attached. Is there anything wrong with the code? Thanks.

[rnixon]

No critical sections there, pretty standard stuff. It doesn't make sense that packets are lost by the pc end, but that is where the evidence in this thread seems to point. I'm really not sure what else to look at, other than to look for the lost packet in your wireshark trace to see if it is there (would have happened much earlier than the picture you attached. Please don't attache a big file, I won't be able to debug it. You need to look for the lost sequence number.

If that does not show the packet, it is still not definitive. The PC could be losing the packet before wireshark sees it. You might need to add a second PC on a hub (not a switch or you wont' see the traffic) that captures all the packets going back and forth, and see if the lost packet is on the wire. If it is, then the PC is the problem. If it is not, then there is something on the NetBurner side.