Got a device using W5100S, which works well with some networks providers, but fails with others.
When it send small packets, all is OK. When it starts to send more data, then it fails after some packets has been sent. This happens on some network providers. Same device connected to another network provider works well, without any problems. All devices send/rcv data from same server.
What can I do to debug such problem? does it have anything to do with Max Segment Size Register?
Thanks
Johanan
We not support the fragmentation of TCP.
I think didn’t you use fragmentation of TCP?
You can see same network packet via Wireshark program.Analyzing the packet will show you when it doesn’t work.
Hello,
it is the device using the W5100S that send a lot of information to the server.
It is using VNC protocol to send a LCD screen, and if the screen has a lot of graphics, it fails at some point.
The packets are sent one by one - each abot 1000 bytes, with the send() Wiznet lib function, blocking mode. So I don’t understand how it can be fragmented.
Please explain more.
Thanks.
Dear Johnan!
WIZnet Chip have a limitted socket buffer, so you have to controll the chip to send a large data.
I wonder how many sockets is used and how to configure socket TX / RX buffer.
As you mentioned, You sent one by one data about 1000 bytes to peer.
Even if you send data one by one, Some Data over 1000 bytes can be sent when Socket Buffer size is allocated bigger than your data size and peer can’t reply ack to the sent data.
This case causes the TCP retransmission and performance is reduced.
In the Worst case, If WIZnet chip receives an non-expected ack packet, Retransittion can not be recoveryed.
I will recommand as following.
1.After sending data, check please the socekt free buffer size with getSn_TX_FSR ().
2.If the socket size have increased as data sent size, then you can send next data.
For more detail, Caputer the packet with wireshark and share the orginal the file.
Thank you.
Thanks,
i will check buffer available size.
Problem is more complex, as in my lab (and some other users) all is working OK and very smoothly.
It is with some customers, and some of them are 3500 km away.
I have been able to output some logs via the device RS232 port and I have one user which allows me to login to his PC and check that logs, but so far I could not find the reason.
This customer can update the device firmware, and is cooperative, but even so, it is very difficult to understand what is the problem.
As I said, its a VNC protocol, In order to “solve” the problem, the device does not show any complex graphics (leaving only text and simple shapes on screen) when communicating by VNC, and this works without any issues, as the amount of data sent per screen refresh is much smaller. Whoever this is just for lowering the flames, and not a solution.
I tried disable delays flag (SF_TCP_NODELAY) but this does not make any noticeable difference.
I must assume that it is something which I don’t understand about under the hood of networks, as in some networks all is working very well, and some not. Very frustrating…
Johanan
Dear Johanan!
As I mentioned, If the peer exists on remote site, the ack from the peer maybe lost. It occurs the tcp re-transmission.
Even if WIZnet chips receives unexpected ack from the peer, the ack cannot be processed by WIZnet chips. Because WIZnet chips have a limitted resouce. WIZnet chips have to wait the ack by determined sending data size.
Most of all, It is need to check that WIZnet have lost a ack packet or receive the unexpected ack.
Can you capture the packet with wireshark?
And can you check the path delay information by using dos prompt as following.
c:\>tracert xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx means the peer IP address.
Thank you.
Hi,
Can I check any register value to see if there is lost or bad acknowledge? then I can resend the packet by device software, before I sent the next packet…
Am I making any sense?
Thanks
ack registers are only refered by WIZnet chip inside.
If you want to know the right ack point, you can call getSn_TX_RSR().
This function notifiy the free size of socket tx buffer.
So,
After you have sent some data, getSn_RX_RSR() return reduced value by the data size.
And then this function return value increased by the data size.
For more detail information, You shoud capture packets by using wireshark program.
you can download the program via google search.
In addtion, You can not resend the packet by software, because TCP’s retranmission only can be controlled by WIZnet Chips.
thank you.
