[En-Nut-Discussion] Ethernut TCP hangs

[Michael Smola]

Hi Dusan,

sorry about boring you with too much code, but Harald requested more details
about my configuration and my very long mail had been even much longer if I
would describe all details :-)

My LAN segment is pretty small and low traffic! The problem I have is not
the scheduling, my requirements are even very low.
As I figured out under 3.4.1.1 everything was "rock solid" over months.
After switching to 3.9.5.1 something changed? I just want to find out what
has changed and what to do to get the same state as under 3.4 to be
compliant with future NUT/OS versions. Maybe I will change later to your
proposal, but for the moment I want to find out whats wrong with my
current version.
 
> Hi Michael,
> 
> I prefer more info instead of plenty of source code. First - what about 
> ethernet traffic on your LAN segment ? Are there a lot of ARPs ? Even 
> collisions ?
> 
> If yes I suggest to use following modification. It allows other threads to
> run instead of continuously serving incoming packet storm. We found this 
> critical.
> 
> This mechanism follows what I discovered usefull with other embedded 
> cooperative OS where ethernet packets are served via a separate thread. 
> This was necessary even when run on 32-bit 66MHz chip with integrated
> (i.e. 
> DMA into RAM) ethernet controller.
> 
> Please keep me informed if this modification helps.
> 
> --------------
> 
> >     //JS
> >     unsigned long end_tick_count;
> >     //JS
> ...
> >         while (1) {
> >         NutEventWait(&ni->ni_rx_rdy, 0);
> >
> >         //JS 7/1/2005
> >        #define MAX_RECEIVING_TIME      100     //ms
> >         end_tick_count = NutGetTickCount() + (MAX_RECEIVING_TIME*2)/125;
> >         //JS
> >         /*
> >          * Fetch all packets from the NIC's internal
> >          * buffer and pass them to the registered handler.
> >          */
> >         do {
> >
> >             nb = NicGetPacket();
> >
> >             /* The sanity check may fail because the controller is too
> busy.
> >                restart the NIC. */
> >             if ((u_short) nb == 0xFFFF) {
> >                 NicStart(ifn->if_mac);
> >                 ni->ni_rx_size_errors++;
> >             } else if (nb) {
> >                 ni->ni_rx_packets++;
> >                 (*ifn->if_recv) (dev, nb);
> >             }
> >     #if 1
> >             //JS 7/1/2005
> >             if ((NutGetTickCount() >= end_tick_count))
> >             {
> >                 NutThreadYield();
> >                 end_tick_count = NutGetTickCount() + 
> > (MAX_RECEIVING_TIME*2)/125;
> >//                putchar('@');
> >             }
> >
> >         } while (nb && (NutGetTickCount() < end_tick_count));
> >     #else
> >         // original
> >         } while (nb);
> >     #endif
> 
> ---------------
> >From: "Michael Smola" <Michael.Smola at gmx.net>
> >Subject: RE: [En-Nut-Discussion] Ethernut TCP hangs
> >
> >New information on TCP stalls:
> >
> >I discovered, that with 3.9.5 only the last two http threads are
> activated
> >(3&4 in case of 4 http threads, 7&8 in case of 8 http threads).
> >With 3.4.1 the threads are permuted as expected from 1 to 4 (8).
> >
> >After a while, only the last thread is activated. Maybe later the 4th
> >thread is stalling too!?
> 
> 
> 
> Dusan 
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> 

-- 
Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl