Antwort: Re: Antwort: Re: configure ACK delay for TCP

[Eric Norum]

On Jun 8, 2010, at 11:15 AM, Wolfgang Rostek wrote:

> ...
> >>      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? 
> I don't have line '15' handling on file but it was identical to '17' 
> as described before. 
> 
> As far as I understand is the call to rtems_bsdnet_event_receive() a kind 
> of announcing an event. The next time clock or other interrupts invoke 
> the 'schedular' it dispatches these events to awaiting apps like the TCP 
> state machine. Per default this machine has a 200 ms ACK delay and it will 
> wait for several clock ticks until ACK is generated and send. 
> (I hope I'm not totally wrong here) 

I'm afraid that your understanding is a little off.

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

> 
> 
> ...
> >>   rtems_bsdnet_event_receive (INTERRUPT_EVENT | FATAL_INT_EVENT,
> ..
> > Right -- and it appears the it returns from this function whenever a
> > packet is received.   
> Until now I did analyse network.c and have only a rough idea what's going 
> on beyong this call. 
> 
> ...
> >> 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. 
> Any idea where this default ACK delay value is defined (200 ms)? No 
> easy way to figure it out within the TCP/BSD stuff. 
> 
> regards 
> Wolfgang R.  

-- 
Eric Norum
wenorum at lbl.gov

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