-->
Page 1 of 4

Latency with WifiClient.print()

PostPosted: Wed Apr 22, 2015 4:53 pm
by martinayotte
Is there any news about the latency found with WifiClient.print() ?
I've started some kind of TCP2Serial transparent bridge, and this latency is causing problems.
Thanks in advance,

Re: Latency with WifiClient.print()

PostPosted: Wed Apr 22, 2015 10:19 pm
by Chris--A
Use WifiClient.write( buffer, length ); where possible!!

.write( buff, len ) sends a buffer using tcp_write().

.print/ln() eventually call .write() with a single character, which basically means, 1 character per tcp_write() call.

Calling .write() with a large buffer directly should dramatically improve performance especially if tcp_write() is blocking while a packet is sent.

This is not a bug, but more of a consequence of using a library meant for generalized communication. WifiClient inherits Client which inherits Stream which inherits Print. It is a virtual nightmare for efficiency, but it works!

Calling .write() allows you to call the most derived implementation directly.

Re: Latency with WifiClient.print()

PostPosted: Thu Apr 23, 2015 2:43 pm
by martinayotte
I understand the efficiency differences between .write() and .print() and all those Stream/Print I/Os, so I've changed my code to used .write() instead. But still, the issue I means here, why we have 150ms latency for every packet sent.
Like I've mentionned in another thread, IPAddress.printTo() is taking 1 sec to print.
So yes, I've worked around it by adding IPAddress.toCharArray() and then sending it as a single print().
The problem still, especially in a TCP2Serial scenario, or even for those who wish to send files over TCP, this kind latency is simply not acceptable. Currently, my TCP2Serial prototype, which inputs at 115200Kb, look more like a 9600bps on the TCP side. :(

Re: Latency with WifiClient.print()

PostPosted: Thu Apr 23, 2015 8:20 pm
by Chris--A
The reason I posted, is because of this:

https://github.com/esp8266/Arduino/blob ... ext.h#L173

I'd assume that your latency is far greater than 150ms. Maybe you could try replacing the delay with tcp_output( _pcb );