Raspberry Pi4 announced

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
I forgot.

The RPI foundation officially supports now (since September, if I'm not mistaken) a 64bit RPI kernel with special focus on PI4. It also works on the PI3B+.

There'd be no need to use the rather "crippled" 64bit mainline kernel for the PI anymore.
Basically the known kernel structure with all its adaptions, tweaks, overlays asf. etc. remains as known from the 32bit RPI kernels.

However. What's missing is the PI4 64bit userland on pretty much all major PI4 OSes.

The for now only existing 64bit image is a Gentoo image.
 
Moderator
Joined 2002
Paid Member
The flawed USB power port is still an issue on the Pi4. No update yet as it seems.

I'm using my 4GB model as a server - it replaces a Tinkerboard which was set up in similar fashion, though I did have a traditional fileserver (basically a Windows machine with shared directories) do to the more heavy lifting which required both gigabit Ethernet and fast drive access. The smaller units basically run Transmission, Samba and PiHole.

I had though the Pi4 would give me a big speed boost in terms of storage access but it seems moving to USB3 has only moved me from ~30MB/s to ~40MB/s. True, it's a 30% speed boost and the drives are in NTFS, but I've seen the top Netgear routers deliver over 80MB/s using the same drives.

Since I am a very basic user, I've stuck with the official distribution. And the setup works well enough that I haven't considered installing anything else. I know this may not be as much help to the audio side of things, but there it is. The way I see it, the Pi4 will have a long wait to fully realise its potential, by which time there will 5, 6, or something else.
 
I just did another benchmark test.

Basically generating a 1GB file and writing it.

I used the same Crucial SSD on

* Broadwell NUC and
* the PI4.


NUC

time sh -c "dd if=/dev/zero of=./ddwrite bs=1G count=1 && sync"; rm ./ddwrite
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 1,17882 s, 911 MB/s

real 0m3,567s
user 0m0,002s
sys 0m1,221s


PI4 @ 1500MHz

time sh -c "dd if=/dev/zero of=./ddwrite bs=1G count=1 && sync"; rm ./ddwrite
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 9.48629 s, 113 MB/s

real 0m10.753s
user 0m0.002s
sys 0m9.470s


This simply shows that we're still talking about different leagues.

I ran the same test on a tmpfs btw:

NUC: 1,2GB/s
PI4: 209MB/s
 
Last edited:
Nobody except you is talking about SATA. :confused: That's irrelevant.

Sangam came up with USB3 and the slow NTFS.



I then did a bit of benchmarking of what actually can be expected - best case.

I compared the PI4 USB3 vs. NUC (Broadwell-i5) USB3 by using the same SSD.

The PI4 performs much better then its predecessors. No question. And that's great.

Still. A single PCIe lane, rather slow RAM, asf, simply slows the device down
in comparison to the big boys out there.
As a serious powerful server even the PI4 is IMO still the wrong device.
But that I mentioned before.




Enjoy.
 
There are quite a lot of other things that the PI folks didn't have in mind
when starting the RPI project. ;)

It's not about the designers though. It's about the users.
The user simply need to understand what to expect from such a device.


The Pi4 will work as a server. Better then any other PI before.
Actually it's the first time I'm considering to run the PI4 as LMS server myself.
Data and / will be stored on a SSD.
Since I currently do not run any demanding DSP tasks it should work rather well.


And not to forget. All that @$40. That tag alone should limit the exceptions from the very beginning. ;)


Enjoy.
 
FYI.

I just managed to get my ArchLinuxArm RPI4 64bit installation - RPI rt-kernel and userland - going. :D

Code:
root@boss64:~# cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.1

root@boss64:~# uname -a
Linux boss64 4.19.79-rt25-sc1 #2 SMP PREEMPT RT Mon Oct 14 09:35:28 CEST 2019 aarch64 GNU/Linux

root@boss64:~# file /usr/bin/ls
/usr/bin/ls: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=d3d0049a9af71d4be7a4dafff7d668b248b75319, for GNU/Linux 3.7.0, stripped
 
Moderator
Joined 2002
Paid Member
I did try xfs but I couldn't get off the ground. I wasn't able to obtain write permissions for the drive after formatting, so I stuck with NTFS.

It's not possible to have 20TB of SSDs. It is, but not on zero salary. Therefore I'm on mech drives still. Mine is abit of a worst case - but I've seen better performance with routers and NTFS drives (see here: Router Charts - NTFS Read - USB 3.0) As you can see, there are plenty of routers that will hit the 100MB/s with NTFS drives on the USB 3.0 port. That would satisfy me - and all routers run Linux, sort of.

I do know that NTFS is slower than native FS. That is not a surprise to me. I was not expecting SSD-like performance, just close to what a consumer router would give me. That is my disappointment.

Besides, I'm uniterested in benchmarks. Real-world file transfer speeds over a network are what I'm interested in. I move many gigs of data over a network on a daily basis and 40-50MB/s is fine, just a little less than what I was expecting.
 
Besides, I'm uniterested in benchmarks.


:rolleyes: That's IMO pretty stupid.

You basically will have no reference. You're not able to see and identify the flaws or bottlenecks and based on that you draw highly questionable out-of-context conclusions. Like "my PI4 just does 30MBit/s".


It happened more then once that I was able to identify and solve quite serious issues by running benchmarks.
Such findings even lead to changes on official SW such as piCoreplayer.


Before I buy a device I have a look at e.g. Phoronix to lookup their benchmarks to get to know what to expect.

The first thing, after running stable, I do on any new system is running some basic benchmarks and that includes the (wireless) network performance btw.
I simply need to know that the system works fine.


I'm just saying. :D
 
Last edited:
Moderator
Joined 2002
Paid Member
:rolleyes: That's IMO pretty stupid.

Reading one line of a post and responding to it in isolation is exactly as stupid.

I said:

Besides, I'm uniterested in benchmarks.

Followed by

Real-world file transfer speeds over a network are what I'm interested in. I move many gigs of data over a network on a daily basis and 40-50MB/s is fine, just a little less than what I was expecting.

Am I stupid to expect something that delivers in real life? Benchmarks represent best case scenario. Not everybody has the same use case.

:rolleyes:
 
Read and try to understand what I wrote.

That I'm simply quoting the key-message of your post, which to me is your key problem, doesn't mean I didn't read the whole text.

And guess what. I read your OP once more.
And another problem is of course is this:

...Since I am a very basic user, I've stuck with the official distribution...

That problem alone, will prevent you from understanding your system and pushing its limits. Even running proper benchmarking tests would exceed
your capabilities. Now I understand.

The PI was never build and intended for very basic users though. There's a reason why SBCs are usually also called "development boards". ;)
If you plan to continue to work with SBCs, you better gain some knowledge over time. It'll help a lot.

I do have the feeling, since the intro of the RPI, we have a lot more advanced Linux users around - even 10-year olds. Great. ;)


Good luck with your projects.
 
Some more PI4 updates.

The foundation now merged the eeprom update toolsets.
Basically it's now possible to upgrade bootloader and usb controller with a single rpi-eeprom-update tool.
I bring that up once more because I consider certain features, such as saving around 20% power, that would come with
these eeprom/firmware upgrades quite essential.


Anyhow. My full blown 64bit system based on ARCH Linux is running quite stable now.

The powersavings measures known from the 3B+ are still not applicable though. I'm currently running
at around 480mA idle compared to 225mA idle
on the 3B+.

Stuff, like turning the mainboard LED off works. Turning the ethernet port LEDs off doesn't.
I am neither be able to turn off USB nor I'm able to turn off HDMI.

Again. The new platform is all but in a comparable mature state as the 3B+ platform used to be.

One thing that I'd really like to see is USB-boot. It's supposed to come sooner or later. They did focus on NetBoot first though.
You can still run the old method of putting the root dir on a SSD to speed things seriously up.


Yep. The PI folks are still working on the basics. The dust hasn't settled yet. ;)



Over the weekend I attached a SSD to the PI4.
And then I made Logitechmediaserver going on my aarch64 userland.
And of course put the server and the music data on that SSD.

So far I'm more then pleased with the basic performance of that server.
The server is pretty responsive. I didn't experience any lags so far.
I could easily live with that setup. Of course I havn't done serious transcoding yet and my test database just holds a around 2000 tracks. Under real world conditions my early impressions might change.

That'll be it for now.

Enjoy.
 
Last edited:
Not sure. Depends how you look at it.

Do you think building your own PS, DAC, amp or speaker (every other month) is a different subject and cost less free time !?!? :D

Fact is most users don't really care.
99.99% of all people simply write a foc image to SD card and enjoy the result. A 10 minutes effort. I think that's a great deal for the 99.99% .
For the rest it's a hobby. :D

Change and progress is the fuel to our hobbies. That keeps us going.
Time aspects become somewhat irrelevant. ;)

Enjoy.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.