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

[Wolfgang Rostek]

...
> 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.
Thanks for all your explanations. Of course I've to learn and dig deeper
into it.

Like to give you a bit of the background.

I've experienced different problems when raising msg speed or other 
traffic
on the network. Unfortunatly not possible to establish a reproducable
test case. All I see was a kind of congestion starting by retransmit
TCP packages and reducing window size. In the end sender or receiver
hangs.

To see if my network.c driver stuff is working I've added in-memory
trace to track the function flow. I was looking if my low level
ethernet parts have problems (interrupt, dma buffer mgmt,...) or
something else is going wrong. For now I could not detect problems
on this lower level.

So I assume timing problems. The delayed TCP ack could be removed
to see if things get better. Another option I have is to increase
the clock speed. From 10 ms to 100 us as discussed in another thread
yesterday. Maybe this will change the behaviour as well.

But then I really have to start understanding what's going on ;)

regards
Wolfgang R.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20100609/6135372e/attachment.html>