Re: latency test results for armhf vs arm64?

[Lennart Sorensen]

On Sat, Jul 16, 2022 at 08:35:26PM +0200, Diederik de Haas wrote:
> Raspbian(.org) was created by Peter Green (plugwash) (and Mike Thompson who's 
> name is still attached to raspbian(.org)'s GPG key, but otherwise moved on) 
> precisely because the RPi 1 did not meet the armhf/armv7 qualifications that 
> Debian uses.
> The Raspberry Pi Foundation (RPF) started with (Debian's) armel (armv5) 
> architecture, but that was slow and didn't optimally use the HW that was 
> available on the RPi 1.
> 
> So Plugwash (and Mike) started a recompilation of the Debian archive which 
> makes better use of the HW available in the RPi 1. Confusingly, they labeled 
> it armhf, while it was and is NOT the same as Debian's armhf.
> To add to the confusion, RPF called their OS also Raspbian :-/
> 
> AFAIK it's still Plugwash that runs the buildd which compiles the packages 
> for 
> Raspbian/RaspiOS, but those packages are now also mirrored on RPF servers/
> archives. That is still ~armv6 (+hardfloat+sth IIRC).
> 
> The RPi 2 (and newer) can run Debian's armhf (armv7).
> 
> The RPi 3 and newer can also run arm64 and that is the same as Debian's.
> 
> I am *quite* sure RaspiOS is not available in normal/Debian's armhf, but only 
> in their own armv6+ (but labeled armhf) and arm64.

Yeah looking at raspberrypi.com they seem to have 64 bit and 32 bit
builds.  The 32 bit is definitely armv6 since it says it is compatible
with all versions of the pi.  Pretty sure they have never done armv7
since that would just be what Debian already provides and would break
the Pi 0 and Pi 1 after all although the 2 would be happier.  It shoudl
happily run on a kernel that supports armv7 but it does mean user space
certainly isn't fully taking advantage of what a pi 2 or newer offers.

I certainly only see 2 flavours on the page.  The original armel I don't
think has been made for quite a few years at this point and proper armv7
armhf they have certainly never done either.  So they have 2 flavours:
armv6 and armv8.

-- 
Len Sorensen

Re: latency test results for armhf vs arm64?

[Diederik de Haas]

On Saturday, 16 July 2022 18:19:31 CEST gene heskett wrote:
> > You said raspios which sure looks like raspian.  Raspian/Raspberry Pi
> > OS is armv6.  If you are running Debian armhf, then it is armv7 but it
> > would be a lot less confusing to call it Debian and not raspios in
> > that case.
> 
> raspian/raspios is available in all 3 flavors.

Raspbian(.org) was created by Peter Green (plugwash) (and Mike Thompson who's 
name is still attached to raspbian(.org)'s GPG key, but otherwise moved on) 
precisely because the RPi 1 did not meet the armhf/armv7 qualifications that 
Debian uses.
The Raspberry Pi Foundation (RPF) started with (Debian's) armel (armv5) 
architecture, but that was slow and didn't optimally use the HW that was 
available on the RPi 1.

So Plugwash (and Mike) started a recompilation of the Debian archive which 
makes better use of the HW available in the RPi 1. Confusingly, they labeled 
it armhf, while it was and is NOT the same as Debian's armhf.
To add to the confusion, RPF called their OS also Raspbian :-/

AFAIK it's still Plugwash that runs the buildd which compiles the packages for 
Raspbian/RaspiOS, but those packages are now also mirrored on RPF servers/
archives. That is still ~armv6 (+hardfloat+sth IIRC).

The RPi 2 (and newer) can run Debian's armhf (armv7).

The RPi 3 and newer can also run arm64 and that is the same as Debian's.

I am *quite* sure RaspiOS is not available in normal/Debian's armhf, but only 
in their own armv6+ (but labeled armhf) and arm64.

HTH

signature.asc
Description: This is a digitally signed message part.

Re: latency test results for armhf vs arm64?

[Matthias Klein]

> Am 16.07.2022 um 18:02 schrieb gene heskett :
> 
> I've not been
> able to find another kernel src any newer that even admits to having a
> realtime preempt in its config, it is conspicuously absent in anything
> newer, and I am subbed to linux-rt so I see all the new stuff being
> announced. 

You could try the following kernel:

https://github.com/kdoren/linux
https://github.com/kdoren/linux/discussions/11

(I have no own experience with the above kernel)

Best regards,
Matthias

Re: latency test results for armhf vs arm64?

[Lennart Sorensen]

On Sat, Jul 16, 2022 at 12:19:31PM -0400, gene heskett wrote:
> raspian/raspios is available in all 3 flavors.

Oh right they do have the other ones, they are just not the ones they
recommend by default.

> True, but when those two seagate 2T drives puked in quick succession, I lost
> all
> my patched amanda sources. I'd only been running amanda since 1998.
> I figured if bullseye ever stabilizes I might see about starting it up
> again. But UM
> sold it to zmanda so progress stopped, and then was sold to Betsol about 2
> years back, and so far they've been all hat and no cattle. As far as I'm
> concerned its time to look for a new backup strategy that mimics how amanda
> worked. IOW I'm still building this box, almost from scratch. Its been very
> painful
> so far with bullseye.

Yeah loosing multiple drives sucks.

My important stuff sits on a raid6 setup and does automatic off site
(to my parents house) backups using rsnapshot.

-- 
Len Sorensen

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/16/22 11:32, Lennart Sorensen wrote:

On Sat, Jul 16, 2022 at 08:41:07AM -0400, gene heskett wrote:

I wish you would admit that the raspios I am running IS armhf (kernel7l)
I've no clue where you got the impression it was v6. It is not.

You said raspios which sure looks like raspian.  Raspian/Raspberry Pi
OS is armv6.  If you are running Debian armhf, then it is armv7 but it
would be a lot less confusing to call it Debian and not raspios in
that case.

raspian/raspios is available in all 3 flavors.

Doesn't matter what your kernel is.  What is your userspace you are
actually running?


The card its running on right now is over 2 years old, zero problems,
and has had all updates, including a daily update of linuxcnc from the
the buildbot, or if the buildbot is down, my own scripts also building
installable deb's. The secret is use a big enough card that it has enough
room to do its maintenance. 64G card has around 15G's on it.

Backups once in a while of the card is still nice to have.

True, but when those two seagate 2T drives puked in quick succession, I 
lost all

my patched amanda sources. I'd only been running amanda since 1998.
I figured if bullseye ever stabilizes I might see about starting it up 
again. But UM

sold it to zmanda so progress stopped, and then was sold to Betsol about 2
years back, and so far they've been all hat and no cattle. As far as I'm
concerned its time to look for a new backup strategy that mimics how amanda
worked. IOW I'm still building this box, almost from scratch. Its been 
very painful

so far with bullseye.

Cheers, Gene Heskett.

--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/16/22 10:33, Arnd Bergmann wrote:

On Sat, Jul 16, 2022 at 2:41 PM gene heskett  wrote:

On 7/16/22 08:10, Arnd Bergmann wrote:

- 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.

Their kernels are uniformly horrible with latency's ranging to above a
millisecond.
Linuxcnc simply refuses to run on those kernels.

I think this is simply because raspbian does not ship any preempt-rt
kernel themselves, so clearly their kernel binaries won't be low-latency.

You did not say where  you got the kernel that you are running
successfully, so as far as I could tell this might be a combination
of the raspbian patches and the preempt-rt patches.\

I got this as 4.19.y, and applied the realtime patch kit. I've not been
able to find another kernel src any newer that even admits to having a
realtime preempt in its config, it is conspicuously absent in anything
newer, and I am subbed to linux-rt so I see all the new stuff being
announced. But the .configs have not included a realtime you can
see, let alone turn on. This particular 4.19.y was obtained from a git
link I was supplied by a forum msg, about a day before I was black holed.

I've been on my own since, several years now. It was me that figured
out how to build it, and it was me who figured out a way to install it.

Up until now, when I've asked arm questions here, I've essentially been
told to bug/buzz off. Which is why I made the comment about a civil 
discussion.
Its a surprise, and I certainly welcome it. I've never had the intention 
of being

a PITA.

What you've seen in the uname -a output I've posted was my 2nd build, the
first one was built when 4.19 was fairly new but the video was still 
slow, this

one was after some patches that enable the specific gfx these arms used. And
TBT, I was amazed that it actually worked both times. I had been led to 
believe
that stability was not in the arm vocabulary, but this is at least as 
solid as
wintel stuff has ever been. OTOH, wheezy was a giant step fwd in that 
department.


I can put that src tarball up on my web page, but 4.19.y s/b available 
at faster
servers. I've only a 10 megabaud adsl, meaning slow slow downloads from 
my site.


Take care & stay well.

- 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)

I wish you would admit that the raspios I am running IS armhf (kernel7l)
I've no clue where you got the impression it was v6. It is not.

This paragraph was about the user space, not the kernel.

The entire reason for Raspbian's existence is that it runs on armv6
hardware like the Raspberry Pi 1, which Debian armhf does not
run on. Building for armv6 means they can run the same user space
on all hardware generations from v6 to v8, and they advertise this
on their website:
https://www.raspberrypi.com/software/operating-systems/
ship at least two separate 32-bit kernels, since an LPAE-enabled
kernel is needed to access PCI and high memory but is incompatible
with Armv6 hardware.

  Arnd
.



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: latency test results for armhf vs arm64?

[Lennart Sorensen]

On Sat, Jul 16, 2022 at 08:41:07AM -0400, gene heskett wrote:
> I wish you would admit that the raspios I am running IS armhf (kernel7l)
> I've no clue where you got the impression it was v6. It is not.

You said raspios which sure looks like raspian.  Raspian/Raspberry Pi
OS is armv6.  If you are running Debian armhf, then it is armv7 but it
would be a lot less confusing to call it Debian and not raspios in
that case.

Doesn't matter what your kernel is.  What is your userspace you are
actually running?

> The card its running on right now is over 2 years old, zero problems,
> and has had all updates, including a daily update of linuxcnc from the
> the buildbot, or if the buildbot is down, my own scripts also building
> installable deb's. The secret is use a big enough card that it has enough
> room to do its maintenance. 64G card has around 15G's on it.

Backups once in a while of the card is still nice to have.

-- 
Len Sorensen

Re: latency test results for armhf vs arm64?

[Arnd Bergmann]

On Sat, Jul 16, 2022 at 2:41 PM gene heskett  wrote:
> On 7/16/22 08:10, Arnd Bergmann wrote:
> >
> > - 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.
>
> Their kernels are uniformly horrible with latency's ranging to above a
> millisecond.
> Linuxcnc simply refuses to run on those kernels.

I think this is simply because raspbian does not ship any preempt-rt
kernel themselves, so clearly their kernel binaries won't be low-latency.

You did not say where  you got the kernel that you are running
successfully, so as far as I could tell this might be a combination
of the raspbian patches and the preempt-rt patches.

> > - 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)
> I wish you would admit that the raspios I am running IS armhf (kernel7l)
> I've no clue where you got the impression it was v6. It is not.

This paragraph was about the user space, not the kernel.

The entire reason for Raspbian's existence is that it runs on armv6
hardware like the Raspberry Pi 1, which Debian armhf does not
run on. Building for armv6 means they can run the same user space
on all hardware generations from v6 to v8, and they advertise this
on their website:
https://www.raspberrypi.com/software/operating-systems/
ship at least two separate 32-bit kernels, since an LPAE-enabled
kernel is needed to access PCI and high memory but is incompatible
with Armv6 hardware.

 Arnd

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/16/22 08:10, Arnd Bergmann wrote:

On Sat, Jul 16, 2022 at 5:05 AM gene heskett  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.


Their kernels are uniformly horrible with latency's ranging to above a 
millisecond.

Linuxcnc simply refuses to run on those kernels.

- 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)

I wish you would admit that the raspios I am running IS armhf (kernel7l)
I've no clue where you got the impression it was v6. It is not.

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]

