Re: latency test results for armhf vs arm64?
On Sat, Jul 16, 2022 at 5:05 AM gene heskett <gheskett@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
Reply to: