[En-Nut-Discussion] TCP vs. Memory

[Michael Jones]

Hello,

Some time ago Bernd and Harald were having a good chat (see below) about the
way Nut/OS handles ZWP.

I have been struck with the same problem that Bernd described and have come
to the similar conclusions. A further observation is, that the SMSC
LAN91C111 chip is partly to blame as its lack of dynamic buffer sizes causes
packet loss whenever multiple small packages are received (Packet loss will
occur at the latest after the 8th consecutive received packet). This will
lead to packets put into storage for "future" use and ultimately to
retries... which only seems to aggravate the situation.

I end up with a system that is still running but will accept no further in
or outbound network connections (most likely due to memory fragmentation -
but I'm still investigating this part of the observation).

So the questions are:

Has anybody else made observations of similar behavior,
and what's the status on the changes suggested by Bernd and Harald?

Cu,
Michael

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Bernd Walter
Sent: Dienstag, 30. Juni 2009 14:55
To: Ethernut User Chat (English)
Cc: ticso at cicely.de
Subject: Re: [En-Nut-Discussion] TCP uses to much memory with zero window?

On Mon, Jun 29, 2009 at 07:41:44PM +0200, Harald Kipp wrote:
> Bernd Walter wrote:
> 
> > There is a memory protector in the receive, which keeps 2048 Bytes free.
> > Don't know why it doesn't protect my system from failing - maybe
> > the memory is too fragmented - 2048 is not very much.
> 
> Definitely. It had been 8k some time ago, but under certain conditions
> applications may run well at this limit so it had been changed. Anyway,
> it is not expected that an application will still run well. It's just a
> last try to stop TCP from eating up all resources.
> 
> The better solution will be to change the strategy in that way, that
> incoming packets are processed by the receiver thread and outgoing
> packets will use a dedicated thread. This had been discussed some days
> ago (too lazy to locate the thread) and I think it is a good solution to
> several problems.
> 
> > But it is not the right answer, because at some point it just ignores
> > incoming packets and therefor ZWP probes are not answered, which then
> > makes the peer drop the connection.
> 
> In this low memory situation the connection may not make sense at all.
> However...

It does make sense, because I should have enough memory free.
It is the problematic behavour in ZWP which creates the low memory
condition.

> > What do you think about to change that to something like this:
> >                 if (th_seq < thq_seq && nb->nb_ap.sz <= thq->th_win) {
> >                     *nbqp = nb;
> >                     nb->nb_next = nbq;
> >                     break;
> >                 }
> >                 if (th_seq == thq_seq || nb->nb_ap.sz > thq->th_win) {
> >                     NutNetBufFree(nb);
> >                     sock->so_tx_flags |= SO_ACK | SO_FORCE;
> >                     NutTcpOutput(sock, 0, 0);
> >                     return;
> >                 }
> 
> As it doesn't really need that much heap, I think this should be
> implemented. It will help to recover from temporarily low memory
situations.

That's not the purpose - it is to avoid a TCP socket to claim unlimted
heap space.
ZWP show two problems in current code.
1. it sends payload beyound receive window, which ethernut doesn't enforce
2. it send 1 byte payload only, which is stored very inefficiently.
The above is to enforce the receive window, so we don't store more data
then allowed.

> Many thanks, Bernd. Your detailed description of the problem really
> helped me to get back into this stuff again. I'm not yet able to tell,
> how the dedicated transmitter thread will change the status quo. But
> I'll keep you informed about its progress.

Thank you.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion