Greg, I have write buffering enabled: CONFIG_NET_WRITE_BUFFERS=y
Here are my IOB settings: CONFIG_MM_IOB=y CONFIG_IOB_NBUFFERS=24 CONFIG_IOB_BUFSIZE=196 CONFIG_IOB_NCHAINS=24 CONFIG_IOB_THROTTLE=0 I do have some more data. I did a manual git bisect to find out where things started getting worse. I went back to Jan 1 and tested various commits with a custom program that talks to tcpecho (binary search to zero in on where the problems are). Commits before and after, up to the current tip, hang when I try to do consecutive TCP sends. Since Jan 1, most of the commits can't do more than 10 consecutive TCP sends of 1000 characters, that's a lot less than the MSS of 1447. However, commit c1f75af084010bd8a13b2481abc38d848cd545f2 seems to work the best. With that commit, as long as CONFIG_TIME_EXTENDED is not set, I can send as many 1400 character TCP sends as I want... thousands in a row. However, if I set CONFIG_TIME_EXTENDED=y, things stop working, I can only do a few TCP sends before the tcpecho hangs. Note that through all this, if I try to send more than about 1440 characters in a single TCP send, tcpecho will hang. That isn't right but I haven't tracked that problem down either. I tried to use a debugger and also syslog to trace what difference the CONFIG_TIME_EXTENDED was making– why it causes the hang if it is turned on. But I haven't figured that out yet. Do you have any ideas? Re: Wireshark, I have been using tcpdump extensively. The linux side seems to send the first TCP packet ok. tcpecho can echo back if CONFIG_TIME_EXTENDED is not set and the MSS is 1400 bytes or less. If MSS is larger than 1447 tcpecho will send a few packets and then hang. I haven't characterized the boundary (1400-1448 bytes). I also just figured out the CONFIG_TIME_EXTENDED thing this afternoon so haven't looked at tcpdump traces of it yet, but I will and report back. I can send some tcpdump traces if that would help. Would it? -adam On Sun, Feb 9, 2020 at 5:21 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > My question about MSS wasn't clear– what I mean is, to an application > (like > > tcpecho or tcpblaster), the size of MSS shouldn't matter. Shouldn't the > > application be able to send as many bytes as it wants? The TCP stack > > divides the stream up into chunks (of MSS length) and transmits them... > > sending more than MSS bytes should not hang the application...? > Yes, that is correct. > > That's not what I"m seeing with the NuttX that I'm using > (SAMA5D36-Xplained > > using the gigabit ethernet port, built from the latest master). > Do you have write buffering enabled? Do you have enough IOBs > pre-allocated? Have you tried looking at the traffic with WireShark? > > > -- Adam Feuer <a...@starcat.io>
