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

[Thomas Doerfler]

Hello,

Am 08.06.2010 20:15, 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)

You are (slightly) wrong here: This function call makes the current
(Ethernet rx) task wait/sleep, until at least one of the following
conditions is true:

- the specified timeout expires (which will never happen due to "NO_TIMEOUT"

or

- one of the specified events occurs.

The major event the task is waiting for is an event coming from the rx
interrupt routine, which get active, whenever one or more packets have
been received. The main purpose of this task is to push the received
packets into the networking stack ethernet receive queue, where incoming
packets are processed as soon as possible.

What you are missing is the __response__ to a received packet, and this
will be generated in the networking stack according to rather
complicated decisions (to avoid unneeded traffic).

wkr,
Thomas.


> 
> 
> ...
>>>   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.  
> 
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 

--------------------------------------------
embedded brains GmbH
Thomas Doerfler        Obere Lagerstrasse 30
D-82178 Puchheim       Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9
PGP:   Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.