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

[Wolfgang Rostek]

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


...
>>   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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100608/78f593dd/attachment.html>