[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: latency test results for armhf vs arm64?



On 7/16/22 10:33, Arnd Bergmann wrote:
On Sat, Jul 16, 2022 at 2:41 PM gene heskett <gheskett@shentel.net> 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 <http://geneslinuxbox.net:6309/>


Reply to: