When I tested buffered send mode, as I remember, I tried to increase number of IOBs. It did not affect the performance. Also I observed some strange spurious changes of receive window size that NuttX TCP side advertises. As I had better results with unbuffered mode, I started to use it rather than buffered one. I am going to experiment with buffered mode again later.
Do I understand correctly, that if I use unbuffered mode with a large user buffer (say 64 KB), then RFC 1122 still may pause NuttX TCP stack if an odd number of TCP segments are constructed based on the 64 KB buffer? Thus 0.5 second delay may occur at the end of 64 KB buffer during the last segment? On Thu, 2021-10-14 at 13:36 -0600, Gregory Nutt wrote: > > > Currently I'm using "unbuffered" send mode as in my case it > > > surprisingly provides twice as high throughput as "buffered" > > > one. > > > Though, I initially expected that "buffered" send mode should > > > have > > > better performance compared to "unbuffered" one > > > > It should not be faster. I suspect that is some artifact of a bad > > "buffered configuration" ... > > > > For example, if your configuration does not provide a sufficient > number of > IOBs, then the performance of the buffered case will be bad because > it will > be constantly blocked waiting for free IOBs. You really have to > carefully > tune the buffering to get the performance you want.
