<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 8, 2010, at 11:15 AM, Wolfgang Rostek wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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> </blockquote><div><br></div>I'm afraid that your understanding is a little off.</div><div><br></div><div>The rtems_bsdnet_event_receive routine simply blocks waiting for the interrupt handler to send the event that indicates that a packet has arrived. The receive thread then passes the packet up to the rest of the network stack for further processing (and ultimately acknowledgement).</div><div>This is why I say that you really do not want to change the arguments to the rtems_bsdnet_event_receive routine since doing so will merely make the receive thread poll for packet arrival instead of blocking and waiting for an interrupt to occur.</div><div><br><blockquote type="cite">
<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></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div>-- <br>Eric Norum<br><a href="mailto:wenorum@lbl.gov">wenorum@lbl.gov</a></div></span>
</div>
<br></body></html>