Open geerlingguy opened 1 year ago
@fanoush - I don't have x-rays yet, but here's the bottom:
@ayufan - dump_cameras.sh
output below:
what does the armhf 32bit image use as it's kernel? An armv6 kernel with 4k pages? An armv7 kernel with 4k pages? Armv8 with 4 or 16k pages?
AFAICT, Pi 5 doesn't yet have a 32-bit Arm image (not sure if there will be one?). All of us have been testing on 64-bit image. Good question to ask one of the Pi engineers.
@erdnussIO - I believe the PHY might have a pin for PPS_OUT, but it is not routed anywhere accessible on the Pi 5 (at least not at a quick glance). Maybe there's a test pin somewhere (TP64?) on the bottom it can be accessed?
On the CM4, there was a separate header where PPS_IN/PPS_OUT was exposed. I don't see any way for it to route to GPIO so we'd need to figure out the pin on the BCM chip and solder to it.
what does the armhf 32bit image use as it's kernel? An armv6 kernel with 4k pages? An armv7 kernel with 4k pages? Armv8 with 4 or 16k pages?
AFAICT, Pi 5 doesn't yet have a 32-bit Arm image (not sure if there will be one?). All of us have been testing on 64-bit image. Good question to ask one of the Pi engineers.
@erdnussIO - I believe the PHY might have a pin for PPS_OUT, but it is not routed anywhere accessible on the Pi 5 (at least not at a quick glance). Maybe there's a test pin somewhere (TP64?) on the bottom it can be accessed?
On the CM4, there was a separate header where PPS_IN/PPS_OUT was exposed. I don't see any way for it to route to GPIO so we'd need to figure out the pin on the BCM chip and solder to it.
Thank you so much for your investigation. That would be a bit of a pity - I would have hoped for something like that pin to be routed through the RP1 as an AF or so (which, I have to admit, would probably be quite unconventional). So much for an audio HAT synchronized to/clocked by PTP via the PPS output (having AES67 in mind here)
/dev/video21 | [40]: 'PC1B' (PiSP Bayer Comp 1, compressed) /dev/video21 | [41]: 'PC1R' (PiSP Bayer Comp 1, compressed) /dev/video21 | [42]: 'PC1G' (PiSP Bayer Comp 1, compressed) /dev/video21 | [43]: 'PC1g' (PiSP Bayer Comp 1, compressed) /dev/video21 | [44]: 'RPBP' (PiSP Opaque Format, compressed)
This looks very interesting.... do RPI have their special compressed Bayer format?
Also thank you for all the work and follow up you did, this thread has been a amazing source of information!
@will127534 I believe this is for supporting more advanced and higher-pixel camera sensors. It seems that ISP will accept up-to: 65535x65535.
@geerlingguy I have compiled vulkancapsviewer and glcapsviewer for you to run if you can. this will allow you to upload the OpenGL/GLES/Vulkan capabilities of the Pi5 to the respective online databases (https://opengl.gpuinfo.org/ https://vulkan.gpuinfo.org/)
You will need a few libraries installed to run the binaries. I will list them in debian control automated format for each after each zip glcapsviewer.zip
Depends=libc6 (>= 2.34), libgcc-s1 (>= 3.0), libglew2.2 (>= 2.2.0-4+b1), libglfw3 (>= 3.0), libglx0, libopengl0, libqt5core5a (>= 5.14.1), libqt5gui5 (>= 5.0.2) | libqt5gui5-gles (>= 5.0.2), libqt5network5 (>= 5.0.2), libqt5widgets5 (>= 5.4.0), libstdc++6 (>= 11), libx11-6
Depends=libc6 (>= 2.34), libgcc-s1 (>= 3.0), libqt5core5a (>= 5.15.1), libqt5gui5 (>= 5.0.2) | libqt5gui5-gles (>= 5.0.2), libqt5network5 (>= 5.0.2), libqt5widgets5 (>= 5.14.1), libstdc++6 (>= 11), libvulkan1 (>= 1.2.131.2), libwayland-client0 (>= 1.0.2)
In glcapsviewer make sure to upload both the OpenGL Default and OpenGLES 3.0 Context results
For anyone curious, these dependencies were autogenerated using dpkg-shlibdeps
which is what many debian packages use to generate their dependencies. So I just did this in the folder that contained the binary:
# create dummy debian control file
mkdir debian
touch debian/control
# generate dependency list in debian control format and print to stdout
dpkg-shlibdeps --ignore-missing-info -O vulkanCapsViewer
here are the results I uploaded myself on pi4 bookworm arm64 beta
vulkan: https://vulkan.gpuinfo.org/displayreport.php?id=24473 opengl: https://opengl.gpuinfo.org/displayreport.php?id=10496 opengles: https://opengl.gpuinfo.org/displayreport.php?id=10497
@theofficialgman - I will try to run that later (have a kids' event to attend tonight, was painting most of the day!). @will127534 and @ayufan — when I visited Pi HQ in May, I noticed there was a lot of buzz around ISP in the new chip, they were excited to talk about camera capabilities (and some ideas using RP1 for low power stuff, like detecting simple light/dark levels via camera even if BCM2712 is powered off).
When engineers talk with some excitement, it often indicates they are proud of some things that they know you won't understand. And I understand little of the guts of the thing!
Looks like it is still limited to USB OTG 2.0 like the Pi4 [1]. Rock 3/4 have USB OTG 3.0 but ~Rock 5~ only has USB OTG 2.0 like all the raspberrypi's.
I need a SBC with USB OTG 3.0 for a fast piSCSI USB Drive.
I wonder if we can switch that DW3 USB3 IP to be in device mode and we can then have the USB OTG 3.0 on the USB-A connector.
Any luck on VAINFO? if it does have HEVC 10bit decode, could make for a nice little HDR transcode capable jellyfish server
@theofficialgman - See:
@FCLC - vainfo
returns:
pi@pi5:~/Downloads/vktest $ sudo vainfo
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
libva info: VA-API version 1.17.0
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
vaInitialize failed with error code -1 (unknown libva error),exit
@theofficialgman - See:
@FCLC -
vainfo
returns:pi@pi5:~/Downloads/vktest $ sudo vainfo error: XDG_RUNTIME_DIR is invalid or not set in the environment. libva info: VA-API version 1.17.0 libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null) vaInitialize failed with error code -1 (unknown libva error),exit
You shouldn't need sudo here, but it shouldn't hurt. Could be that they haven't enabled vaapi and that they've only got v4l2 up and running right now
EDIT:
Maybe try v4l2-ctl --list-formats-ext?
Linux/system information
# output of `neofetch` _,met$$$$$gg. pi@pi5 ,g$$$$$$$$$$$$$$$P. ------ ,g$$P" """Y$$.". OS: Debian GNU/Linux 12 (bookworm) aarch64 ,$$P' `$$$. Host: Raspberry Pi 5 Model B Rev 1.0 ',$$P ,ggs. `$$b: Kernel: 6.1.32-v8+ `d$$' ,$P"' . $$$ Uptime: 4 mins $$P d$' , $$P Packages: 1536 (dpkg) $$: $$. - ,d$$' Shell: bash 5.2.15 $$; Y$b._ _,d$P' Resolution: 1920x1080 Y$$. `.`"Y$$$$P"' Terminal: /dev/pts/0 `$$b "-.__ CPU: BCM2835 (4) @ 2.400GHz `Y$$ Memory: 416MiB / 7942MiB `Y$$. `$$b. `Y$$b. `"Y$b._ `""" # output of `uname -a` Linux pi5 6.1.32-v8+ #1 SMP PREEMPT Sat Aug 5 07:03:33 BST 2023 aarch64 GNU/Linux
This Neofetch seems a little strange; curious why is it showing the BCM2835 instead of 2712?
This Neofetch seems a little strange; curious why is it showing the BCM2835 instead of 2712?
Much of what goes on with the upside down broadcom chips where its an Arm cluster ontop of videocore boot system is firmware and likely an oversight by raspberry but guess all depends on where neofetch gets each bit of info. Maybe they started with the initial BCM2835 code and hacked up a pi5 revision.
@theofficialgman - See:
@geerlingguy can you make sure to get OpenGLES too please
In glcapsviewer make sure to upload both the OpenGL Default and OpenGLES 3.0 Context results
Some findings I see immediately the maxdrawbuffers increased from 4 on the pi4 to 8 on the pi5. That is great because OpenGL 3.0 conformance requires a minimum supported 8 drawbuffers and the pi4 was never going to meet that (hardware limitation).
One thing I noticed is that they are having mesa report OpenGL 3.1 capabilities on both the pi4 and pi5. Previously they were only reporting 2.1. On the pi4 this is a bit of a lie since it definitely does not meet that 8 minimum draw buffers and never will and its unknown whether Depth format cube textures
and Multisample anti-aliasing
have been implemented from these reports alone. Not sure how to check for those but otherwise yeah the drivers are OpenGL 3.1 capable.
Not much to report on Vulkan besides memory heap size doubling (from about 2GB to 4.2GB) but that might be due to me using a 4GB pi4 while you have an 8GB pi5.
OpenGL comparison of our reports (pi4 vs pi5): https://opengl.gpuinfo.org/compare.php?reports=10496,10501 Vulkan comparison of our reports (pi4 vs pi5): https://vulkan.gpuinfo.org/compare.php?reports=24473,24529
Comparing the Broadcom proprietary driver on this hardware to the MESA drivers is also interesting. https://vulkan.gpuinfo.org/compare.php?reports=24529,19987
This Neofetch seems a little strange; curious why is it showing the BCM2835 instead of 2712?
Since it blindly trusts in /proc/cpuinfo and RPi kernels almost always fake BCM2835 for whatever reason.
@geerlingguy do you have two USB powermeters in your lab to do the simple test whether there's a step-up converter in the power path to the USB ports? What can be measured at the USB3-A receptacles if input voltage at the USB-C port is e.g. 4.8V?
I had the hope to find this information somewhere else but to no avail (and I'm a bit surprised since the RPi's silly 5V powering has always been its achilles heel wrt properly powering USB consumers – as such this would've been the very 1st test I would have done with this thing since 5V @ 5A is so insane)
This Neofetch seems a little strange; curious why is it showing the BCM2835 instead of 2712?
Because the upstream Linux kernel decided that all Raspberry Pi's reports BCM2835 as the SoC name. You can refer to the revision code paragraph.
/dev/video21 | [40]: 'PC1B' (PiSP Bayer Comp 1, compressed) /dev/video21 | [41]: 'PC1R' (PiSP Bayer Comp 1, compressed) /dev/video21 | [42]: 'PC1G' (PiSP Bayer Comp 1, compressed) /dev/video21 | [43]: 'PC1g' (PiSP Bayer Comp 1, compressed) /dev/video21 | [44]: 'RPBP' (PiSP Opaque Format, compressed)
This looks very interesting.... do RPI have their special compressed Bayer format?
Also thank you for all the work and follow up you did, this thread has been a amazing source of information!
The Frontend (found on the RP1) connects to the CSI2 Rx directly, and can output either 16-bit expanded Bayer output (i.e. left shift the sensor output to 16-bits), or output an 8-bit compressed (lossy, but visually near identical to the original) output to save on memory bandwidth and buffer space. Either of these outputs can be read by the Backend ISP on the 2712 chip to process the Bayer data and output YUV/RGB.
So it looks like some of the ISP is in the RP1 (Frontend) where it can output 8bit compressed Bayer to save some bandwidth and memory.
@geerlingguy have you tried testing A1 vs A2 cards on the Pi5?
@geerlingguy OC would be interesting as supposed possible
@StuartIanNaylor - Tom's Hardware tested up to 3.0 GHz. On mine, I could get 2.6 GHz stable, and 2.8 GHz unstable, didn't try 3.0.
I used the settings:
arm_freq=2600
over_voltage=6
force_turbo=1
I did not try overclocking the GPU at all.
One important note; instead of using over_voltage
, it's recommended to use a new option over_voltage_delta
, which will increase the voltage AFTER DVFS has run. And technically, it might work fine without any over voltage applied, according to Pi engineers—the DVFS algorithm may be able to scale voltage correctly without intervention.
it's recommended to use a new option
over_voltage_delta
, which will increase the voltage AFTER DVFS has run.
It's still just a wrong concept since adding any amount of fixed voltage to a DVFS OPP table is a sign of not knowing how DFVS works: the higher the clockspeed the exceptionally higher the supply voltage needs to be. You can't just add '+50mV' in general since this will only work well in a limited range.
And technically, it might work fine without any over voltage applied, according to Pi engineers—the DVFS algorithm may be able to scale voltage correctly without intervention.
Well, you or someone-else might need to explain this in detail. Which 'DVFS algorithm' is in place and what do you need to get this working (ignoring that any overclocking that does not reach at least 3.6 GHz on a 2.4 GHz quad-core A76 CPU is a joke)
I haven't looked for Pi5 kernel changes (not sure if they are public anyway).
Is DVFS here implemented in userspace, kernelspace, or firmware?
Where I am familiar with it (on Nvidia tegra X1) it's implemented in kernelspace and each SOC has what are called "speedos" (fuses with specific values burned into them, binning) that define how good or bad a particular piece of silicon is. The kernelspace uses these speedos, current silicon load, and current frequency to determine what voltage is necessary at any given time for the silicon to operate properly.
I used the settings:
@geerlingguy Maybe a 2nd vid when you have some time to explore as a whole rake of questions have cropped up here. Getting geeky on the OC comparing against current draw, of is it worth it? Maybe if you can grab a few to see if there is much variance.
There is another as the benchmark in https://github.com/Tencent/ncnn would also be interesting for cpu/gpu when vulkan is working as for ML the examples are an OK yardstick. Again maybe make a vid Pi5 Pt II
Same with A1 vs A2 as may A2 cards on other SBC seem to be slower than my A1 cards, which is cool as A1 are cheaper but wonder if the Pi 5 gets the benefit of the A2 cards.
PS I really like this read only mode as it uses overlayfs and merges down on shutdown so its read only, write once on shutdown https://github.com/ecdye/zram-config
Speaking of benchmarks, I made a post on the forum containing the current benchmarks that I have procured or done myself so we can see how the Pi5 stacks up against the competition (tldr, the GPU is still obliterated by mali arm and Nvidia's offerings) https://forums.raspberrypi.com/viewtopic.php?p=2140061#p2140061 You are welcome to add any an all benchmarks to the thread
@ThomasKaiser / @theofficialgman - I honestly didn't have time to ask more about how DVFS works on the Pi 5 (nor Pi 4) in the past few weeks, but there is another thread in the firmware repo with at least a little more detail: https://github.com/raspberrypi/firmware/issues/1825
The delta can apparently be used to overvolt or undervolt the SoC, but DVFS on its own should be good enough to handle modest over/underclocks. I still have some testing to do, but may post a blog post with what I've learned so far at least (since it seems like every other YouTuber is posting their overclocking videos this week... I've been painting my new office all weekend lol).
Also, I'm not sure if this is new or not, but there's a section on DVFS in the Pi docs now.
@ThomasKaiser / @theofficialgman - I honestly didn't have time to ask more about how DVFS works on the Pi 5 (nor Pi 4) in the past few weeks, but there is another thread in the firmware repo with at least a little more detail: raspberrypi/firmware#1825
Yeah that repo confirms it... its fully proprietary. Thats really unfortunate and significantly hampers the tinkerers ability to see inside the system and how it works. They probably have "speedo" equivalent data burned into the SOC which represents the binning of each component (as tested at the factory) but there is no way for us to know short of decompiling/RE the firmware blobs.
Compare that to tegra x1 and DVFS all open source in the corresponding kernel driver (switchroot fork linked here but it comes from nvidia) https://gitlab.com/switchroot/kernel/l4t-kernel-4.9/-/tree/linux-dev/drivers/soc/tegra
I'm not sure if this is new or not, but there's a section on DVFS in the Pi docs now.
The document's history is on Github.
Since someone already tried to overclock BCM2712 to 3100 MHz (arm_freq=3100
) I find a look at the DVFS OPP table interesting since it shows that clockspeeds higher than 3000 are currently ignored and that the supply voltages do not really meet expectations (all OPP above 1800 at the same 1V value):
Cpufreq OPP: 3100 ThreadX: 3000 Measured: 2998 @ 1.0000V (-3.3%)
Cpufreq OPP: 3000 ThreadX: 3000 Measured: 2998 @ 1.0000V
Cpufreq OPP: 2900 ThreadX: 2900 Measured: 2898 @ 1.0000V
Cpufreq OPP: 2800 ThreadX: 2800 Measured: 2798 @ 1.0000V
Cpufreq OPP: 2700 ThreadX: 2700 Measured: 2698 @ 1.0000V
Cpufreq OPP: 2600 ThreadX: 2600 Measured: 2598 @ 1.0000V
Cpufreq OPP: 2500 ThreadX: 2500 Measured: 2498 @ 1.0000V
Cpufreq OPP: 2400 ThreadX: 2400 Measured: 2398 @ 1.0000V
Cpufreq OPP: 2300 ThreadX: 2300 Measured: 2298 @ 1.0000V
Cpufreq OPP: 2200 ThreadX: 2200 Measured: 2198 @ 1.0000V
Cpufreq OPP: 2100 ThreadX: 2100 Measured: 2098 @ 1.0000V
Cpufreq OPP: 2000 ThreadX: 2000 Measured: 1998 @ 1.0000V
Cpufreq OPP: 1900 ThreadX: 1900 Measured: 1898 @ 1.0000V
Cpufreq OPP: 1800 ThreadX: 1800 Measured: 1798 @ 1.0000V
Cpufreq OPP: 1700 ThreadX: 1700 Measured: 1698 @ 0.9994V
Cpufreq OPP: 1600 ThreadX: 1600 Measured: 1598 @ 0.9907V
Cpufreq OPP: 1500 ThreadX: 1500 Measured: 1498 @ 0.9821V
Cpufreq OPP: 1400 ThreadX: 1500 Measured: 1498 @ 0.9735V (+7.0%)
Cpufreq OPP: 1300 ThreadX: 1500 Measured: 1498 @ 0.9648V (+15.2%)
Cpufreq OPP: 1200 ThreadX: 1500 Measured: 1498 @ 0.9562V (+24.8%)
Cpufreq OPP: 1100 ThreadX: 1500 Measured: 1498 @ 0.9476V (+36.2%)
Cpufreq OPP: 1000 ThreadX: 1500 Measured: 1498 @ 0.7200V (+49.8%)
But since this attempt was using over_voltage=8
it seems better to wait for OC attempts w/o over_voltage
settings or at least choosing over_voltage_delta
instead.
BTW: ThreadX does not only refuse to use clockspeeds above 3000 MHz but also below 1500 MHz which is something not really expected since between 1400 and 1000 MHz supply voltages are reported to get lower and lower while cpufreq remains at 1500 MHz. Can be also observed w/o any OC at all:
Cpufreq OPP: 2400 ThreadX: 2400 Measured: 2398 @ 0.9094V
Cpufreq OPP: 2300 ThreadX: 2300 Measured: 2298 @ 0.8988V
Cpufreq OPP: 2200 ThreadX: 2200 Measured: 2198 @ 0.8882V
Cpufreq OPP: 2100 ThreadX: 2100 Measured: 2098 @ 0.8775V
Cpufreq OPP: 2000 ThreadX: 2000 Measured: 1998 @ 0.8669V
Cpufreq OPP: 1900 ThreadX: 1900 Measured: 1898 @ 0.8563V
Cpufreq OPP: 1800 ThreadX: 1800 Measured: 1798 @ 0.8457V
Cpufreq OPP: 1700 ThreadX: 1700 Measured: 1698 @ 0.8351V
Cpufreq OPP: 1600 ThreadX: 1600 Measured: 1598 @ 0.8244V
Cpufreq OPP: 1500 ThreadX: 1500 Measured: 1498 @ 0.8138V
Cpufreq OPP: 1400 ThreadX: 1500 Measured: 1498 @ 0.8032V (+7.0%)
Cpufreq OPP: 1300 ThreadX: 1500 Measured: 1498 @ 0.7926V (+15.2%)
Cpufreq OPP: 1200 ThreadX: 1500 Measured: 1498 @ 0.7820V (+24.8%)
Cpufreq OPP: 1100 ThreadX: 1500 Measured: 1498 @ 0.7713V (+36.2%)
Cpufreq OPP: 1000 ThreadX: 1500 Measured: 1498 @ 0.7200V (+49.8%)
If at 1500 MHz the supply voltage should be 0.81V while dropping as low as 0,72V in reality seems like undervoltage to me.
@ThomasKaiser - Thanks for that; I've also published some more data from my own (more cursory) testing this morning on my blog, since overclocking is making the rounds on YouTube: Overclocking and Underclocking the Raspberry Pi 5
@geerlingguy can you make sure to get OpenGLES too please?
In glcapsviewer make sure to upload both the OpenGL Default and OpenGLES 3.0 Context results
@geerlingguy incase you missed it ^. Thanks for the OpenGL Default and Vulkan uploads by the way 😄
@theofficialgman - I'm remote this week so can't connect the Pi 5 to a display right now, SSH only — when I try running the viewer it seems to require Qt/a display, is there any way to do it headless?
pi@pi5:~/Downloads/vktest $ ./glcapsviewer
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Aborted
No I don't think so. Don't worry about it till you have physical access to the device. I was just pinging incase my request got lost in this thread.
@theofficialgman - See:
@FCLC -
vainfo
returns:pi@pi5:~/Downloads/vktest $ sudo vainfo error: XDG_RUNTIME_DIR is invalid or not set in the environment. libva info: VA-API version 1.17.0 libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null) vaInitialize failed with error code -1 (unknown libva error),exit
You shouldn't need sudo here, but it shouldn't hurt. Could be that they haven't enabled vaapi and that they've only got v4l2 up and running right now
EDIT:
Maybe try v4l2-ctl --list-formats-ext?
Did v4l2-ctl --list-formats-ext
produce anything?
A bit more on the RP1 silicon: RP1: the silicon controlling Raspberry Pi 5 I/O, designed here at Raspberry Pi
A bit more on the RP1 silicon
Nice, let's try to compile a list of RP1 3rd party IP blocks:
What specification should we be looking for when selecting an SD card in order to take advantage of the newer SD H/W? The term SDR104
seems not to be listed in the Amazon listings.
Thanks!
Edit: This comment started discussion of SD cards that is meandering off topic for this thread. Please use https://github.com/HankB/Raspberry-Pi-storage for further discussion relating to storage for the Pi 5 (and other Raspberry Pis.)
According to Wikipedia, UHS-I cards supporting SDR104 should be labeled UHS104. You might look for cards labeled UHS-I and claiming speeds greater than 50MB/s as that is the required speed for UHS-I (SDR50).
On Sun, Oct 8, 2023, 10:29 AM HankB @.***> wrote:
What specification should we be looking for when selecting an SD card in order to take advantage of the newer SD H/W? The term SDR104 seems not to be listed in the Amazon listings.
Thanks!
— Reply to this email directly, view it on GitHub https://github.com/geerlingguy/sbc-reviews/issues/21#issuecomment-1752042120, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPEX7BWNECLNCUN4G2VZYTX6K2GLAVCNFSM6AAAAAA5KNQMO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJSGA2DEMJSGA . You are receiving this because you were mentioned.Message ID: @.***>
We can use vkpeak to measure the peak computing flops of the v3d GPU on rpi4 and rpi5. Thanks ! https://github.com/nihui/vkpeak
What specification should we be looking for when selecting an SD card in order to take advantage of the newer SD H/W?
When keeping in mind which sort of I/O the more important is then choosing A1 or A2 rated cards in any case since you always want high random IOPS! And then of course cards that exceed 100 MB/s both read and write, see this search through available TF cards for example. I personally would also choose "10 years warranty" as a requirement and then we're here with only two reputable manufacturers left.
But always keep in mind that there's no guarantee you will be buying genuine cards so always test them immediately after purchase for counterfeit/fake using f3 or H2testw in case you're using Windows.
The current best cards objectively are the Samsung pro plus (and pro ultimate if you want the guaranteed 10 year life). Sandisks as seen through long term testing get slower over time with random read/writes, Samsungs do not nearly as quickly.
I'll just whine a bit that the warranty is useless if it cannot be claimed. I have a 32GB EVO Plus (microSD) that malfunctioned. Their warranty page wants a 15 character serial number and the card has a 12 or 13 serial number. I can't find any way to contact Samsung support. NB, I have successfully claimed warranty on a 500GB SATA SSD. I still prefer Samsung storage products.
I have a 32GB EVO Plus (microSD) that malfunctioned. Their warranty page wants a 15 character serial number and the card has a 12 or 13 serial number
Congratulations! You're another victim of counterfeit flash storage. Check your card with 'sbc-bench -S' and lets keep this Github issues being focused on RPi 5B.
Would be nice to see some benchmarks of SuperTuxKart at various graphics settings, to get a feel for how powerful the GPU is in real-world applications.
@qwertychouskie - Already have that in my YouTube video: https://www.youtube.com/watch?v=nBtOEmUqASQ
To be honest after buying Samsung Pro & Pro Plus A2 cards and finding them slower than Mymemory own brand A1 and never getting failures apart from cards heavily reimaged due testing OS's and SBC I think just get any but make sure the retailer is reputable and just stay away from ebay & aliexpress buys.
https://www.mymemory.co.uk/mymemory-plus-64gb-micro-sd-card-sdxc-4k-a1-uhs-1-v30-u3-adapter-100mb-s.html https://www.mymemory.co.uk/kingston-64gb-canvas-select-plus-micro-sd-card-sdxc-a1-c10-100mb-s.html https://www.mymemory.co.uk/sandisk-64gb-ultra-lite-micro-sd-card-sdxc-uhs-i-u1-a1-100mb-s.html https://www.mymemory.co.uk/samsung-evo-plus-64gb-4k-ready-microsdxc-memory-card-uhs-i-u1-with-sd-adapter-130mb-s.html
Unless the mymemory 'ownbrand' are something special all cards are relatively in the same ballpark and just minimise writes by keeping your log dir in a zram dir, I really like this util as it creates a read only system that writes once on shutdown. https://github.com/ecdye/zram-config I am not sure why Raspberry don't do more utils with Zram, PS have a backup file swap just in case Zram hits something large and heavily compressed as on those rare occasions it will write to SD or fail. Its very subjective and likely some have certain taste but minimising writes with some utils and use any... The more expensive cards often don't equate to perf and likely a bit Stella Artois!
My apologies to those of us who don't care to see side discussions about SD cards polluting this thread. @ThomasKaiser is absolutely correct. There is clearly interest in this topic and I have created a place to discuss that at https://github.com/HankB/Raspberry-Pi-storage. I intend to delete my comment that led us astray and provide a link for further discussion and encourage others to do the same to clean up the discussion here.
Thanks!
One thing I like to use to test GPUs is the x86 tool, GpuTest. I find it works fine under box64, although the gputest_gui.py
file needs to be marked executable and have one python2 print
statement replaced with a python3 print()
function call. It also needs the TK library installed (python3-tk?), and perhaps an import adjusted: import tkinter as tk
I especially like the looks of the "Pixmark Volplosion" animation.
For comparison (all at the default window size of 1024x640):
As for potential voltage drops on the USB ports I received no answer but found a statement in the official documentation: "You can’t see USB current or anything else connected directly to 5V because this bypasses the PMIC".
We all (should) know Ohm's law still exists, 5V at above 3A is challenging and I'm really curious what that means for USB consumers once the current at the PSU exceeds 3A or even 4A.
In the meantime I tried to finish voltage/consumption monitoring for RPi 5B in sbc-bench so it would be really interesting to run a simple sbc-bench -m
while having heavy USB consumers attached. Should look somewhat like this then:
root@raspberrypi:/home/pi# sbc-bench.sh -m
BCM2712, RPi 5 Model B Rev 1.0 / BCM2712, Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 1000 2400 Cortex-A76 / r4p1
1 0 0 1000 2400 Cortex-A76 / r4p1
2 0 0 1000 2400 Cortex-A76 / r4p1
3 0 0 1000 2400 Cortex-A76 / r4p1
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (cpu-thermal)
Time fake/real load %cpu %sys %usr %nice %io %irq Temp VCore PMIC DC(V)
21:49:12: 1000/1500MHz 0.00 0% 0% 0% 0% 0% 0% 40.4°C 0.8138V 5.1W 5.18V
21:49:17: 2400/2400MHz 0.05 15% 15% 0% 0% 0% 0% 41.5°C 0.9094V 8.2W 5.10V
21:49:22: 2400/2400MHz 0.18 22% 15% 7% 0% 0% 0% 43.2°C 0.9094V 9.0W 5.06V
...
@geerlingguy does time permit to do a quick test after updating sbc-bench (-u
-switch) with some heavy consumers? All it needs is some heavy consumption at RPi 5B while running sbc-bench -m
in parallel.
And while the PMIC on RPi 5B doesn't allow for measuring voltage available at the USB ports attaching your Rock 5B (powered by one of RPi 5B's USB3 ports) and running sbc-bench -m
there in parallel would do.
How about running a Pi 4 off one of the USB ports with a consumption meter?
pi@pi5:~/Downloads $ sudo ./sbc-bench.sh -m
BCM2712, Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 1000 2400 Cortex-A76 / r4p1
1 0 0 1000 2400 Cortex-A76 / r4p1
2 0 0 1000 2400 Cortex-A76 / r4p1
3 0 0 1000 2400 Cortex-A76 / r4p1
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (cpu-thermal)
Time fake/real load %cpu %sys %usr %nice %io %irq Temp VCore PMIC DC(V)
16:17:43: 2400/2400MHz 0.84 9% 0% 8% 0% 0% 0% 46.9°C 0.9100V 12.5W 5.09V
16:17:48: 1000/1500MHz 0.77 0% 0% 0% 0% 0% 0% 46.3°C 0.7750V 12.1W 5.09V
16:17:53: 1000/1500MHz 0.71 0% 0% 0% 0% 0% 0% 44.1°C 0.7200V 12.4W 5.09V
16:17:58: 1000/1500MHz 0.65 0% 0% 0% 0% 0% 0% 45.8°C 0.7200V 12.8W 5.09V
16:18:03: 1000/1500MHz 0.60 0% 0% 0% 0% 0% 0% 44.6°C 0.7200V 11.9W 5.09V
16:18:08: 1100/1500MHz 0.55 0% 0% 0% 0% 0% 0% 45.2°C 0.7750V 12.5W 5.10V
16:18:14: 1000/1500MHz 0.51 0% 0% 0% 0% 0% 0% 45.8°C 0.7200V 11.8W 5.08V
16:18:19: 1000/1500MHz 0.47 0% 0% 0% 0% 0% 0% 45.8°C 0.7200V 11.7W 5.09V
16:18:24: 1000/1500MHz 0.43 0% 0% 0% 0% 0% 0% 45.8°C 0.7200V 12.3W 5.09V
16:18:29: 1000/1500MHz 0.39 0% 0% 0% 0% 0% 0% 45.2°C 0.7200V 12.3W 5.09V
16:18:34: 1000/1500MHz 0.36 0% 0% 0% 0% 0% 0% 45.8°C 0.7750V 11.7W 5.09V
16:18:39: 1000/1500MHz 0.33 0% 0% 0% 0% 0% 0% 46.3°C 0.7200V 12.7W 5.09V
16:18:45: 1000/1500MHz 0.31 0% 0% 0% 0% 0% 0% 45.8°C 0.7200V 12.4W 5.09V
16:18:50: 1000/1500MHz 0.28 0% 0% 0% 0% 0% 0% 46.3°C 0.7200V 12.5W 5.09V
I also ran stress-ng -c 0
on the Pi 4 while it was running off the Pi 5, but it seemed to go into a soft cycle on power, as it went between consuming 5W and 2W.
I tried with -c 1
through -c 4
, and it was stable up to 3 cores, just under 1A at 5.05v on the USB meter. At 4 cores it was just over 1A and it kept cycling. Any other tests you'd like me to try on there?
Basic information
Linux/system information
Benchmark results
CPU
Power
stress-ng --matrix 0
): 9.7 Wtop500
HPL benchmark: 11 W (2.75 Gflops/W)Disk
SanDisk Extreme 128GB microSD
Kioxia XG8 1TB NVMe at PCIe Gen 2
Kioxia XG8 1TB NVMe at PCIe Gen 3
Single SanDisk Extreme PRO USB 3.1 Flash Drive
2x SanDisk Extreme PRO USB 3.1 Flash Drives (simultaneous)
Run benchmark on any attached storage device (e.g. eMMC, microSD, NVMe, SATA) and add results under an additional heading. Download the script with
curl -o disk-benchmark.sh [URL_HERE]
and runsudo DEVICE_UNDER_TEST=/dev/sda DEVICE_MOUNT_PATH=/mnt/sda1 ./disk-benchmark.sh
(assuming the device issda
).Network
Built-in Ethernet
iperf3 -c $SERVER_IP
: 938 Mbpsiperf3 --reverse -c $SERVER_IP
: 942 Mbpsiperf3 --bidir -c $SERVER_IP
: 930 Mbps up, 600 Mbps downBuilt-in WiFi
iperf3 -c $SERVER_IP
: 186 Mbpsiperf3 --reverse -c $SERVER_IP
: 207 Mbpsiperf3 --bidir -c $SERVER_IP
: 2.15 Mbps up, 206 Mbps downUSB 3.0 Pluggable USBC-E2500 2.5 Gbps Adapter
iperf3 -c $SERVER_IP
: 1.55 Gbpsiperf3 --reverse -c $SERVER_IP
: 300 Mbpsiperf3 --bidir -c $SERVER_IP
: 1.56 Gbps up, 153 Mbps downASUS XG-C100C 10G Network Adapter (Aquantia AQC107)
iperf3 -c $SERVER_IP
: 5.63 Gbpsiperf3 --reverse -c $SERVER_IP
: 6.05 Gbpsiperf3 --bidir -c $SERVER_IP
: 4.40 Gbps up, 2.50 Gbps downGPU
Compatibility reports:
Memory
tinymembench
results:Click to expand memory benchmark result
``` tinymembench v0.4.10 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 5676.0 MB/s (1.9%) C copy backwards (32 byte blocks) : 5649.5 MB/s (0.6%) C copy backwards (64 byte blocks) : 5688.0 MB/s (0.6%) C copy : 4870.3 MB/s (0.2%) C copy prefetched (32 bytes step) : 4808.4 MB/s C copy prefetched (64 bytes step) : 4819.7 MB/s (0.2%) C 2-pass copy : 4887.0 MB/s (0.6%) C 2-pass copy prefetched (32 bytes step) : 4849.2 MB/s C 2-pass copy prefetched (64 bytes step) : 4845.1 MB/s C fill : 13672.2 MB/s (0.5%) C fill (shuffle within 16 byte blocks) : 13655.6 MB/s (0.5%) C fill (shuffle within 32 byte blocks) : 13697.6 MB/s (0.5%) C fill (shuffle within 64 byte blocks) : 13703.3 MB/s (0.4%) NEON 64x2 COPY : 4813.8 MB/s (0.1%) NEON 64x2x4 COPY : 4832.2 MB/s (0.1%) NEON 64x1x4_x2 COPY : 4830.8 MB/s (0.1%) NEON 64x2 COPY prefetch x2 : 4298.5 MB/s NEON 64x2x4 COPY prefetch x1 : 4335.5 MB/s NEON 64x2 COPY prefetch x1 : 4306.5 MB/s NEON 64x2x4 COPY prefetch x1 : 4336.0 MB/s --- standard memcpy : 4805.4 MB/s standard memset : 13676.9 MB/s (0.6%) --- NEON LDP/STP copy : 4793.9 MB/s NEON LDP/STP copy pldl2strm (32 bytes step) : 4821.9 MB/s NEON LDP/STP copy pldl2strm (64 bytes step) : 4829.9 MB/s NEON LDP/STP copy pldl1keep (32 bytes step) : 4811.7 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 4812.1 MB/s NEON LD1/ST1 copy : 4818.2 MB/s NEON STP fill : 13659.2 MB/s (0.5%) NEON STNP fill : 13683.3 MB/s (0.4%) ARM LDP/STP copy : 4818.7 MB/s ARM STP fill : 13557.6 MB/s ARM STNP fill : 13682.7 MB/s (0.4%) ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 0.0 ns / 0.0 ns 131072 : 1.1 ns / 1.5 ns 262144 : 1.6 ns / 2.0 ns 524288 : 1.9 ns / 2.2 ns 1048576 : 8.3 ns / 11.2 ns 2097152 : 12.2 ns / 14.4 ns 4194304 : 54.9 ns / 84.1 ns 8388608 : 86.8 ns / 119.4 ns 16777216 : 103.0 ns / 131.6 ns 33554432 : 112.9 ns / 138.3 ns 67108864 : 118.7 ns / 142.2 ns ```Phoronix Test Suite
Results from pi-general-benchmark.sh:
Other Data
Crypto performance as measured by OpenSSL (see sbc-bench ARMv8 Crypto Extensions):
PTP Hardware Timestamping support via Cadence GEM: