• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 40 subscribers
  • Views 4111 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC3120MOD: Default TCP recv window size

CC3100MODBOOST: TCP previous sequence not captured and duplicate acknowledge

Michel B.
Intellectual 300 points
Part Number: CC3100MODBOOST
Other Parts Discussed in Thread: TMS570LS0432, CC3100

Hello,

I am using a CC3100 module as an access point and TCP server. With my PC I connect to the access point's WLAN. Then a program on my PC connects to the CC3100's server and the server starts to transmit data with TCP packets. My goal is to collect CAN bus messages with a TMS570LS0432 microcontroller and send them via the CC3100 to my PC with a TCP protocol. Currently I am sending about 1500 TCP packets per second (1 TCP packet (68 bytes overall) for every CAN bus message (14 data bytes)). There is only data transmission from CC3100 server to the PC client. My transmission works fine until the CC3100 sends a "TCP previous segment not captured" packet to the PC (see my wireshark capture file, marked packet no. 50914). This is followed by a lot of "TCP DUP ACK" messages send from my PC. The CC3100 does some retransmissions then and all the data send is received correctly. But there is a lot of delay caused by this behavoiur, so my buffer for CAN messages on the controller is full and I loose some CAN messages. In this this thread the same problem is described, but no one posted a solution. So can anyone tell me what the cause of this behaviour is? Why does the CC3100 send a "packet not captured" message and why are there so many "DUP ACK" messages from the PC?

Best regards
Michel

