[En-Nut-Discussion] TCP uses to much memory with zero window?

[Bernd Walter]

On Tue, Jun 09, 2009 at 01:03:15PM +0200, Harald Kipp wrote:
> Bernd Walter wrote:
> > I'd build a 3-axis CNC controller with AT91SAM7X256 and Ethernut-4.6.3.
> > The GCode data is transmitted via TCP.
> 
> Most interesting project.

I can send pictures of the board to interested persons.

> > After many succesfull tests using fast movement I had the problem
> > with slow movements that the memory filled up.
> > I see that the sending host is transmitting many zero window probe
> > frames and ethernut ack's them all.
> > Now I asume that ethernut wastes lot of overhead maintaining those
> > packets.
> 
> I do not believe that the zero window probes consume a lot of RAM, but I
> may be wrong. Acknowledging zero window probes shouldn't consume much
> RAM or CPU power.

It achknowledges 1 byte payload each time and I can see memory going
down, while my own code doesn't allocate memory.
Maybe I'm wrong, but it looks like the TCP code is not enforcing the
announced window.

> > Reducing SO_RCVBUF to 256 made the problem appear later.
> 
> In general it is not a good idea to reduce SO_RCVBUF below MSS. Actually
> I'd recommend to set it at least to 3*MSS. Nut/OS set the MSS (max.
> segment size) to 536 by default, which is the lowest value for avoiding
> fragmentation in todays environments. (Nut/OS cannot handle IP fragments).

I should have told that I also reduced MSS for this test.

> Any reason for using this Nut/OS version? At least 4.6.5 should be fully
> compatible and fixes several bugs.

Updating Ethernut code is always very difficult for me.
I tried updating to 4.8.2, but got many new problems.
Missing C-files in the Makefiles and such.
I also had problems with clock settings.
This is likely because I use a different build environment than most.
I build Ethernut with my code, so I can switch parameters, such as
CPU clock and CPU type easily.
I run FreeBSD as build OS.
And I have several local modifications.
Currently I'm almost done, and just left with multiple definitions
of _write, _close, etc with newlib and ethernut:
/usr/local/arm-elf/lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/thumb/interwork/libg.a(syscalls.o): In function `_write':
../../../../../../.././newlib/libc/sys/arm/syscalls.c:333: multiple definition of `_write'
contrib/ethernut-4.8.2/lib/libnutcrt.a(write.o):write.c:(.text+0x0): first defined here

> http://ethernut.cvs.sourceforge.net/ethernut/nut/ChangeLog?revision=1.463.2.5&pathrev=nut-4_6-branch
> 
> Any problems with 4.8? Just asking because I'd like to setup a similar
> environment here for testing and would prefer to test the latest stable
> version.

Looking at the code it seems that it is the same in this case, but I
can't test myself yet.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.