[En-Nut-Discussion] Fear not, good Sir... TCP might still be saved...

[Michael Jones]

Don't let the version number confuse you - I'm almost head - especially when
\dev and \os are concerned.

Cu,
Michael

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Michael Jones
Sent: Monday, June 26, 2006 4:48 PM
To: 'Ethernut User Chat (English)'
Subject: RE: [En-Nut-Discussion] Fear not,good Sir... TCP might still be
saved...


Hello Harald,

Here the app/httpd runs without any problems:


Nut/OS 3.9.8.2 HTTP Daemon...192.168.16.197 ready
[4] Connected, 24244 bytes free
[4] Disconnected
[4] Connected, 24118 bytes free
[3] Connected, 23405 bytes free
[4] Disconnected
[3] Disconnected
[3] Connected, 24244 bytes free
[3] Disconnected
[3] Connected, 24124 bytes free
[3] Disconnected
[3] Connected, 24244 bytes free
[3] Disconnected


So maybe there is some other difference. I have added a few of Henrik's
changes (but not the CriticalSections) but there might also be other changes
that play a role here. 

Cu,
Michael

-----Original Message-----
From: harald.kipp at egnite.de [mailto:harald.kipp at egnite.de] 
Sent: Monday, June 26, 2006 3:15 PM
To: Michael Jones
Cc: 'Matthias Ringwald'; henrik at proconx.com
Subject: RE: [En-Nut-Discussion] Fear not, good Sir... TCP might still be
saved...

Hi Michael,

app/httpd sample outputs

   Nut/OS 4.1.6.1 pre HTTP Daemon...

and hangs there when using this update. Doesn't look like but may
be caused by my already changed event handling.

Harald

At 12:22 26.06.2006 +0200, Michael Jones wrote:

>Hello all,
>
>I might (but only might) have found the last missing bit...
>
>
>This is a new version of the "stopped timer" section at the end of
>NutTimerProcessElapsed(...). The previous version did not remove the first
>nor the last entry from the list.
>
>    // remove stopped timers, if nutTimerStopped
>
>     if ((nutTimerList && tempTimerStopped)) {
>         NUTTIMERINFO *tn_prev = NULL;
>
>         tn = nutTimerList;
>
>         while (tn) {
>             if (tn->tn_callback == 0) {
>                 // remove entry from linked list and update ticks
>                 if (tn->tn_next)
>                     tn->tn_next->tn_ticks_left += tn->tn_ticks_left;
>
>                 if (nutTimerList == tn)
>                     nutTimerList = tn->tn_next;
>                 else
>                     tn_prev->tn_next = tn->tn_next;
>
>                 NutHeapFree(tn);
>             } else
>                 tn_prev = tn;
>
>             tn = tn->tn_next;
>         }
>     }
>
>I can see a vast improvement when using my massive ARP/Random Packet
>floods... I hope you can find this too!
>
>Cu,
>Michael
>
>
>-----Original Message-----
>From: harald.kipp at egnite.de [mailto:harald.kipp at egnite.de]
>Sent: Sunday, June 25, 2006 7:57 PM
>To: Michael Jones
>Cc: Matthias Ringwald; henrik at proconx.com
>Subject: RE: [En-Nut-Discussion] Fear not, good Sir... TCP might still be
>saved...
>
>Hi,
>
>Well, combining Henrik's and Michael's (broadcast) changes seems to fix the
>problem, but I'm currently testing an alternate approach, which decreases
>critical sections even compared to the current CVS HEAD.
>
>I added a counter (td_qpec) to THREADINFO and redefined
>
>#define NutEventPostFromIrq(qp)     \
>{                                   \
>      if (*qp == 0) {                 \
>          *qp = SIGNALED;             \
>      }                               \
>      else if (*qp != SIGNALED) {     \
>          NUTTHREADINFO *tp = *qp;    \
>          tp->td_qpec++;              \
>      }                               \
>}
>
>This way interrupts are not directly modifying thread queues, except
>they _are_ changing an empty queue handle to SIGNALED. Before context
>switch is done, these counters are processed and the related queues
>are updated.
>
>Currently the highest priority thread sometimes disappears, but I'm
>sure I will located this last bug. The hole event processing looks
>much more simple now.
>
>Regards,
>Harald
>
>At 18:44 25.06.2006 +0200, Michael Jones wrote:
>
> >Hello!
> >
> >Do these files include the final changes that you mentioned in your
latest
> >post?
> >
> >I would like to test them. I can see some promising modifications but I
>also
> >flinch at the CriticalSection just as Harald did.
> >
> >Cu
> >Michael
> >
> >
> >
> >-----Original Message-----
> >From: henrik at proconx.com [mailto:henrik at proconx.com]
> >Sent: Friday, June 23, 2006 6:11 AM
> >To: pavlu at HWserver.cz; Michael.e.Jones at web.de
> >Subject: Re: [En-Nut-Discussion] Fear not, good Sir... TCP might still be
> >saved...
> >
> >Hello,
> >
> >I came across some issues with Nut/OS and short time-outs with high
> >interrupt loads on the serial ports which I could not resolve for weeks
> >and today I finally was able to track down the issues.
> >
> >Following your posts in the mailing list, I believe your issues might
> >relate to the same topic: Timeout events and Interrupts.
> >
> >Attached you find 3 files with patches for Nut/OS 4.1.5. Maybe you want
> >to try them.
> >
> >NutTimerProcessElapsed(): Needs a critical section for the event
> >call-back as the callback pointer is manipulated in IRQ context.
> >
> >NutEventTimeout(): I extended the critical section as there is otherwise
> >some unexplainable race condition between NutEventTimeout and
> >NutTimerProcessElapsed.
> >
> >I am interested to hear if these patches improve the issues you are
> >observing as well.
> >
> >
> >Best Regards
> >
> >Henrik Maier
> >
> >--
> >proconX - Protocol Converter, Device Server and Industrial Gateways
> >http://www.proconx.com  Tel: +61-7-3376 3911   Fax: +61-7-3102 9206




_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion