Hi, I've been busy on other tasks therefore haven't obtained a oscilloscope trace yet, but one of my peers have performed some profiling on a different micro and non-secure core, with the mxrt1064-evk:nsh configuration + tickless and 100us tick rate:
nsh> dd if=/dev/zero of=/dev/null bs=4096 count=100 409600 bytes copied, 2200 usec, 181818 KB/s nsh> mkrd -m 1 -s 512 1024 nsh> mkfatfs /dev/ram1 nsh> mount -t vfat /dev/ram1 /mnt nsh> dd if=/dev/zero of=/dev/null bs=4096 count=100 409600 bytes copied, 2200 usec, 181818 KB/s nsh> dd if=/dev/zero of=/mnt/t bs=4096 count=100 409600 bytes copied, 4700 usec, 85106 KB/s nsh> umount /mnt nsh> mkfatfs /dev/mmcsd0 nsh> mount -t vfat /dev/mmcsd0 /mnt nsh> dd if=/dev/zero of=/mnt/t bs=4096 count=100 409600 bytes copied, 959000 usec, 417 KB/s nsh> dd if=/dev/zero of=/dev/sd0 bs=4096 count=100 409600 bytes copied, 361400 usec, 1106 KB/s As observed, the raw speed for the RAM based block device is 181 M/S, through vfat on a ramdisk is 85 M/S and 0.5M/S with SD (Class 4). The raw speed using the BCH device (sd0) is 1M/s. On Fri, 2 Jun 2023 at 05:18, Gregory Nutt <spudan...@gmail.com> wrote: > > > That would help when tickless mode is used. But what about tickful mode? > I > > guess the intent of 7312a553b was to avoid wasting processor cycles on > busy > > waiting, but if tickless isn't being used, perhaps busy waiting is > > necessary here? It could choose between the two wait types at compile > time > > based on tickless mode. > In "tickful" mode, you could increase the timer frequency to improve > resolution. At 1000 Hz things run pretty well too. But at some point, > however, the interrupt processing overhead becomes prohibitive. > > Or a bigger question: if tickless mode is "better" (longer battery life, > > fewer unnecessary interrupts, more processor cycles for real work) why > > aren't we always using tickless mode? Are there limitations/bugs that > make > > it unsuitable in some situations? Not universally supported on all > > microprocessors? Other reasons? > > It does rely on an available high resolution timer and, so, uses > resources that not all MCUs may have. It would also take a substantial > effort to convert all existing architectures to support tickless. > > But the real reason is that tickless mode was experimental and not > supported on all platforms on initial release and also not well > trusted. But I think it is well trusted these days and could be the > standard. > > I am not opposed to the idea at all. I do like the "tickful" mode for > MCU bringup because it is a lot simpler. Tickless support can be added > later when the port is stable. > > >
