TCP uses to much memory with zero window?

[Bernd Walter-2]

I'd build a 3-axis CNC controller with AT91SAM7X256 and Ethernut-4.6.3.
The GCode data is transmitted via TCP.
Some commands, e.g. long lines,  take a long time to process, so the
incoming data is often used slowly.

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 started with 15k free memory.
My routines are using static allocated memmory, so 15k free should be
enough under normal conditions.
Reducing SO_RCVBUF to 256 made the problem appear later.
Then I freed up more memory and started with about 25k and the system
was staying alive, but now I have the problem that the machine stops
in between - maybe because the incoming data is spread over so many
packets?

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

[Ethernut]

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.


> 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.


> 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).

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

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.

Harald


_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Bernd Walter-2]

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@...> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Bernd Walter-2]

On Tue, Jun 09, 2009 at 04:35:02PM +0200, Bernd Walter wrote:

> On Tue, Jun 09, 2009 at 01:03:15PM +0200, Harald Kipp wrote:
> > Bernd Walter wrote:
> 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

I've finally managed to get it to compile again.
Ethernut was missing calloc and strdup:
[916]devel> svn diff
Index: contrib/ethernut-4.8.2/crt/Makefile
===================================================================
--- contrib/ethernut-4.8.2/crt/Makefile (revision 4180)
+++ contrib/ethernut-4.8.2/crt/Makefile (working copy)
@@ -92,7 +92,7 @@
         fread.c fscanf.c getc.c getchar.c gets.c kbhit.c scanf.c ungetc.c vfscanf.c \
         fprintf.c fputc.c fputs.c fwrite.c printf.c putc.c putchar.c puts.c vfprintf.c \
         sprintf.c sscanf.c vsprintf.c vsscanf.c gmtime.c localtim.c mktime.c time.c \
-        tzset.c errno.c malloc.c environ.c getenv.c putenv.c setenv.c
+        tzset.c errno.c malloc.c environ.c getenv.c putenv.c setenv.c calloc.c strdup.c
 
 SRCCP = fprintf_p.c fputs_p.c fscanf_p.c fwrite_p.c printf_p.c puts_p.c \
        scanf_p.c sprintf_p.c sscanf_p.c vfprintf_p.c vfscanf_p.c \

Not sure if it was missing in the original Ethernut code, or happened
when merging my own changes in.

Since I saw similar problems on the list without real answers:
For the people seeing similar problems with multiple definitions.
It took the implementations fom newlib, which the sucked in invalid
and colliding syscall based implementations.
I removed the unuseable objectfiles from the lib:
arm-elf-ar d libg.a syscalls.o
A few more deletes up to deleting the wrong calloc and strdup I've
found out the missing Ethernut source files.
The same symptoms can be produced by other missing files as well.

Runtime test not done yet.

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

[Bernd Walter-2]

On Tue, Jun 09, 2009 at 04:35:02PM +0200, Bernd Walter wrote:
> On Tue, Jun 09, 2009 at 01:03:15PM +0200, Harald Kipp wrote:
> > Bernd Walter wrote:
> > 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.

Updating worked after a few minor compile time problems.
System is runnning with 4.8.2.
I have a bit more free RAM after the update :-)
But the network problem is still there.
I started with about 26k free and it went below 3k and finally the
system hang.
Socket setup was default again.
Maybe the problem with slow processing was my fault, because I had
only a single packet in the buffer with my low settings, but I can't
tell because the system died before it really started the short line
pattern in my testjob.
The testjobs starts with several long lines, which processes very slow
and finishes with many short lines, which processes coordinates much
faster.

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

[Ethernut]

Bernd Walter wrote:

> Updating worked after a few minor compile time problems.
> System is runnning with 4.8.2.
> I have a bit more free RAM after the update :-)

We changed the direction. Unlike with previous upgrades we hope to be
able to reduce memory usage in newer versions. ;-)


> But the network problem is still there.
> I started with about 26k free and it went below 3k and finally the
> system hang.

I'm not sure that this is network related. After upgrading, you are now
able to dump heap usage.

Add

HWDEF+=-DNUTDEBUG_HEAP

to UserConf.mk (build and app tree) and rebuild everything. At specific
locations within your application call

NutHeapDump(<file-pointer>);

replacing <file-pointer> with your console stream, probably stdout.
You'll get a list of all allocated fragments, which will help to locate
the memory hole.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Bernd Walter-2]

On Wed, Jun 10, 2009 at 04:09:33PM +0200, Harald Kipp wrote:
> Bernd Walter wrote:
>
> > Updating worked after a few minor compile time problems.
> > System is runnning with 4.8.2.
> > I have a bit more free RAM after the update :-)
>
> We changed the direction. Unlike with previous upgrades we hope to be
> able to reduce memory usage in newer versions. ;-)

Nice idea ;-)
For me the most missing feature in respect to save memory however would
be a listen queue.
Needing multiple threads for a service consumes a major part of memory
in my applications.

> > But the network problem is still there.
> > I started with about 26k free and it went below 3k and finally the
> > system hang.
>
> I'm not sure that this is network related. After upgrading, you are now
> able to dump heap usage.
>
> Add
>
> HWDEF+=-DNUTDEBUG_HEAP
>
> to UserConf.mk (build and app tree) and rebuild everything. At specific
> locations within your application call
>
> NutHeapDump(<file-pointer>);

I like that feature.

> replacing <file-pointer> with your console stream, probably stdout.
> You'll get a list of all allocated fragments, which will help to locate
> the memory hole.