WiresharkCaptureFile.zip

  • 0
    Intellectual 300 points
    I'm sorry for this mistake, since I filtered out the windows traffic in my wireshark capture file, the "TCP previous segment not captured" packet is no. 50870 now.
  • 0 in reply to Michel B.
    TI__Mastermind 34940 points

    Hi Michel,

    Please verify whether you are receiving a SL_SOCKET_TX_FAILED_EVENT for any of the sl_Send calls. Also, to narrow down the issue, please try receiving with iperf (this is used in the TCP socket example of CC3100 SDK: processors.wiki.ti.com/.../CC3100_TCP_Socket_Application

    "TCP previous segment not captured" is a message produced by wireshark (not sent by CC3100): documentation.help/.../ChAdvTCPAnalysis.html .


    Regards,
    Toby

  • 0 in reply to Toby
    Intellectual 300 points

    Hi Toby,

    I don't get any errors in my program when calling sl_Send(), all the data is sent correctly. The only problem is the delay caused by the strange behavior. I just tested my program with iPerf. The CC3100 device, connected as a client to an iPerf server sends data correctly. See this iPerf log and the Wireshark capture file "iPerf Server.pcapng" (there is only a single retransmission at the beginning).

    C:\Users\miche>"C:\Portable\iPerf 2.0.9 Win 64\iperf.exe" -s -p 5001 -i 1
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 62630
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 1.0 sec   176 KBytes  1.44 Mbits/sec
[  4]  1.0- 2.0 sec   172 KBytes  1.41 Mbits/sec
[  4]  2.0- 3.0 sec   175 KBytes  1.43 Mbits/sec
[  4]  3.0- 4.0 sec   174 KBytes  1.42 Mbits/sec
[  4]  4.0- 5.0 sec   174 KBytes  1.42 Mbits/sec
[  4]  5.0- 6.0 sec   175 KBytes  1.43 Mbits/sec
[  4]  6.0- 7.0 sec   172 KBytes  1.41 Mbits/sec
[  4]  0.0- 7.9 sec  1.34 MBytes  1.43 Mbits/sec

    But there seems to be a problem when using the device in server mode respectively receiving data with the device, since there are a lot of TCP packets marked as "TCP Window Full", "TCP ZeroWindow" and "TCP ZeroWindowProbe" by Wireshark. As far as I can analyse (I am not a wireshark expert), the PC is sending data too fast and the CC3100 device tries to tell iPerf stop sending data, until it reduces its receive buffer to zero and the connection breaks. But I think this is currently not my problem (am I right?). For the Wireshark Log File see "iPerf Client.pcapng", this is the iPerf log for iPerf in client mode:

    C:\Users\miche>"C:\Portable\iPerf 2.0.9 Win 64\iperf.exe" -c 192.168.1.1 -p 5001 -i 1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 26171 connected with 192.168.1.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  1.0- 2.0 sec   128 KBytes  1.05 Mbits/sec
[  3]  2.0- 3.0 sec   256 KBytes  2.10 Mbits/sec
[  3]  3.0- 4.0 sec   128 KBytes  1.05 Mbits/sec
[  3]  4.0- 5.0 sec   128 KBytes  1.05 Mbits/sec
[  3]  5.0- 6.0 sec   256 KBytes  2.10 Mbits/sec
[  3]  6.0- 7.0 sec   128 KBytes  1.05 Mbits/sec
write failed: Broken pipe
[  3]  0.0-17.9 sec  1.50 MBytes   704 Kbits/sec

    Since there are no messages marked as "TCP Dup ACK" by Wireshark (iPerf client as well as iPerf server), which caused a delay and the CC3100 device sends data correctly,  I hope there is no problem with my program.

    Here are both Wireshark log files, one for iPerf in sever mode, one for iPerf in client mode.

    Wireshark Capture Files.zip

    I hope this additional information helps a little to solve the problem.

    Best regards
    Michel

    PS: Sorrrey for the late reply, there was a weekend in between.

  • 0 in reply to Michel B.
    TI__Mastermind 34940 points
    From my understanding, you have evaluated the following cases:
    - (CC3100, AP mode, TCP client) --------> (iperf, TCP server) working ok
    - (CC3100, AP mode, TCP server) <------- (iperf, TCP client) window full, etc

    Please also try the following case (I believe this matches your use case?) :
    - (CC3100, AP, TCP server) ---------> (iperf, TCP client)
  • 0 in reply to Toby
    Intellectual 300 points

    Hi Toby,

    thank you for your reply. You are right I didn't test my use case. I was already aware about this, but in iPerf 2 the server is always the receiver and the client is always the sender (I don't know a way to change this in iPerf 2). Nevertheless I changed my program code to send data in server mode and I tried to launch an iPerf 2 client with this command "<iPerf 2.0.9> -c 192.168.1.1 -p 5001 -i 1". But then both the iPerf client and the CC3100 server try to send data and I get these "Window Full" and "ZeroWindow" messages again. The iPerf output is the following then:

    C:\Users\miche>"C:\Portable\iPerf 2.0.9 Win 64\iperf.exe" -c 192.168.1.1 -p 5001 -i 1
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.2 port 27871 connected with 192.168.1.1 port 5001

    When canceling iPerf after a minute with CTRL + C, since there is no more output, this is shown by the console:

    write failed: Connection reset by peer
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-80.6 sec   256 KBytes  26.0 Kbits/sec

    So i definitivly think this is the wrong way. So I found an alternative.

    In iPerf 3 you can use a the "-R" parameter to run iPerf in reverse mode (server sends, client receives, see https://iperf.fr/iperf-doc.php). So I tried to use iPerf 3 with this command: "<iPerf 3.1.3> -c 192.168.1.1 -p 5001 -i 1 -R". But iPerf 3 doesn't seem to be compatible with my program code or the CC3100, since it throws the following error message:

    C:\Users\miche>"C:\Portable\iPerf 3.1.3 Win 64\iperf3.exe" -c 192.168.1.1 -p 5001 -i 1 -R
iperf3: error - received an unknown control message

    I can't tell by the Wireshark capture files why this message is produced by iPerf 3. Here are my Wireshark capture files, if they are helpful for anyone: 4762.Wireshark capture files.zip

    If I distance myself from my current analysis and look at my problem's analysis from a "TCP view", there should be no difference between server and client after the connection is established, as it is fully symmetric (both server and client can send and receive data). As we have seen the confuguration CC3100 sending data and PC / iPerf receiving data (no matter who is client or server) worked fine in my tests. So before struggling with iPerf 3 error messages as a consequence of incompatiblity or whatever, I would look for another way to solve the problem.

    The next thing I could try would be sending less TCP packets with more payload. I think more than 1500 packets per second with only 14 bytes payload but 68 bytes total is quite a lot of traffic. So I could only send one packet every 10 ms. This would be a maximum of 100 packets per second and about 210 bytes payload (15 x 14 byte messages) and about 264 bytes total (if packet overhead is the same). Maybe then there is less trafic "on wire" (816 kbit/s vs. 211,2 kbit/s) and there are less packets to be acknowledged, so occurring retransmissions don't cause so much delay.

    Since I am interested in this topic anyway, is it possible that the CC3100 or the TCP protocol in general is not designed to be used for transmitting a lot of single small messages? I expected TCP to handle that correctly. I want to transmit a lots of small messages, since the transmitted data is passed to a live display. A transmission of large messages with 1400 bytes would result in "display stuttering" (or whatever you can call this in english). So whenever a new large packet is received, the screen is updated  (this would be once a second then). But I guess you can't see a 10 ms delay.

    I hope I could help a little with this additional information. I'll reply soon, if I have tested my idea. If you have any further ideas how to fix my CC3100's strange behavior or how to avoid the iPerf 3 error message please let me know. I am thankful for any answers.

    Best regards
    Michel

  • 0 in reply to Michel B.
    TI__Mastermind 34940 points

    In general, it's better to send longer rather than shorter TCP packets (due to overhead as you have mentioned).

    The purpose of the iperf checks was to verify that the PC application wasn't the limiting factor (eg. taking more time to process the received packets). Now that you have mentioned a screen, another thing to keep in mind is that typically a 60 Hz (~16 ms) refresh rate would be sufficient. You're currently sending every ~0.7 ms, so you have a lot of flexibility in terms of what you can set your packet size.

    Regarding the CC3100 as a server sending, perhaps you can try a simple python client to receive data from CC3100 server, and see if you see similar results in the wireshark capture:

    import socket


TCP_IP = '192.168.1.1'
TCP_PORT = 5001
BUFFER_SIZE = 1024

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((TCP_IP, TCP_PORT))

while (1):
    data = s.recv(BUFFER_SIZE)
    #print "received data: ", data #print if needed

s.close()

    If you see similar results, then you can narrow down focus to CC3100 (and not your PC application).

    Also, for the previous iperf configuration you used (CC3100 client sending to iperf server), please try receiving more than 7.9 seconds, since in the original wireshark capture, the "TCP Previous segment not captured" occurs at ~26 seconds.

  • 0 in reply to Toby
    Intellectual 300 points

    Hi Toby,

    thank you for your answer. Meanwhile I have tested to send less TCP packets with more payload. Now my data transmission works perfectly even with higher transfer rates. So this seems to be a working solution.

    Since I am still interested in the "TCP prevois segment not captured" message, I have programmed a little client receive program for testing the CC3100 as a server sending data. As I am not familiar with Python, I used Java instead with this code:

    import java.net.Socket;

public static void main2(String[] args) throws Exception {
		
	Socket socket = new Socket("192.168.1.1", 5001);
		
	if (!socket.isConnected()) {
		return;
	}
		
	while (true) {
		int i = socket.getInputStream().read();
	}
}

    When transmitting lots of small TCP packets, I get the same behavior as before (lots of "TCP Dup ACK" etc). If I transmit messages only every 10ms with more payload, there are no problems. So I think the CC3100 cannot accept to many TCP acknowlegment messages (I don't think my PC is too slow for a microcontroller or the CC3100 and the Java application's receive buffer is about 65000 bytes). Either it is not possible to use the CC3100 for sending lots of small TCP packets (because of limited hardware or whatever) or there is a software fail in my software or the CC3100's program. But I am simply establishing a connection with my CC3100 after setting it up in access point mode and then sending data to a client with sl_Send() like this:

    _i16 status = sl_Send(socketID, data, length, 0);
if (status <= 0) {
    printInt("[TCP Server] Data send Error: %d\r\n", status);
    status = sl_Close(socketID);
    return TCP_SEND_ERROR;
}

    I did not configure any parameters for TCP transmission if this is possible at all. Now I think my problem is solved by sending less and larger TCP packets. But if you can tell me why it does not work with more smaller TCP packets even when using a lower data rate, I would like to know the cause of this.

    Thank you for your support.

    Best regards
    Michel

  • 0 in reply to Michel B.
    Intellectual 300 points

    I forgot to attach the Wireshark capture file I recorded using the code above. Maybe it is helpful for problem analysis if there is a problem with the CC3100.

    Java TCP client receiving data.zip

  • 0 in reply to Michel B.
    TI__Mastermind 34940 points
    It's possible this could be due to the CC3100 concurrently acting as AP. If your application does not necessarily require that CC3100 be an AP, perhaps you can try connecting the CC3100 to an external AP, and your PC to that same AP, then check if you see similar results.

    Glad you got your project to a state that's working. Hopefully you don't experience too much "display stuttering".
  • 0 in reply to Toby
    Intellectual 300 points

    Hi Toby,

    as my CC3100 is placed in a racing car for the telemetry and I don't want an external router being the access point, I think my current setup is the best. Since most laptops don't have an access point mode, its too circuitous use the CC3100 in station mode. By the way I don't think it is the acces point mode overtaxing the CC3100 (there are no other clients connecting), but rather the load of TCP acknowledge packets.

    Thank you for having a working solution now!

    Best regards
    Michel