Hi Hakeem, Thank you very much for opening this issue.
I saw you are using a pretty old NuttX version, did you try with recent version that has the solution pointed by Simon that could fix this issue? Best Regards, Alan On 11/29/23, Giydan, Hakeem <hakeem.giy...@brooks.com> wrote: > Hello Alan, > > Thank you for your reply, I have opened a new issue in github. You can find > it here: https://github.com/apache/nuttx/issues/11292 > > best, > Hakeem > > > > ________________________________ > From: Raja, Mayank <mayank.r...@brooksautomation.com> > Sent: Tuesday, November 28, 2023 10:21 AM > To: Giydan, Hakeem <hakeem.giy...@brooksautomation.com> > Subject: FW: Networking Delay: SO_SNDTIMEO odd behavior > > > > -----Original Message----- > From: Alan C. Assis <acas...@gmail.com> > Sent: Tuesday, November 28, 2023 12:58 AM > To: dev@nuttx.apache.org > Cc: Raja, Mayank <mayank.r...@brooksautomation.com> > Subject: Re: Networking Delay: SO_SNDTIMEO odd behavior > > [External Email] > > Hi Hakeem, > > Thank you very much for reporting an issue your team found. > > Could you please open an issue with more information at > https://github.com/apache/nuttx/issues and supply a little bit more > information (board/mcu used, version of NuttX, host OS, etc). > > Please also supply your board config (run "make savedefconfig" and attach > the defconfig generated). > > I think probably some higher priority thread/task is getting all CPU for > some time. > > If you are using an ARM MCU then you can use Segger SystemView (enable the > RTT driver on NuttX) to see what is happening when that 1s delay. > We don't have an official documentation about it yet, but this discussion > here could help: > https://github.com/apache/nuttx/issues/10556 > > Alternatively if you can use an all open-source solution, you can use > ORBTrace as explained here: > https://www.youtube.com/watch?v=_k1f4F2JVBA > > Best Regards, > > Alan > > On 11/27/23, Giydan, Hakeem <hakeem.giy...@brooks.com> wrote: >> Hello, >> >> we are using Nuttx on our Robot Control Boards, 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. Also >> Strangely, we reduce the timeout to 1us and we don't see any timeout >> happening in the socket. >> >> >> Why would adding "SO_SNDTIMEO" remove the once in a while delay we >> were seeing and why after setting the timeout to 1us we are not seeing >> the timeout error? >> >> best, >> Hakeem >> >> >> _____________________________________________________________________ >> >> This email message, including any attachments, may contain >> confidential and proprietary information for the sole use of the >> intended recipient. If you are not the intended recipient, please >> notify the sender and delete this message from your system, without >> making any copy or distribution. Our website and email privacy policy >> is available at https://www.brooks.com/privacy >> > _____________________________________________________________________ > > This email message, including any attachments, may contain confidential and > proprietary information for the sole use of the intended recipient. If you > are not the intended recipient, please notify the sender and delete this > message from your system, without making any copy or distribution. Our > website and email privacy policy is available at > https://www.brooks.com/privacy >
