Re: SD and eMMC performance in Nuttx
Hi Nathan, Thanks for the reply. The round-robin interval was set to 200ms and reducing it down to 10 marginally improved the transfer speed. Our current code base and dev board is running a slightly quicker clock than what I used when I measured 75KiB/s, and the current setup is transferring at 100KiB/s with a RR interval of 200 and this increases to 135KiB/s with a RR interval of 10ms. Yes I do have access to an oscilloscope and logic analyzer so will endeavour to obtain some traces tomorrow to rule in/out possible unexpected delays and/or noise. *Kind regards,* *Radek Pesina* On Wed, 31 May 2023 at 11:33, Nathan Hartman wrote: > On Tue, May 30, 2023 at 8:07 PM Radek Pesina > wrote: > > (snip) > > *Configurations Tested:* > > > > For eMMC, I've tried optimising the menuconfig settings to improve it, > > including options such as below. However, the performance remains > > lacking: > > > >- Turning on CONFIG_MEMCPY_VIK gave slight improvement > >- Setting USEC_PER_TICK to 1000 or below gave most improvement, > however > >at the detriment of other aspects of the system. The fastest speeds > >observed by adjusting this was ~370KiB/s write and 700KiB/s read > though > >overall this was unacceptable given the effect on the rest of the > > system. > >- Adjusting LittleFS parameters (e.g. > >CONFIG_FS_LITTLEFS_PROGRAM_SIZE_FACTOR, > >CONFIG_FS_LITTLEFS_READ_SIZE_FACTOR, > > CONFIG_FS_LITTLEFS_BLOCK_SIZE_FACTOR, > >CONFIG_FS_LITTLEFS_CACHE_SIZE_FACTOR, > CONFIG_FS_LITTLEFS_LOOKAHEAD_SIZE > >- Ensuring SD/eMMC DMA read/writes are enabled. > >- Setting MMCSD_MULTIBLOCK_LIMIT to 0 > > > > (snip) > > Out of curiosity, what is the value of CONFIG_RR_INTERVAL, and, if you > reduce it to something like 20 or 10, does that show any improvement? > > Do you have an oscilloscope or logic analyzer available to monitor the > signals between the microcontroller and MMC? That might shed additional > light on this. E.g., extremely noisy signals, intermittent signals, > unexpectedly long delays between bursts of communication, etc. > > Nathan >
Re: CI tests (was: Re: [OT] Learning Makefiles)
On Mon, May 29, 2023 at 2:41 AM Michael Gielda wrote: > > Haha, no worries, just subscribed on Friday for this particular reason :) > glad Renode was useful for EOS S3 and of course happy to see how we can > enable more of that. > > > You mention you have a CI generating all the elfs, could you point me to > where that can be found? We could grab those and try to run them, see what > happens. > > There is a giant bundle of the build artifacts that can be downloaded here under linux-builds https://github.com/apache/nuttx/actions/runs/5128284656 https://github.com/apache/nuttx/suites/13258933442/artifacts/723073966 For example there should be a stm32f4discovery/nsh with a nuttx.elf which would be a small shell build for that board. >From what I remember a few years ago was that I had to sub out some clock and power related code to allow the target to boot, but I have not tried in at least a year. --Brennan
Re: SD and eMMC performance in Nuttx
On Wed, May 31, 2023 at 3:11 AM Radek Pesina wrote: > Hi Nathan, > > Thanks for the reply. The round-robin interval was set to 200ms and > reducing it down to 10 marginally improved the transfer speed. Our current > code base and dev board is running a slightly quicker clock than what I > used when I measured 75KiB/s, and the current setup is transferring at > 100KiB/s with a RR interval of 200 and this increases to 135KiB/s with a RR > interval of 10ms. This leads me to think that there are several threads of same priority competing for CPU time together with the thread that is transferring the information. When the round robin time was 200ms, the transfer thread would be made to wait up to 1/5th of a second per other thread of same priority with which it was competing. (I say "up to" because those other threads could voluntarily sleep or block waiting on other things.) You could try raising the priority of the thread in question, but test carefully because a higher priority thread will block lower priorities from running. Maybe you want that, maybe not. Maybe you want that only during startup. It sounds like performance still isn't where you need it, so besides priorities there may be additional factors contributing. Perhaps some other threads are running needlessly and should explicitly relinquish CPU time? Hopefully a good fix won't require major rework... Yes I do have access to an oscilloscope and logic analyzer so will > endeavour to obtain some traces tomorrow to rule in/out possible unexpected > delays and/or noise. Great! Hope this helps... Nathan
Re: Thank you!
Kudos and looking forward to seeing pictures and videos! Thank you! пт, 26 трав. 2023 р. о 20:54 Tim Hardisty пише: > I have been tinkering with a blog/AboutMe thingy, also using it as a way > to learn markdown. Although I've not updated it for a short while, I > decided to add it to my GitHub profile if anyone is at all interested: > > https://github.com/TimJTi > > > > >
