Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]
On Wednesday 03 March 2021 03:44:13 LinAdmin wrote:
> The common believe that on the same hardware 64-bit must be
> better or equal to 32-bit is clearly wrong for the "crazy"
> BCM2711 chip used in Pi4.
> The detailed benchmarks for Raspian Buster are at 32 Bit
> Kernel 4.19 <http://ix.io/1MFf> and 64 Bit Kernel 5.4.
> <http://ix.io/2paq> showing for calculation AES 16KB 50%
> less throughput for 64-bit.
>
> On my system I get similar results e.g. for AES-128 (16KB):
> Salsa Buster arm64 5.9.0 42'000
> Ubuntu LTS armv7l 5.4 92'000
> When playing a FullHD video coded H265, the average CPU load
> is 80% on 64-bit and less than 30% on 32-bit!
> Similar situations when encoding to H265 using ffmpeg .
>
> LinAdmin
>
> On 02.03.21 21:30, Arnd Bergmann wrote:
> > On Tue, Mar 2, 2021 at 7:51 PM LinAdmin <linadmin@quickline.ch>
wrote:
> >>> There is really no good reason to run a 32-bit /kernel/ on the Pi
> >>> 4, especially the version
> >>> with 8GB RAM. While the bug should get fixed in principle to make
> >>> the default kernel
> >>> work and allow installing a 32-bit distro, the best setup for this
> >>> machine (especially
> >>> the versions with less than 4GB) is to use an armhf user space
> >>> with a 64-bit kernel.
> >>
> >> Benchmarking shows that the Pi4 with 32 bit kernel has about
> >> double performance compared to 64 bit kernel!!!
> >
> > Can be more specific about what benchmarks and who ran them?
> > This seems highly unlikely.
> >
> > Arnd
To add further fuel to this fire, this is precisely why, when running cnc
machinery with a pi3 or pi4, an armhf kernel is the only one that comes
anywhere near meeting the performance it takes to do a decent job of
running dangerous machinery. The irq response time of the 64 bit
kernels has been found to be seriously lacking. I built a
4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6 07:09:18 EST 2020 armv7l
kernel last on an rpi4 over a year ago, which can respond to a fault
interrupt in as little as 12 microseconds. Several have now tried the
arm64 version and all got far worse latency results. As bad as 200
microseconds. You simply cannot run a stepper motor, using software step
generators at even 10% of that motors speed potential with that kind of
timing wibbles in the steps sent. They will stall, stop, losing step
counts. Even if the code stops and the motor then restarts, you've lost
the home reference and wrecked the part being made. That kernel was also
built for a pi3b and worked well for around 2 years, but the pi3b was
about to its limits.
The other limit to using it, is the odd layout of the /boot directory
enforced by the firmware that boots it, not well documented, so I had to
invent my own way to install that kernel. But suffice to say, its dead
stable. I even put a small ups on it, runs for months. So stable that I
am also running an armhf version of a buildbot for linuxcnc on it.
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)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: