<tt><font size=2>...<br>
>>      15 30.098174   192.168.18.47    
    192.168.18.135        TCP <br>
>> 50569 > 5477 [PSH, ACK] Seq=2201 Ack=1 Win=5856 Len=800 TSV=23499477
TSER=43 </font></tt>
<br><tt><font size=2>> Did the receive thread not get awoken by the
arrival of the above <br>
> packet?  There's no indication in the frame/clock lines below.
 Was <br>
> there a line '15' that you did not include in the messaget?</font></tt>
<br><tt><font size=2>I don't have line '15' handling on file but it was
identical to '17'</font></tt>
<br><tt><font size=2>as described before. </font></tt>
<br>
<br><tt><font size=2>As far as I understand is the call to rtems_bsdnet_event_receive()
a kind</font></tt>
<br><tt><font size=2>of announcing an event. The next time clock or other
interrupts invoke</font></tt>
<br><tt><font size=2>the 'schedular' it dispatches these events to awaiting
apps like the TCP</font></tt>
<br><tt><font size=2>state machine. Per default this machine has a 200
ms ACK delay and it will</font></tt>
<br><tt><font size=2>wait for several clock ticks until ACK is generated
and send.</font></tt>
<br><tt><font size=2>(I hope I'm not totally wrong here)</font></tt>
<br>
<br>
<br><tt><font size=2>...<br>
>>   rtems_bsdnet_event_receive (INTERRUPT_EVENT | FATAL_INT_EVENT,<br>
..<br>
> Right -- and it appears the it returns from this function whenever
a<br>
> packet is received.  </font></tt>
<br><tt><font size=2>Until now I did analyse network.c and have only a
rough idea what's going</font></tt>
<br><tt><font size=2>on beyong this call.</font></tt>
<br>
<br><tt><font size=2>...<br>
>> I've got the hint from Thomas to use the socket options to force
an <br>
>> immediate ACK.   <br>
</font></tt>
<br><tt><font size=2>> <br>
> Yes, I would say that the delay is coming from somewhere else other
<br>
> than the receive thread since that thread appears to be responding
<br>
> to the interrupts caused by arriving packets as it should.  I
think <br>
> that it would be a very bad idea to turn the receive thread from <br>
> being interrupt driven as it is now to instead be polling which it
<br>
> would become if your patch were applied.</font></tt>
<br><tt><font size=2>Any idea where this default ACK delay value is defined
(200 ms)? No</font></tt>
<br><tt><font size=2>easy way to figure it out within the TCP/BSD stuff.</font></tt>
<br>
<br><tt><font size=2>regards</font></tt>
<br><tt><font size=2>Wolfgang R.  </font></tt>