In case of board I was working with, the network traffic was handled by low priority work queue. It is probably the same with your network driver.
Such work queue has configuration. Maybe you need to change some parameters of it. It might help if you send here your configuration file, or part of it. On Mon, 9 Nov 2020, 13:55 Andrey Shetov, <ashe...@gmail.com> wrote: > Hi, Jukka. > > I'm working with the thread author on a low latency audio processor based > on the STM32H7 chip and can provide some technical details about the issue. > We've used Ethernet config from your repo bitbucket.org/jlaitin/nuttx/ and > integrated it to master branch of Nuttx OS. After that, we've ported > CONFIG_SCHED_CRITMONITOR functionality into H7 platform and have > measured sending and receiving time of UDP packets by inserting bunch of > tracepoints into the driver. Results are little strange - packet receiving > is OK, but actual time of packet _sending_ at 100Mbit/s is about 200 usec. > By "actual time" I mean delay between sendto() and stm32_txdone() > functions. > > For now we are looking the reasons of such delay and ways to reduce it, any > help will be much appreciated. > PS We've already tried to use raw (packet) socket, it reduces the delay a > little, but not significant. > > -> sendto_start_time: 0 usec > stm32_dopoll: 58 usec > stm32_transmit: 93 usec > -> sendto_done_time: 120 usec > stm32_interrupt: 186 usec > ETH_DMACSR_TI: 187 usec > stm32_interrupt_work: 205 usec > stm32_txdone: 207 usec > > > On Sat, Nov 7, 2020 at 8:29 AM Jukka Laitinen <jukka.laiti...@iki.fi> > wrote: > > > Hi, > > > > I am not quite sure about from where you measured (and what is your phy > > config), but sending out 1000 bytes will take in theory about 800+ us at > > 10Mbps and 80+ us at 100Mbps, so you probably wouldn't want it to be > > synchronous (you'd like to be able to receive in full duplex at the same > > time when transmit happens). The ethernet driver uses the stm32h7 eth > > block's internal dma for sending. Other ethernet traffic, hubs, switches, > > the network cards.. may cause additional delays. > > > > Handling the interrupt should be fast, but the actual completion happens > > in your thread (waking up from mutex), so this can be delayed by some > > higher priority thread running in your system. > > > > - Jukka > > > > > > S D kirjoitti tiistai 3. marraskuuta 2020: > > > Hello! > > > could you please help a nuttx newbie. > > > I'm using a stm32h7 for my project > > > I'm trying to communicate with "big" Linux machine via direct ethernet > > (UDP), and I see relatively big delays for outgoing packets (with a 1000 > > bytes payload). > > > I see that sendto is executed in about 120usecs, but the actual > transmit > > is seems to be executed much later, and I see the actual transmit > > completion (interrupt) in about 100 more usecs later after return from > > sendto call. > > > > > > I spent a few days reading stm32_ethernet.c driver (and all the other > > stuff it works with) and it seems the system is heavily asynchronous. > > > Could you please tell, Is there a way to send/receive data > > immediately/synchronous if all I need a direct Ethernet connection to > > another device (may be even with raw ethernet frames) ? > > > > > > Thanks! > > > >
