TCP Connection takes approx 250ms to get client.available() response on Teensy 4.1

[mantisrobot]

Hi, I've recently converted some hardware from Teensy 4.0 with Wiznet device to the Teensy 4.1 with built in Ethernet.

Ive ported my code to QNEthernet and its running, however the TCP connection I use only seems to get updates to client.available() every 250ms or so regardless how fast my client polls the Teensy server. This wasn't the case on the old Teensy 4 hardware setup.

I also have UDP sockets running and the response is as fast as my origonal Teensy 4 / wiznet setup.

I tried adding Ethernet.loop() / yield() to my loop but this made no difference., and according to docs shouldn't be needed. Here is some timing with clinet.avaialble() followed by client.read() called within a continuous loop.

available() = 14, 36.806 mS
read() = 14, 36.806 mS
available() = 14, 37.047 mS
read() = 14, 37.047 mS
available() = 14, 37.304 mS
read() = 14, 37.304 mS
available() = 14, 37.547 mS
read() = 14, 37.547 mS

Any thoughts?

[ssilverman]

Hi, Matt. Thanks for using the QNEthernet library. It’s likely that data is getting buffered and not being sent right away. Note that I’m assuming that you’re expecting a response to data being sent out the connection. This section of the Readme may help: https://github.com/ssilverman/QNEthernet/blob/master/README.md#write-immediacy

Try calling flush() after sending data that needs to be immediately sent.

[mantisrobot]

Hi, Thanks for the fast response!

Yes you are correct and I had just found this in another post! so it was the server reply write() that was holding things up. I am now tetsing with flush() and the QNETHERNET_FLUSH_AFTER_WRITE option. Yes I need an imediate response as its a UI interface.

Thanks!

[ssilverman]

I’m going to suggest using flush() instead of the QNETHERNET_FLUSH_AFTER_WRITE option. If you have the option set then all writes are immediate and you don’t need flush(). Setting that option is not preferred because it’s often the case that TCP buffering is desired. Using flush() gives more control when you do want buffering. The option approach is a hack for libraries that can’t be changed.

[mantisrobot]

Hi,

Yes I have updated the code to use flush() and its working much better now, howver I noticed there was still some latency when compared to my older Wiznet hardware. I found that I also had to switch off Nagle in order to get back to the fill low latency interfcae I had before. So to summerise I now have:

Switch off nagle on new clinet connect using:
client.setNoDelay(true);

In my tcpSendAll() routine:
client.write();
client.flush();

Thanks for the help.

[ssilverman]

Great! I'm glad you got it working.