<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jun 8, 2010, at 9:21 AM, Wolfgang Rostek wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><font size="2" face="sans-serif">Hi Eric</font>
<br>
<br><tt><font size="2">Eric Norum <<a href="mailto:wenorum@lbl.gov">wenorum@lbl.gov</a>> schrieb am 08.06.2010
17:42:17:<br>
...<br>
> I don't understand what you're suggesting. The event is sent
by <br>
> the interrupt handler when a packet is received. If no packet
has <br>
> been received I don't see any advantage in waking up the receive <br>
> thread after every clock tick. </font></tt>
<br><tt><font size="2">> <br>
> Which driver in particular are you describing?</font></tt>
<br><tt><font size="2">> <br>
c/src/lib/libbsp/m68k/genmcf548x/network/network.c</font></tt>
<br>
<br><tt><font size="2">I've added traces to network.c and try to align to
the network analyser</font></tt>
<br><tt><font size="2">output. 192.168.18.135 is the RTEMS socket server
and 192.168.18.47 the</font></tt>
<br><tt><font size="2">client sending 200 bytes every 50 ms (aggregated to
longer frames on the</font></tt>
<br><tt><font size="2">client side)</font></tt>
<br>
<br><tt><font size="2">From line 15 to 16 you see 200ms ACK delay. Frame
17 is not immediately</font></tt>
<br><tt><font size="2">ack'ed but after frame 18. This is a working transfer
but only to show</font></tt>
<br><tt><font size="2">the ACK delay.</font></tt>
<br>
<br><tt><font size="2">...</font></tt>
<br><tt><font size="2"> 15 30.098174 192.168.18.47
192.168.18.135 TCP
50569 > 5477 [PSH, ACK] Seq=2201 Ack=1 Win=5856
Len=800 TSV=23499477 TSER=43</font></tt>
<br></blockquote><div>Did the receive thread not get awoken by the arrival of the above packet? There's no indication in the frame/clock lines below. Was there a line '15' that you did not include in the messaget?</div></div><div><br><blockquote type="cite"><tt><font size="2"> 16 30.297928 192.168.18.135
192.168.18.47 TCP
5477 > 50569 [ACK] Seq=1 Ack=3001 Win=17376 Len=0
TSV=44 TSER=23499477</font></tt>
<br><tt><font size="2"> 17 30.298158 192.168.18.47
192.168.18.135 TCP
50569 > 5477 [PSH, ACK] Seq=3001 Ack=1 Win=5856
Len=800 TSV=23499527 </font></tt></blockquote>From what I see in the frame/clock lines below, the receive thread did get awoken by the arrival of the above packet -- as it should.</div><div><br><blockquote type="cite"><tt><font size="2">TSER=44</font></tt>
<br><tt><font size="2"> 18 30.378088 192.168.18.47
192.168.18.135 TCP
50569 > 5477 [FIN, PSH, ACK] Seq=3801 Ack=1 Win=5856
Len=200 TSV=23499547 </font></tt></blockquote>And it got awoken by the arrival of the above packet, too.</div><div><br><blockquote type="cite"><tt><font size="2">TSER=44</font></tt>
<br><tt><font size="2"> 19 30.378301 192.168.18.135
192.168.18.47 TCP
5477 > 50569 [ACK] Seq=1 Ack=4002 Win=17176 Len=0
TSV=44 TSER=23499527</font></tt>
<br>
<br><tt><font size="2">The following lines show</font></tt>
<br><tt><font size="2"> <frame> ###### <clock count [10 ms]></font></tt>
<br><tt><font size="2">and the functions entered</font></tt>
<br>
<br><font size="2" face="sans-serif">16 #################################
0C34<br>
mcf548x_fec_txDaemon ()<br>
mcf548x_fec_sendpacket ()<br>
mcf548x_fec_txDaemon ()<br>
<br>
17 ################################# 0C34<br>
mcf548x_mcdma_rx_irq_handler ()<br>
mcf548x_fec_rxDaemon ()<br>
<br>
18 ################################# 0C3C<br>
mcf548x_mcdma_rx_irq_handler ()<br>
mcf548x_fec_rxDaemon ()</font>
<br><font size="2" face="sans-serif"><br>
19 ################################# 0C3C<br>
mcf548x_fec_txDaemon (0xb...)<br>
mcf548x_fec_sendpacket (0xa...)<br>
mcf548x_fec_txDaemon (0xb...)<br>
mcf548x_mcdma_tx_irq_handler(0x7...)<br>
mcf548x_fec_txDaemon (0xb...)<br>
</font>
<br>
<br><tt><font size="2">Within </font></tt>
<br>
<br><font size="2" face="sans-serif">17 #################################
0C34</font>
<br><font size="2" face="sans-serif">...<br>
mcf548x_fec_rxDaemon ()</font>
<br>
<br><font size="2" face="sans-serif">I see as the last statement executed
the call to </font>
<br>
<br><tt><font size="3"> rtems_bsdnet_event_receive (INTERRUPT_EVENT
| FATAL_INT_EVENT,<br>
RTEMS_WAIT
| RTEMS_EVENT_ANY,<br>
RTEMS_NO_TIMEOUT,
&events);</font></tt>
<br></blockquote><div><br></div>Right -- and it appears the it returns from this function whenever a packet is received. </div><div><br><blockquote type="cite">
<br><tt><font size="3">not triggering an ACK response of the TCP stack. This
is triggered</font></tt>
<br><tt><font size="3">by frame 18 later.<br>
</font></tt>
<br><tt><font size="2">I've got the hint from Thomas to use the socket options
to force an immediate ACK. </font></tt>
<br>
<font class="Apple-style-span" face="monospace"><span class="Apple-style-span" style="font-size: small;"><br></span></font></blockquote></div><div><br></div>Yes, I would say that the delay is coming from somewhere else other than the receive thread since that thread appears to be responding to the interrupts caused by arriving packets as it should. I think that it would be a very bad idea to turn the receive thread from being interrupt driven as it is now to instead be polling which it would become if your patch were applied.<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>