Simon, I'm using the raw api with a lwIP/FreeRTOS port. In my project no netconn or socket API is being used. The tcpip_callback() is definitely the way to go for my application.
Thanks for all the help, Andrew -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Friday, November 12, 2010 09:16 To: Mailing list for lwIP users Subject: Re: [lwip-users] Minimizing TCP send delay with RAW api and multi-threading. Am I assuming correct that you are using the raw api with your own threading-mechanisms instead of using the netcon- or socekt API? If so, you don't have to wait for your poll callback to be called: you can always try to send more data from the sent- or recv- callback. And if you need to to do something in an application thread then, use tcpip_callback() to get back into tcpip_thread directly - no waiting for poll necessary. Simon Andrew Foster wrote: > Kieran, > > I apologize, I mixed some verbiage in my description. I'm asking how to > minimize the delay from application data being ready, to the start of a > new TCP transmission. > > My understanding is that I cannot call a tcp_write from other threads. I > think that means that I would have to wait until the tcpip_thread polls > my application to initiate a tcp_write and tcp_output. > > Maybe I'm going about this the wrong way. Could I just add a sys_timeout > to poll my application at a faster rate? This would ensure that the > tcp_write/output happens in context of the tcpip_thread. > > Thanks, > > Andrew > > -----Original Message----- > From: Kieran Mansley [mailto:[email protected]] > Sent: Friday, November 12, 2010 04:11 > To: Mailing list for lwIP users > Subject: Re: [lwip-users] Minimizing TCP send delay with RAW api and > multi-threading. > > On Thu, 2010-11-11 at 15:49 -0500, Andrew Foster wrote: >> Hello All, >> >> >> >> Are there any safe tricks to get TCP data sent faster from a non >> tcpip_thread? Since the RAW api is not safe for concurrent access, it >> seems the delay will always be a factor of the tcp_tmr intervals >> (fast&slow). With that in mind, the only way to reduce the delay is to >> adjust these tmr values to get the TCP_EVENT_POLL to happen more >> frequently. > I don't follow how the timer delays will affect the speed of data being > sent. The timers are only really involved in this path for > retransmissions. > > Kieran > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