The card its running on right now is over 2 years old, zero problems,
and has had all updates, including a daily update of linuxcnc from the
the buildbot, or if the buildbot is down, my own scripts also building
installable deb's. The secret is use a big enough card that it has enough
room to do its maintenance. 64G card has around 15G's on it.

Take care and stay well everybody.


   Arnd
.



Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: latency test results for armhf vs arm64?

[gene heskett]

On 7/16/22 05:59, Paul Wise wrote:

On Fri, 2022-07-15 at 23:05 -0400, gene heskett wrote:


The whole install of raspios is armhf. So I guess its yes.

I seem to remember them switching to arm64 recently?


They may have, I've had a total loss of history here with 2, 2T seagate
drives dieing within a couple weeks of each other. So let me see if I have
the bullseye image for arm I've tried.  Yes, and its:
2021-10-30-raspios-bullseye-armhf-full.img
Which ran fine, even with my now 2 yo kernel installed but the python
is too new for linuxcnc. With a second user wanting to dup what I did,
I've sent him two cards with the raspios buster for armhf, with my kernel
installed by my method. Linuxcnc has been advised of the python showstopper,
and that may have been fixed by now, but if so, its not caught my attention
in the email's I get from a 4x a day git pull keeping the pi up to date.

Since that master is now in testing for bookworm, I have to assume it 
has been fixed.


