Antwort: Re: configure ACK delay for TCP

[Wolfgang Rostek]

Hi Eric

Eric Norum <wenorum at lbl.gov> schrieb am 08.06.2010 17:42:17:
...
> I don't understand what you're suggesting.   The event is sent by 
> the interrupt handler when a packet is received.   If no packet has 
> been received I don't see any advantage in waking up the receive 
> thread after every clock tick. 
> 
> Which driver in particular are you describing?
> 
c/src/lib/libbsp/m68k/genmcf548x/network/network.c

I've added traces to network.c and try to align to the network analyser
output. 192.168.18.135 is the RTEMS socket server and 192.168.18.47 the
client sending 200 bytes every 50 ms (aggregated to longer frames on the
client side)

>From line 15 to 16 you see 200ms ACK delay. Frame 17 is not immediately
ack'ed but after frame 18. This is a working transfer but only to show
the ACK delay.

...
     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
     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
     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 TSER=44
     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 
TSER=44
     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

The following lines show
  <frame> ###### <clock count [10 ms]>
and the functions entered

16 #################################  0C34
mcf548x_fec_txDaemon ()
mcf548x_fec_sendpacket ()
mcf548x_fec_txDaemon ()

17 #################################  0C34
mcf548x_mcdma_rx_irq_handler ()
mcf548x_fec_rxDaemon ()

18 #################################  0C3C
mcf548x_mcdma_rx_irq_handler ()
mcf548x_fec_rxDaemon ()

19 #################################  0C3C
mcf548x_fec_txDaemon (0xb...)
mcf548x_fec_sendpacket (0xa...)
mcf548x_fec_txDaemon (0xb...)
mcf548x_mcdma_tx_irq_handler(0x7...)
mcf548x_fec_txDaemon (0xb...)


Within 

17 #################################  0C34
...
mcf548x_fec_rxDaemon ()

I see as the last statement executed the call to 

  rtems_bsdnet_event_receive (INTERRUPT_EVENT | FATAL_INT_EVENT,
 RTEMS_WAIT | RTEMS_EVENT_ANY,
 RTEMS_NO_TIMEOUT, &events);

not triggering an ACK response of the TCP stack. This is triggered
by frame 18 later.

I've got the hint from Thomas to use the socket options to force an 
immediate ACK. 


regards
Wolfgang R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100608/7795a0d2/attachment-0001.html>