So I'm trying to send some 59 byte binary messages over TCP at between 100 and 1000hz. Eventually this will read an accelerometer/gyro at this rate and send the results over the network. For now I'm having issues with timing so I put together a quick test program using the tcpserver.c example. When someone connects to it I have it setup to start sending packets back at a fixed rate. This seems to be working but the tcp send call frequently stalls for as much as 2ms when I call it. Most of the time it's as low as 50us.
I have the socket setup in non blocking mode with :
err = fcntl (sock, F_SETFL , O_NONBLOCK );
and for good measure I do the send call with:
err = send(sock, tempbuf, tempbuflen, MSG_DONTWAIT );
I time the calls by checking esp_timer_get_time() on either side of the "send". I put the time required for the send call in the next outgoing message, so nothing is being printed to the console. I am NOT getting any EWOULDBLOCK/EAGAIN errors.
I'm wondering if I've missed some configuration thing here, on most systems I've done something like this on the send returns right away with either success or EWOULDBLOCK but doesn't stall for a significant amount of time.
Is there something I've missed here? Maybe freeRTOS is occasionally taking the send call as an opportunity to sleep my task for a ms? I have the tickcount set to 1000hz and do a vTaskDelay of between 1 and 10 at the top of every loop.
Do non-blocking TCP send calls work?
Re: Do non-blocking TCP send calls work?
I'm using non-blocking sockets exclusively.
Setting non-blocking mode:
https://github.com/PerMalmberg/Smooth/b ... et.cpp#L40
My send-call:
https://github.com/PerMalmberg/Smooth/b ... ket.h#L358
(for anyone reading this in a week or two, the above links goes to a feature branch so they may be 404 by then, see same files in master branch)
Setting non-blocking mode:
https://github.com/PerMalmberg/Smooth/b ... et.cpp#L40
My send-call:
https://github.com/PerMalmberg/Smooth/b ... ket.h#L358
(for anyone reading this in a week or two, the above links goes to a feature branch so they may be 404 by then, see same files in master branch)
Who is online
Users browsing this forum: No registered users and 111 guests