[En-Nut-Discussion] Is this a bug or a 'Feature' ?

[Harald Kipp]

>
>On this note - has anyone had nut application that have run for months on
>end?

This will now become a long response.

We had been running several tests including long time stability
checks since the very first release and all tests were passed
without problem.

However, using Ethernuts in a real time world was different. It
later failed on large incoming packets (ping -l10000) for a
long time and using the public Internet was a whole different
story with all its delays and missing packets.

PPP requires even more. It is slow and packets may get corrupted
quite often. Just yesterday we detected another bug in the TCP
state machine. It appears when the peer doesn't receive the
ACK segment of a newly opened TCP window. In a local LAN this
almost never happens unless you are transfering large amounts
of data to the Ethernut board.

One of our Ethernut based applications is using TCP and UDP
in a non-stop system in a low traffic LAN. It works without
failure since more than half a year, using this old buggy
scrap named Version 2.4.2. :-)

Right now we are testing a 24 kBit MP3 stream on a 57600 Baud
analog modem line to the public Internet. (Don't try this with
Ethernut 1.3, you need Ethernut 2 banked memory). It runs
without general failure, but loses connection sometimes after
a few minutes, sometimes it runs for hours. This may not be
Ethernut's fault, but it's naturally difficult to track.

Beside Ethernut 2 we will soon publish a new revision F of
Ethernut 1.3. It includes a minor modification, based on a very
smart idea of Richard D. Hornbaker, using the IOCHRDY line of
the RTL8019AS to generate interrupts. Without this mdofication,
Ethernut is almost unable to transmit packets during heavy
broadcast showers, for example.

Putting it together: You can build a very reliable application
for a specific environment, which may miserably fail under
different circumstances. During the last two years many people
contributed to the code and spend many hours to track down
problems. The current stability confirms, that our decision to
keep it Open Source, was the best decision we could make.

Harald