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

Wolfgang Rostek Wolfgang.Rostek at
Wed Jun 9 06:43:24 UTC 2010

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

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

Wolfgang R.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list