[En-Nut-Discussion] Nutcracker

[Harald Kipp]

Hi,

I did a test here, using a very simple UDP echo
server for Ethernut 1.3F and Ethernut 2. In parallel
to 128 byte UDP packets, ICMP ping requests are sent,
one per second.

With Ethernut 2, 131,072 kBytes were received and
echoed in 1677 seconds. No problems, no lost pings,
no lost UDP packet. Note, that our office LAN is
calm, not much traffic. Also note, that this is not
the maximum throughput reachable, just a simple
receive and forward with small packets.

Now to Ethernut 1.3. The first test stopped working
after a few seconds. OK, I thought, might be another
problem...The second test runs for nearly a minute,
and then stopped again...

And most amazing, pings are still answered? Grumble....

First I thought, that Bengan is on the right track.
When Ethernut 2 works and Ethernut 1.3 doesn't,
it must be a problem of the Realtek driver.

Finally I found the answer. Yes, indeed the Realtek
driver works less reliable. The echo server on the
Ethernut and the UDP sender on the PC didn't use
timeouts. If the sender doesn't get a response, then
it hangs in the receive routine.

After implementing a timeout on both receiver ends,
the system works as expected. However, the timeout
rate with Ethernut 1 is quite high, about every several
hundred packets a timeout occurs, while on Ethernut 2
not a single timeout occured.

The reason may be the IOCHRDY line, which is ignored
on the Ethernut hardware.

Anyway, when using UDP, one has to prepared losing
packets. TCP, with it's build in retries will not
be harmed.

This is no reason to switch to Ethernut 2. Losing
packets is completely normal and will only harm badly
written UDP applications (Sorry Bengan :-)). Note, that
Ethernut 2 is consuming much more power. Some users even
got alarmed by the temperature of the LAN91C111 and
thought it was broken. During the test, Ethernut 2 draws
more than 400 mA, while Ethernut 1.3 stays cool at 100 mA.

Last not least, no crash at all. In the meantime,
Bengan reported by private email, that he is using
the watchdog. That may cause the "crash".

He modified the Realtek overflow recovery and kindly
sent me his code. Because of some other issues, it's
still in the alpha stage (long interrupt latency).
I doubt, that this will finally solve the Realtek
problem, because this is hardware related. But it
may reduce bad effects.

In the background, Ethernut 1.3 is still running,
so I'm not able to report the final transfer rate
results now. But it looks slower than Ethernut 2.

Harald