apache
Networking 1s Send Delay and SO_SNDTIMEO odd behavior
we are using Nuttx 9.1.0 as host OS on our Robot Control Boards using STM32H7, and we are seeing an odd behavior when communicating with our main board that is running Linux.
Every once in a while, we see a more than a 1 second delay when we call Socket::Send to send information to the Main board. Using Debug Statement, I confirmed that we are calling Socket::Send in a timely manner. Also. by using WireShark, I can confirm that the message does not get sent out until more than a 1 second later.
Strangely, after adding an option to the socket for a 300ms send Delay "SO_SNDTIMEO", we don't see the Delay in communication anymore.
Why would adding "SO_SNDTIMEO" remove the once in a while delay we were seeing?
tcpsend_eventhandler is the callback on state that actually sends the data to dev:
/* Then set-up to send that amount of data. (**this won't actually
* happen until the polling cycle completes**).
*/
devif_send(dev, &pstate->snd_buffer[pstate->snd_sent], sndlen);
Once state.send_cb->event call back is set to above, next thing is to notify the device driver and then wait for semaphore state.snd_sem.
/* Notify the device driver of the availability of TX data */
send_txnotify(psock, conn);
These are all disconnected (or so they seem) and some how changing s_sndtimeo to anything other than UINT_MAX below "fixes" the problem.
ret = net_timedwait(&state.snd_sem,
_SO_TIMEOUT(psock->s_sndtimeo));
if (ret != -ETIMEDOUT || acked == state.snd_acked)
{
break; /* Timeout without any progress */
}
Seems like tcpsend_eventhandler gets called with TCP_NEWDATA flag set sooner or polling cycle completes sooner if the send timeout is not UINT_MAX.
But UINT_MAX only impacts wait on semaphore and we never see a timeout error also (even at 100ms timeout). So semaphore does get set!
Could it be that since we do timeout, e.g. 100ms, _net_timedwait exits and return to for loop to run net_timedwait again but during this time the sched_unlock and leave_critical_section is called in _net_timedwait which allows other tasks to run allowing tcp_send_eventhandler being called sooner?
Should scheduler be locked and IRQs be disabled in _net_timedwait?
Maybe you can try enable CONFIG_NET_ARP_SEND=y and check further if that helps
@HakeemG @mraja-brooks please also test a recent version with the https://github.com/apache/nuttx/pull/10536 that seems to fix similar issue for @SimonFilgis
@acassis I cherry picked the changes in #10536 but unfortunately with no luck in fixing my issue.
Hi Hakeem,
And are you in write-through mode: CONFIG_ARMV7M_DCACHE_WRITETHROUGH
make menuconfig...
Simon
-- Hard- and Softwaredevelopment Consultant Ingenieurbüro-Filgis USt-IdNr.: DE305343278
On Thu, Nov 30, 2023 at 6:39 PM Hakeem Giydan @.***> wrote:
@acassis https://github.com/acassis I cherry picked the changes in #10536 https://github.com/apache/nuttx/pull/10536 but unfortunately with no luck in fixing my issue.
— Reply to this email directly, view it on GitHub https://github.com/apache/nuttx/issues/11292#issuecomment-1834255049, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATU5PMRRMNGFEF342BEFZ3LYHDAEPAVCNFSM6AAAAABAAEHGOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZUGI2TKMBUHE . You are receiving this because you were mentioned.Message ID: @.***>