I also have 11-2 of yours, in netinstall flavor and labeled as armhf. As 
I recall

it had some sort of a showstopper, and I knew raspios worked, I don't recall
that  I investigated yours further. Is there a later netinstall for 
armhf or arm64

available now? u-sd cards I have.

I have not tried to build an aarch64 from the src I have.
I think, since the 240G I'm using for workspace is over 50% full, that I 
had better
replace the 120G I've used for a backup, with a 1T and copy the 240 to 
it, before
I do anything rash. That can be done but I'm in the middle of rebuilding 
a Prusa MK3S
with a better print head and that has priority at the moment. I am using 
it to make
the nuts for a woodworkers workbench vises, carving the screw from a 
2x2" stick
of hard maple about 20" long. See version #1 on my web page it the sig. 
Reshaping
the threads for a lot better fit, version #5 is waiting on a working 
printer to make

more nuts.

I think it would be helpful if someone with an RPi4 could do this.

That's probably me but its also likely a week on down the log.


It, latency-test, has recently been worked on but I've not tested
it on a Debian image of either flavor since. 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 those of you who are able to try this, sounds like you just install
linuxcnc-uspace and then run latency-test. Also install/try latencytop,
although Linux CONFIG_LATENCYTOP is not enabled in Debian probably.

$ apt-file search latency-test
linuxcnc-uspace: /usr/bin/latency-test
linuxcnc-uspace: 
/usr/share/doc/linuxcnc/examples/sample-configs/apps/latency/latency-test.demo
linuxcnc-uspace: /usr/share/man/man1/latency-test.1.gz


