On Wed, May 31, 2023 at 3:11 AM Radek Pesina <radek.pes...@motec.com.au> 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
