On Sat, Jul 16, 2022 at 5:05 AM gene heskett <ghesk...@shentel.net> wrote: > On 7/15/22 21:54, Paul Wise wrote: > > On Fri, 2022-07-15 at 13:40 -0400, gene heskett wrote: > > > >> Because our latency-test results are better on armhf than on arm64, > >> we use armhf for its performance. > > Are these results for armhf kernel with armhf userland? > The whole install of raspios is armhf. So I guess its yes. > > > Are the results for arm64 kernel with armhf userland similar? > I have not tried to build an aarch64 from the src I have. > > How much worse are the results for arm64 kernel and userland? > No, not exact, but its roughly 4x longer when I can get it to run, > as it did check for a realtime preempt kernel and did a graceful > exit if not found. So its not been run on 64 bit Debian image since > stretch.
There are unfortunately a number of variables here that make things really hard to compare, any of these can have an effect that dominates your results: - 4.19 is four years old, and both the mainline kernel and the preempt-rt patches have changed a lot in the meantime. It's possible that a current preempt-rt has regressed compared to the version you are running. If so, we can work on fixing the regression for future kernels, but there won't be much interest in working on the old kernel - Raspberry Pi OS (and Raspbian before that) has a number of platform specific kernel patches that are neither in mainline Linux nor in the Debian kernel packages. It is possible that they have already identified and fixed a source of latency in their kernels but not managed to upstream that fix for a number of reasons. - A lot of kernel configuration options can have a huge impact on latency, it's not just preempt-rt that can be turned on or off, but any device driver that disables preemption for too long can increase the maximum latency of the system. - The raspbian user space should have very little effect on latency but it's worth pointing out that you may see different performance between armv6 (raspbian) and armv7 (debian armhf), between vfpv3-d16 (raspbian and debian armhf) and neon-d32 (fedora and others), and between a32 (raspbian), t32 (debian armhf) and a64 (debian arm64), instruction sets running the same code. In most applications the effect is very small, and it's not always the same one that's fast either. > It, latency-test, has recently been worked on but I've not tested > it on a Debian image of either flavor since. Do you have your latency-test output available for reference somewhere? To establish a baseline, it would be good if someone could run the same test using debian armhf userland on similar hardware with this kernel: https://packages.debian.org/bookworm/linux-image-rt-arm64 If that can reproduce the bad numbers you observed, the next step would be to try a corresponding 32-bit kernel and see if that is better, but that requires building a custom package. There is a linux-image-rt-armmp package in bookworm, but to get PCI and USB3 working on Raspberry Pi 4, one needs to enable both the PCI driver and CONFIG_ARM_LPAE, possibly more. > It is now in testing so those of you w/o 5 years of history to lose > could try it for the price of a 64G u-sd card. For some reason, linuxcnc is still missing for armhf. I managed to build the source package, which had a minor issue finding the libboost_python310 dependency, but it worked after I added that. I don't have the right system to test on myself though. [Side note: I hope you are not storing any important data on an SD card. Even with "industrial grade" ones, I would recommend doing regular backups to more permanent storage, and the usual consumer cards are not designed to handle running a general-purpose OS at all and will cause data corruption over time] Arnd
