Antwort: Re: configure ACK delay for TCP

[Eric Norum]

On Jun 8, 2010, at 9:21 AM, Wolfgang Rostek wrote:

> 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 
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?

>      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
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.

> 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
And it got awoken by the arrival of the above packet, too.

> 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); 

Right -- and it appears the it returns from this function whenever a packet is received.  

> 
> 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.   
> 


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.
-- 
Eric Norum
wenorum at lbl.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100608/19672eee/attachment-0001.html>