latencytop I've heard of, but haven't found, so no comparison comment.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: latency test results for armhf vs arm64?

[Arnd Bergmann]

On Sat, Jul 16, 2022 at 5:05 AM gene heskett  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

Re: latency test results for armhf vs arm64?

[Paul Wise]

On Fri, 2022-07-15 at 23:05 -0400, gene heskett wrote:

> The whole install of raspios is armhf. So I guess its yes.

I seem to remember them switching to arm64 recently?

> I have not tried to build an aarch64 from the src I have.

I think it would be helpful if someone with an RPi4 could do this.

> It, latency-test, has recently been worked on but I've not tested
> it on a Debian image of either flavor since. 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 those of you who are able to try this, sounds like you just install
linuxcnc-uspace and then run latency-test. Also install/try latencytop,
although Linux CONFIG_LATENCYTOP is not enabled in Debian probably.

$ apt-file search latency-test
linuxcnc-uspace: /usr/bin/latency-test
linuxcnc-uspace: 
/usr/share/doc/linuxcnc/examples/sample-configs/apps/latency/latency-test.demo
linuxcnc-uspace: /usr/share/man/man1/latency-test.1.gz

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: latency test results for armhf vs arm64?

[gene heskett]

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.

It, latency-test, has recently been worked on but I've not tested
it on a Debian image of either flavor since. 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.

I want to thank you /all/ for a civil discussion. It has not been all that
welcoming  in the past.

Take care and stay well everybody.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 
null