It agrees with my assumption.
After some time it fills up with many small netbuf allocations:
[...]
0x20b420(60) netbuf.c:146
0x20b3e4(40) netbuf.c:185
0x20b394(60) netbuf.c:146
0x20b358(40) netbuf.c:185
0x20b308(60) netbuf.c:146
0x20b2cc(40) netbuf.c:185
0x20b27c(60) netbuf.c:146
0x20b240(40) netbuf.c:185
0x20b1f0(60) netbuf.c:146
0x20b1b4(40) netbuf.c:185
0x20b164(60) netbuf.c:146
0x20b128(40) netbuf.c:185
0x20b0d8(60) netbuf.c:146
0x20b09c(40) netbuf.c:185
0x20b04c(60) netbuf.c:146
0x20b010(40) netbuf.c:185
0x20afc0(60) netbuf.c:146
0x20af84(40) netbuf.c:185
0x20af34(60) netbuf.c:146
0x20aef8(40) netbuf.c:185
0x20aea8(60) netbuf.c:146
0x20ae6c(40) netbuf.c:185
0x20ae1c(60) netbuf.c:146
0x20ade0(40) netbuf.c:185
0x20ad90(60) netbuf.c:146
0x20ad54(40) netbuf.c:185
0x20ad04(60) netbuf.c:146
0x20acc8(40) netbuf.c:185
0x20ac78(60) netbuf.c:146
0x20a7c4(40) netbuf.c:185
[...]

I can send you complete traces, if you want.
I have no local modifications in netbuf.c, so linenumbers should match
with yours.

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

[Bernd Walter-2]

On Thu, Jun 11, 2009 at 01:57:00PM +0200, Bernd Walter wrote:

> On Wed, Jun 10, 2009 at 04:09:33PM +0200, Harald Kipp wrote:
> > Bernd Walter wrote:
> > > But the network problem is still there.
> > > I started with about 26k free and it went below 3k and finally the
> > > system hang.
> >
> > I'm not sure that this is network related. After upgrading, you are now
> > able to dump heap usage.
> >
> > Add
> >
> > HWDEF+=-DNUTDEBUG_HEAP
> >
> > to UserConf.mk (build and app tree) and rebuild everything. At specific
> > locations within your application call
> >
> > NutHeapDump(<file-pointer>);
>
> I like that feature.
>
> > replacing <file-pointer> with your console stream, probably stdout.
> > You'll get a list of all allocated fragments, which will help to locate
> > the memory hole.
>
> It agrees with my assumption.
> After some time it fills up with many small netbuf allocations:
> [...]
> 0x20b420(60) netbuf.c:146

[...]

Hi Harald and others interested in this,
 I investigated this problem more deeply in the source.

I still fail to see how the window size is enforced.

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.
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.
The right answer would be to resend the zero window size, so the peer
knows that we are still alive and the peer didn't miss a window reopening.

The packed makes it up to NutTcpStateEstablished, which is basicly Ok,
because it might contain a new ack and we can't just ignore a ZWP.
But is is also queued into the socket after calling NutTcpProcessAck,
which is not Ok.

There is a check to handle duplicate packets (tcpsm.c@1207 for me):
                if (th_seq == thq_seq) {
                    NutNetBufFree(nb);
                    sock->so_tx_flags |= SO_ACK | SO_FORCE;
                    NutTcpOutput(sock, 0, 0);
                    return;
                }
If I understand it correctly it drops the packet and then queues a
new packet to reack the current receiver state.
Since the enqueued packet also contains the current windows size this
is excatly what we need as a response to the ZWP as well.
Unfortunately the packet is already queued before:
                if (th_seq < thq_seq) {
                    *nbqp = nb;
                    nb->nb_next = nbq;
                    break;
                }
                if (th_seq == thq_seq) {
                    NutNetBufFree(nb);
                    sock->so_tx_flags |= SO_ACK | SO_FORCE;
                    NutTcpOutput(sock, 0, 0);
                    return;
                }

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;
                }

There is still no protection from queuing up to the receive window with
single byte payloaded packets from bad peers, but it protects to happen
under normal conditions.

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

[Ethernut]

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...

> 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.

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.

Harald


_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Bernd Walter-2]

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@...> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Michael Jones-11]

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@...
[mailto:en-nut-discussion-bounces@...] On Behalf Of Bernd Walter
Sent: Dienstag, 30. Juni 2009 14:55
To: Ethernut User Chat (English)
Cc: ticso@...
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@...> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Ethernut]

Michael Jones wrote:

> Some time ago Bernd and Harald were having a good chat (see below) about the
> way Nut/OS handles ZWP.
...
> 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?

The situation is this: Adding an additional thread would require more
RAM again. There had been a previous discussion in this list about how
to split interrupt handling, so it won't require a full fledged thread
in many drivers. I tried to implement some kind of lightweight thread,
called task. A specific thread in the kernel should provide a task queue.

I know, this may sound weird without knowing further details. Well, the
thing turned out to become quite complicated and after about a week
trying to implement this beast I had to give up due to lack of more
time. In fact I ended up in a situation, where I was in doubt whether
this complicated part would really help to save memory.

My current suggestion is, to go the simple way and just add a full
thread to the transmitter. This will need more RAM, but help to get
packets out as soon as possible. And it will also solve the ICMP packet
loss after ARP cache flush.

Harald


Btw. the reason for the current design was the RTL8019, which typically
crashed in input overflows. Resetting the controller blocked the system
for several hundred milliseconds, so Nut/Net was designed to avoid input
overflows. Actually this was a bad idea. It should have been designed to
get rid of outgoing packets in the first place and simply ignore
incoming packets in low memory situations.

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion