I’m having some serious trouble with the TCP/IP wireless throughput from the WINC1500 module to a simple Windows executable. I’m using the following setup:
- WINC1500 module with firmware version 19.6.1
- WINC1500 module is connected to STM32 NUCLEO64 board via SPI (clock set to 10 MHz)
- WINC1500 module is setup as Access Point with a private class A IPV4 address set to 10.0.0.1
- When I connect the windows machine the windows STA address becomes 10.0.0.100
I have a TCP port 6670 for streaming data to the windows application. The data is send in 50 msec packet chunks with the last packet in the chunk containing a sequence number.
The throughput should be around 56 kbit per second Total chunk size is around 334 byte every 50 msec.
1) I have to send back an ACK from the windows application every time I receive a chunk of data. If I don’t do that than the round trip time is around 40 to 60 msec. Sending an ACK back (just 1 byte) will result in an implicit TCP/IP ACK with a round trip time of 0.1 msec. What causes the extreme RTT when not sending back an ACK every time I receive a chunk of data??? I notice that not sending back an ACK will also result in an extreme interval between the asynchronous send
call and the notification that the transmission has finished by the callback with SOCKET_MSG_SEND
2) Sending chunks of data is not stable in the sense that there various long intervals between the send
call and the SOCKET_MSG_SEND callback
, even when the Windows application returns implicit ACKS. This is illustrated by the next plot where every blue pulse, when high, is the time needed for the asynchronous send with a blue pulse interval depending on the SOCKET_MSG_SEND callback. The red pulses show the send start to SOCKET_MSG_SEND callback. I don’t have a clue why there are extreme long periods between the send
and the SOCKET_MSG_SEND callback. Does anyone have any idea.
All help would be really appreciated!