Our Colibri T20 acting as a tcpip client receives data from a remote board which includes an ADC+MCU and a W5500 SPI to Ethernet bridge.
Although the MCU gets samples at the correct rate from its local ADC, the T20 gets the data at a lower rate and we loose samples.
It’s a 100Mbps Eth link, and the required data flow is only <2Mbps. All packets sent by the MCU get correctly to the T20. But fewer than expected are actually sent, as if the socket was overloaded.
is there a packet sniffing tool to debug tcpip on WCE7+T20?
could it be a delayed ACK situation caused by the T20? We are using a tcpclient with C# at the T20 end.
Note: We are using a USB Hub that channels all Ethernet traffic into the USB port of the Iris carrier board using ASIX chips. And we are debugging at the same time as receiving packets from the ADC. Possibly too much data through the USB port…
The USB as bottleneck is one possible explanation. I think we first should understand the structure of the data transferred from the MCU to the T20. For example if there are many TCP packets with very little actual data payload - such as one sample per TCP packet - the protocol overhead can get huge.
I recommend to sniff the TCP traffic in order to understand where the bottleneck is. Unfortunately there is no such tool for WinCE.
It should be possible to use a (managed) Ethernet Switch in Hub mode, so you can attach a PC and sniff the data between MCU and T20 with Wireshark or a similar tool.
Or you take the trial-and-error approach: Collect multiple samples on the MCU side before sending them, so that the data transferred at once is in the range of 1kB. Does this help?
We don’t have access to a managed Eth switch but if push comes to shove we will need to get hold of one.
Packing more than 16bytes before sending the data does not help. Packing 30 sets of 16bytes in one packet or sending 16bytes in each packet does not make any difference. The transmission takes always around 40% more time than expected for a given number of samples.
Yet we know that the MCU is getting samples at the right rate from the ADC.
We are starting to suspect that the ASIX bridge and USB Hub on a custom connection board could be the root cause. If we uncover the root cause we will post it here.
There’s currently nothing I can do on the Toradex side to help you.
One option you could do is to create a small PC test application which sends dummy data to the Colibri module, instead of the Microcontroller. In this configuration it would be easy to use a Colibri Evaluation board instead of your custom board, and sniff the network traffic e.g. with Wireshark.
I have no simple explanation for such a high CPU load. I tried to reproduce the situation by sending a large number of small ethernet packets from my PC to the Colibri, but I never reached such a high load.
I suggest the following tests
Make sure the issue is not related to the fact that you are debugging over the same Ethernet interface: Copy the executable (in release mode) to the Colibri and let it run. Disconnect any device from the Ethernet which is not absolutely required. Do you still see similar CPU loads?
Please tell me more details about the Ethernet communication
Is the dataflow uni-directional from the DAQ device to the Colibri?
Are you using TCP or UDP packets?
How many bytes are in a packet?
How many packets do you send per second?
I did all my tests using a native C/C++ tool. Maybe you need to move parts of your code from C# to the native C/C++ domain in order to optimize performance.
We have tried 1. as suggested in your note. We generate a release version and ran it after disconnecting the USB connection (we are debugging via USB). The CPU usage is about the same (100% for one core and 60-70% for the other core).
The data flow is unidirectional. The DAQ device starts sending packets of 15 bytes as soon as the socket connection is created. The data rate is 240.000 bytes/second (16.000 packets of 15 bytes each, per second).
Could you paste your C/C++ code, or even better, post the VS2008 solution? We will then change the IP for the remote data generator and see what happens on our board.
I’m afaid there is no way to log the TCP/IP packets on WEC7.
I recommend you make the network traffic available through an Ethernet hub, then you can use Wireshark or a similar software on the PC to monitor the traffic.