lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Minimizing TCP send delay with RAW api and multi-thread


From: address@hidden
Subject: Re: [lwip-users] Minimizing TCP send delay with RAW api and multi-threading.
Date: Fri, 12 Nov 2010 15:16:28 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

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:address@hidden
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
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users





reply via email to

[Prev in Thread] Current Thread [Next in Thread]