Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Bootable 64-bit RPi3 Gentoo image (OpenRC/Xfce/VC4) UPDATED
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 14, 15, 16  
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 215

PostPosted: Wed Aug 22, 2018 5:24 pm    Post subject: Reply with quote

NeddySeagoon,

I didn't realize the Portage tree was already available in squashfs form - that's helpful to know, as I the version I distribute isn't modified from that much (just some additional signed hash verification, which is redundant now gemato has gone live - all the other customizations are done via overlay).

antonlacon,

thanks for the scripts, I'll take a look.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
orion777
Apprentice
Apprentice


Joined: 15 Mar 2017
Posts: 155
Location: Riga, Latvia

PostPosted: Sat Aug 25, 2018 6:00 am    Post subject: Reply with quote

Where are PYTHON TARGETS are stored in?
Now my system (probably after casually made config update by emerge) require python 3.6 install. This, itself, cause massive reinstallation of installed packages to enable python 3.6 use flag, so I afraid of genup which will run --newuse.
So, how to roll back python targets to 2.7 and 3.5 only? Gentoo wiki refers to files, that does not exists in this setup..
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 41320
Location: 56N 3W

PostPosted: Sat Aug 25, 2018 9:06 am    Post subject: Reply with quote

orion777,

PYTHON_TARGETS is a use expand and can be set in make.conf

Code:
PYTHON_TARGETS="python2_7 python3_6"
PYTHON_SINGLE_TARGET="python3_4"


That's an example, which I had commented out in my make.conf.

Only use these settings to delay the inevitable. You will have to do the upgrade sometime.

Doesn't genup install binaries?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 215

PostPosted: Sat Aug 25, 2018 5:09 pm    Post subject: Reply with quote

orion777,

on the gentoo-on-rpi3-64bit image, PYTHON_TARGETS (and PYTHON_SINGLE_TARGET) is usually controlled by the "base" parent profile, via /usr/portage/profiles/base/make.defaults. As this news article states:
Quote:
On 2018-06-22, Python 3.6 will replace Python 3.5 in the default Python
targets for Gentoo systems. The new default targets will be:

PYTHON_TARGETS="python2_7 python3_6"
PYTHON_SINGLE_TARGET="python3_6"

However, I have temporarily overridden PYTHON_TARGETS in the custom profile used by the image (you can see the edit in the file /usr/local/portage/rpi3/profiles/targets/rpi3/make.defaults on your system; this custom profile inherits inter alia from the base profile). This means that currently, you will have:
Code:
PYTHON_TARGETS="python2_7 python3_5 python3_6"
PYTHON_SINGLE_TARGET="python3_6"
(You can check this via emerge --info) This overlap with 3.5 was done to prevent issues during the cutover to 3.6; it will be removed in a little while.

On the image, a gated copy of the Portage tree is used. What happens during the weekly update cycle is that my RPi3 buildserver updates its copy of the Portage tree (using webrsync-gpg) from upstream, and then attempts a full genup run (which builds any upgraded packages, and rebuilds packages with changed USE flags etc - the genup manpage is available here). As the server runs with buildpkg set in FEATURES, successfully built packages automatically create a matching (local) binary package. If there are any issues, I add custom USE flags / package.mask entries etc. into the custom profile, until the build goes through OK. I then test any newly upgraded major packages (GIMP etc.) to check nothing major appears broken. If good, the binary packages are rsync'd up to the binhost (https://isshoni.org/pi64pie, in this case), the Portage tree snapshot is signed (using porthash) and also rsync'd to the isshoni server, and any commits to the custom profile (new masks etc) are pushed to GitHub.

When you run genup on your copy of the image, it will update the rpi3-overlay (which will pull in any custom masks etc. from GitHub) and also the 'gated' copy of the Portage tree. It will then attempt to run a full @world update, and, since the image has getbinpkg set in FEATURES, will check the https://isshoni.org/pi64pie binhost for binary packages (with matching USE flags etc.) before building locally.

As such, NeddySeagoon is correct, in that when you hit a major USE flag change (such as the move to python3_6), appropriately built (or rebuilt) binary packages should already be available on the binhost, so the upgrade should not be painful. Of course, if you have a lot of local USE flag changes, or custom-installed packages, you may still have some local compilation work to do.

I discuss the weekly gated tree, custom profile etc. in more detail here.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
orion777
Apprentice
Apprentice


Joined: 15 Mar 2017
Posts: 155
Location: Riga, Latvia

PostPosted: Sun Aug 26, 2018 6:24 pm    Post subject: Reply with quote

Thank you!
However, maybe something is wrong in my 34 days old system, but emerge --sync returns:
Code:
=== Sync completed for gentoo
q: Updating ebuild cache for /usr/portage ...
q: Finished 35575 entries in 0.850039 seconds
Checking master signature on gentoo repo...
porthash: Using public key 09F2FF455D90CAF4
porthash: Entering /usr/portage...
porthash: Verifying existing hashfile...
porthash: Hashfile signature and format valid
porthash: Computing master hash of /usr/portage, may take some time...
porthash: error: Hashfile and computed hashes DIFFER
Killing parent process...

First time it was called by genup, next it was called manually.
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 215

PostPosted: Sun Aug 26, 2018 6:36 pm    Post subject: Reply with quote

orion777,

it's my own repository check (porthash, which I rolled out before gemato was fully deployed) causing that error message. Could you please post the output of "porthash --version" and the contents of /usr/portage/repo.hash on your system (if you have a modern copy of porthash, it may have renamed this automatically to /usr/portage/local/repo.hash, to avoid clashing with gemato's checksums, so you may need to look there instead)? Thanks.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
ericbish
n00b
n00b


Joined: 27 Apr 2018
Posts: 10

PostPosted: Mon Aug 27, 2018 3:15 pm    Post subject: Reply with quote

Sakaki wrote:
orion777,

it's my own repository check (porthash, which I rolled out before gemato was fully deployed) causing that error message. Could you please post the output of "porthash --version" and the contents of /usr/portage/repo.hash on your system (if you have a modern copy of porthash, it may have renamed this automatically to /usr/portage/local/repo.hash, to avoid clashing with gemato's checksums, so you may need to look there instead)? Thanks.


I had the same problem on multiple Gentoo systems, not just this one.

https://forums.gentoo.org/viewtopic-t-1085580.html?sid=89aace0cb4eb612bf8c0f77a608e2ccc
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 215

PostPosted: Mon Aug 27, 2018 3:43 pm    Post subject: Reply with quote

ericbish wrote:

I had the same problem on multiple Gentoo systems, not just this one.

https://forums.gentoo.org/viewtopic-t-1085580.html?sid=89aace0cb4eb612bf8c0f77a608e2ccc


Were your other systems also arm64 using the rpi3-overlay, and/or based on gentoo-on-rpi3-64bit?

By default, the porthash repo check is only used (as far as I know) by my gated versions of the Portage tree used with the RPi3 and the Excito B2 and B3 miniservers. If you are seeing it, try deleting /usr/portage/metadata/timestamp.x and then syncing again. You can cat the /usr/portage/repo.hash on your system to see its timestamp also (this may be in /usr/portage/local/repo.hash if you are running a modern version of porthash).
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
ericbish
n00b
n00b


Joined: 27 Apr 2018
Posts: 10

PostPosted: Mon Aug 27, 2018 4:13 pm    Post subject: Reply with quote

Sakaki wrote:
ericbish wrote:

I had the same problem on multiple Gentoo systems, not just this one.

https://forums.gentoo.org/viewtopic-t-1085580.html?sid=89aace0cb4eb612bf8c0f77a608e2ccc


Were your other systems also arm64 using the rpi3-overlay, and/or based on gentoo-on-rpi3-64bit?

By default, the porthash repo check is only used (as far as I know) by my gated versions of the Portage tree used with the RPi3 and the Excito B2 and B3 miniservers. If you are seeing it, try deleting /usr/portage/metadata/timestamp.x and then syncing again. You can cat the /usr/portage/repo.hash on your system to see its timestamp also (this may be in /usr/portage/local/repo.hash if you are running a modern version of porthash).


Nope, they were gentoo x86_64 systems, there is a thread with the same thing in the portage forum. There is a bug about it, can't remember the bug ID. I never could figure out exactly what caused it, but clearing /usr/portage and rerunning genup on your arm64 image (or emerge --sync on the x86_64 systems) cleared it up. Cutting the timestamp did not help.
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 215

PostPosted: Mon Aug 27, 2018 5:42 pm    Post subject: Reply with quote

ericbish wrote:

Nope, they were gentoo x86_64 systems, there is a thread with the same thing in the portage forum. There is a bug about it, can't remember the bug ID. I never could figure out exactly what caused it, but clearing /usr/portage and rerunning genup on your arm64 image (or emerge --sync on the x86_64 systems) cleared it up. Cutting the timestamp did not help.


That's odd. There only way that porthash gets called, afaik, is via this repo.postsync.d hook, which on the rpi3 is set up by the app-portage/rpi3-check-portage package from my rpi3-overlay. Did you copy your /usr/portage and /etc/portage directories over to an x86_64 machine by any chance, perhaps to use as a 'starter' configuration?
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
ericbish
n00b
n00b


Joined: 27 Apr 2018
Posts: 10

PostPosted: Mon Aug 27, 2018 5:48 pm    Post subject: Reply with quote

Sakaki wrote:
ericbish wrote:

Nope, they were gentoo x86_64 systems, there is a thread with the same thing in the portage forum. There is a bug about it, can't remember the bug ID. I never could figure out exactly what caused it, but clearing /usr/portage and rerunning genup on your arm64 image (or emerge --sync on the x86_64 systems) cleared it up. Cutting the timestamp did not help.


That's odd. There only way that porthash gets called, afaik, is via this repo.postsync.d hook, which on the rpi3 is set up by the app-portage/rpi3-check-portage package from my rpi3-overlay. Did you copy your /usr/portage and /etc/portage directories over to an x86_64 machine by any chance, perhaps to use as a 'starter' configuration?



Nope, both those other gentoo boxes were up years before I built the pi. Plus other folks have seen the issue (at least on other on the Pi, and at least a couple of others on x86_64), hence the bug report. It may be two different issues with a common similarity (the manifest failing hash) and just coincidence they came up at the same time......but either way, in both cases, reconstructing the /usr/portage directory and rerunning genup/emerge sync corrected it.
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 215

PostPosted: Mon Aug 27, 2018 6:09 pm    Post subject: Reply with quote

ericbish,

Searching Gentoo bugzilla for porthash doesn't seem to bring up anything - did you by any chance contribute to the original bug report you mentioned? If so would you mind looking up the bug ID so I can investigate this further. Many thanks!
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
ericbish
n00b
n00b


Joined: 27 Apr 2018
Posts: 10

PostPosted: Mon Aug 27, 2018 6:36 pm    Post subject: Reply with quote

Sakaki wrote:
ericbish,

Searching Gentoo bugzilla for porthash doesn't seem to bring up anything - did you by any chance contribute to the original bug report you mentioned? If so would you mind looking up the bug ID so I can investigate this further. Many thanks!



For the life of me, I cannot find it again. I came across it originally IIRC, dumping the error from one of the x86_64 boxes into google, then chasing through a ton of threads regarding the portage sync verification changes and such from a while ago. Then from there, I got sucked into the rabbit hole and somewhere among posts about manifest hash mismatches, there was a bug ID about it. About then I just threw in the towel and blew away portage, and recreated it......problem gone.
Back to top
View user's profile Send private message
orion777
Apprentice
Apprentice


Joined: 15 Mar 2017
Posts: 155
Location: Riga, Latvia

PostPosted: Tue Aug 28, 2018 6:01 am    Post subject: Reply with quote

Sakaki wrote:
orion777,

it's my own repository check (porthash, which I rolled out before gemato was fully deployed) causing that error message. Could you please post the output of "porthash --version" and the contents of /usr/portage/repo.hash on your system (if you have a modern copy of porthash, it may have renamed this automatically to /usr/portage/local/repo.hash, to avoid clashing with gemato's checksums, so you may need to look there instead)? Thanks.

Code:
pi64 /usr/sbin # porthash --version
1.0.6
pi64 /usr/sbin # cat /usr/portage/repo.hash
Hash format: 1
Date: 2018-08-25 17:47
Hash: sha512sum
Metadata covered: no
5cab65371634c7824a5d4ea3685d5d5518b211d70f371ca412d7a7a99261d568d6aa535d09b9a63bc5942ed0022c3a799c61f0b979009c7d75cf4c88c2e165bb  -
pi64 /usr/sbin # cat /usr/portage/local/repo.hash
Hash format: 1
Date: 2018-07-20 12:22
Hash: sha512sum
Metadata covered: no
409c1e0dd2b29b5f7af0929fa64a2970790edb5eb27a52dba5126098f7537d85ccc4a2422147909fe6dc391d9af38ef90bea2570d905ea131b84d5bf7698ff8a  -
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 215

PostPosted: Tue Aug 28, 2018 12:07 pm    Post subject: Reply with quote

orion777, ericbish (and all users of the gentoo-on-rpi3-64bit image) -

OK, first of all, an apology - there is a bug (introduced by me) in porthash-1.0.6, that in turn is causing genup to fail. I've put a fix into porthash-1.0.7, and posted a news article via the rpi3-overlay, and a GitHub issue with the resolution, also copied below. ><

Diagnostics

Look near the end of your /var/log/latest-genup-run.log file to see if the issue affects you; if it does, you'll see something similar to the below:
Code:
=== Sync completed for gentoo
q: Updating ebuild cache for /usr/portage ...
q: Finished xxx entries in yyy seconds
Checking master signature on gentoo repo...
porthash: Using public key 09F2FF455D90CAF4
porthash: Entering /usr/portage...
porthash: Verifying existing hashfile...
porthash: Hashfile signature and format valid
porthash: Computing master hash of /usr/portage, may take some time...
porthash: error: Hashfile and computed hashes DIFFER
Killing parent process...


Fixing the Issue

To address the issue, open a terminal and issue the following commands, as the root user, on your rpi3:
(if running as demouser, prefix the following commands with sudo):
Code:
pi64 ~ # emaint sync --repo sakaki-tools
pi64 ~ # emerge --update --oneshot --verbose app-portage/porthash

This should upgrade porthash to >= 1.0.7. Once this is done, your automatic weekly genup run should start working again.

That's it!

Background to the Issue (Optional Reading)

The porthash utility creates, or by default checks, the validity of a repository master hash (repo.hash) and counterpart digital signature (repo.hash.asc), to allow verification of a Portage tree distributed over an unauthenticated channel such as rsync. There was no such 'official' facility in Gentoo when the tool was originally deployed.

However, when Gentoo started rolling out its official app-portage/gemato manifest verification tool, porthash was modified (at v1.0.6) to migrate the location of the repo.hash{,.asc} files, from the top level /usr/portage/ directory (where they would clash with gemato) to /usr/portage/local/, which gemato ignores.

Unfortunately, during an rsync process of the Portage tree with the isshoni.org binhost, this local directory is not synced by default, but since (due to faulty logic; my bad) porthash-1.0.6 checks this location first when looking for the repo.hash{,.asc} files, the next time the tree is synced after the files have been migrated, the old (stale) /usr/portage/local/repo.hash{,.asc} files will be checked (not the fresh /usr/portage/repo.hash{,.asc} versions), and accordingly the signature verification will fail, and genup will halt with an error. (orion777 - you can see the date difference in the two repo.hash files you posted)

This error is addressed in >=porthash-1.0.7, so upgrading this single package is sufficient to fix the problem.

Thanks both for reporting this issue, and apologies again to all users for any inconvenience caused
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
orion777
Apprentice
Apprentice


Joined: 15 Mar 2017
Posts: 155
Location: Riga, Latvia

PostPosted: Sat Sep 01, 2018 9:15 am    Post subject: Reply with quote

Yes, seems working!
Back to top
View user's profile Send private message
roylongbottom
n00b
n00b


Joined: 13 Feb 2017
Posts: 33
Location: Essex, UK

PostPosted: Thu Sep 13, 2018 10:23 am    Post subject: Raspberry Pi 3B+ Stress Tests Reply with quote

Raspberry Pi 3B+ Stress Tests

I have finished running my benchmarks on the Raspberry Pi 3B+. A full report is available from ResearchGate:

https://www.researchgate.net/publication/327467963_Raspberry_Pi_3B_32_bit_and_64_bit_Benchmarks_and_Stress_Tests?_iepl%5BviewId%5D=RiEmnDoCO1cfHp4h46lXJY4T&_iepl%5Bcontexts%5D%5B0%5D=projectUpdatesLog&_iepl%5BtargetEntityId%5D=PB%3A327467963&_iepl%5BinteractionType%5D=publicationTitle

The last programs run were my Stress Tests that, at least, identify the 3B+ thermal characteristics. These are single core programs with input parameters for duration and test selection, with multiple copies run for maximum loading, and an updated monitor, measuring CPU MHz, temperature and core voltage. The main programs are one running integer arithmetic, another with floating point and My OpenGL program. The first exercise was with the 3B+ card installed in a plastic case, with no heatsink on the CPU.

Following is an example results from my monitoring program, whilst running four copies of the integer stress test program. These are instantaneous samples that can vary up and down within the sampling period. Above 70°C, CPU frequency is reduced from 1.4 GHz to 1.2 GHz, when core voltage is also reduced. Later thermal throttling is applied on reaching 80°C, in this case, occasionally reducing sample MHz to 1087.

Code:

 Temperature and CPU MHz Measurement  Start at Tue Jul 31 21:14:36 2018

 Seconds
    0.0     1400 scaling MHz,   1400 ARM MHz, core volt=1.3438V, temp=58.0°C
   16.0     1400 scaling MHz,   1400 ARM MHz, core volt=1.3500V, temp=65.0°C
   32.5     1400 scaling MHz,   1400 ARM MHz, core volt=1.3563V, temp=69.3°C
   49.1     1400 scaling MHz,   1200 ARM MHz, core volt=1.3563V, temp=70.4°C
   65.6     1400 scaling MHz,   1199 ARM MHz, core volt=1.2375V, temp=70.9°C
   82.1     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=71.4°C
   98.7     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=72.0°C
  115.2     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=73.1°C
  131.7     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=74.1°C
  148.3     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=74.1°C
  164.9     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=74.7°C
  181.5     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=75.2°C
  197.9     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=75.2°C
  214.4     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=75.2°C
  230.9     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=76.3°C
  247.5     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=77.4°C
  264.0     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=77.4°C
  280.5     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=77.4°C
  297.1     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=77.4°C
  313.6     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=77.4°C
  330.1     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=77.4°C
  346.7     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=78.4°C
  363.2     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=78.4°C
  379.8     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=78.4°C
  396.4     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  413.0     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  429.6     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  446.1     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  462.6     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  479.2     1400 scaling MHz,   1195 ARM MHz, core volt=1.2375V, temp=80.1°C
  495.9     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  512.3     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  528.8     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  545.3     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  561.8     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=78.4°C
  578.3     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.0°C
  594.9     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=79.5°C
  611.6     1400 scaling MHz,   1195 ARM MHz, core volt=1.2375V, temp=79.5°C
  628.1     1400 scaling MHz,   1195 ARM MHz, core volt=1.2375V, temp=79.5°C
  644.6     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=80.6°C
  661.1     1400 scaling MHz,   1200 ARM MHz, core volt=1.2375V, temp=80.6°C
  677.6     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.1°C
  694.2     1400 scaling MHz,   1194 ARM MHz, core volt=1.2375V, temp=80.6°C
  710.7     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.6°C
  727.3     1400 scaling MHz,   1195 ARM MHz, core volt=1.2375V, temp=80.6°C
  743.8     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.6°C
  760.3     1400 scaling MHz,   1087 ARM MHz, core volt=1.2375V, temp=80.1°C
  776.8     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.6°C
  793.3     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.6°C
  809.8     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.6°C
  826.3     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=81.1°C
  842.9     1400 scaling MHz,   1087 ARM MHz, core volt=1.2375V, temp=80.6°C
  859.5     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.6°C
  876.0     1400 scaling MHz,   1087 ARM MHz, core volt=1.2375V, temp=81.1°C
  892.5     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.6°C
  909.1     1400 scaling MHz,   1140 ARM MHz, core volt=1.2375V, temp=80.6°C
  925.6     1400 scaling MHz,   1087 ARM MHz, core volt=1.2375V, temp=81.1°C
  942.2     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=80.6°C
  958.7     1400 scaling MHz,   1141 ARM MHz, core volt=1.2375V, temp=81.1°C


Integer Stress Tests

This has 12 tests using different data patterns, 6 of them Write/Read and 6 read only, performance being measured in MB/second. In this case, each test has the same running time, set at 80 seconds (overall 16 minutes), for this test. Below are 32 bit and 64 bit results from the 3B+, where the former is somewhat faster. There were "Cool" and "Hot" runs (room 3 °C to 4°C higher). All show CPU frequency throttling, below 1 GHz with the "Hot" tests, with similar reductions in measured performance.

Code:
           Multiply MB/second by four for overall performance

           Raspbian 32 Bit                     Gentoo 64 Bit
           Cool              Hot               Cool              Hot
           MB/s   MHz    °C  MB/s   MHz    °C  MB/s   MHz    °C  MB/s   MHz    °C

 Write/Read      1400  44.0        1400  59.1        1400  47.8        1399  65.5
        1  3699  1400  68.2  3240  1200  75.2  2927  1400  69.8  2589  1200  78.4
        2  3415  1200  70.9  3297  1200  79.0  2611  1200  70.9  2509  1141  81.1
        3  3218  1200  72.9  3247  1195  80.6  2536  1200  72.0  2375  1087  81.7
        4  3299  1200  73.1  3045  1141  81.1  2525  1200  75.2  2302  1034  81.7
        5  3288  1200  75.2  2929  1087  81.7  2533  1200  75.8  2263  1034  81.7
        6  3291  1200  76.3  2882  1033  81.7  2533  1200  77.4  2231  1034  81.7
 Read
        1  3620  1200  75.8  3343  1141  81.7  2832  1200  77.4  2646  1141  81.7
        2  3602  1200  78.4  3153  1034  81.7  2841  1200  78.4  2539  1034  81.7
        3  3592  1195  79.5  3015   980  82.2  2829  1195  80.1  2470  1034  81.7
        4  3567  1141  80.5  2938   926  82.2  2790  1141  80.6  2444  1033  82.2
        5  3500  1141  80.6  2922   980  82.7  2733  1141  80.6  2414  1034  82.2
        6  3432  1087  80.6  2876   980  82.2  2679  1087  80.1  2152   980  82.2

Average    3460  1197  76.0  3074  1075  81.0  2697  1197  76.5  2411  1066  81.5
1 Core     4065  1400        4065  1400        3168  1400        3168  1400
%Av/1 Core   85    86          76    77            85    86          76    76

Start                  44.0              59.1              47.8              65.5
Max                    80.6              82.7              80.6              82.2


Floating Point Stress Tests

The program uses single precision floating point calculations, with run time options for the number of operations per data word read/written and data size, in this case, 8 operations per word and 16 KB for L1 cache use. A summary of results is below. This time, the 64 bit version is the faster (up to 17.4 GFLOPS from 4 cores). "Cool" and "Hot" test results are again provided, not particularly comparable with those for the integer tests, but suggesting slightly less performance degradation. All exceeded 70°C but the "Cool" 64 bit test did not suffer from 80°C thermal throttling.

Code:

          Multiply MFLOPS by four for overall performance

          Raspbian 32 Bit                     Gentoo 64 Bit
          Cool              Hot               Cool              Hot
          MFLOPS  MHz    °C MFLOPS  MHz    °C MFLOPS  MHz    °C MFLOPS  MHz    °C

Average    2945  1212  75.7  2833  1168  78.7  3809  1227  71.8  3690  1203  77.4
1 Core     3439  1400        3439  1400        4360  1400        4360  1400
%Av/1 Core   86    87          82    83            87    88          85    86

Start                  47.8              55.8              45.1              61.2
Max                    80.1              81.7              76.3              80.1


OpenGL Stress Test

My OpenGL benchmark can also be included in stress testing, with a choice of window size, test function and running time. The detailed results PDF report shows that the Tiled Kitchen test produced the highest loading, along with performance being faster, using the 64 bit benchmark. Running a second 15 minute “Hot Test”, the latter, showed rapid varying speed between 20 and 18 FPS, with CPU frequency sometimes reducing to 1200, and maximum temperature of 70.9°C. VMSTAT measurements indicated that more than one CPU core was being used (average utilisation 116%).


OpenGL Extended Power Cable

After noting slow CPU benchmark performance whilst using an extended power cable, the procedure was repeated running the OpenGL test, when performance immediately reduced to 8 FPS, with the following recorded decreases in CPU MHz to 600 and core voltage to 1.2. The Pi 3B+ deserves a commendation for actually running in these circumstances (a permanent way of running cool?).

Code:

 Seconds
    0.0     1400 scaling MHz,   1400 ARM MHz, core volt=1.2000V, temp=52.6°C
    1.0     1400 scaling MHz,    600 ARM MHz, core volt=1.2000V, temp=52.6°C
    2.4     1400 scaling MHz,    600 ARM MHz, core volt=1.2000V, temp=52.6°C


OpenGL + 3 CPU Stress Tests Gentoo 64 Bit

Further 15 minute tests were carried out, running the OpenGL program at the same time as three CPU tests. Below are summaries of results, comprising a “Hot Test” using the plastic enclosure, with “Cool and Hot” using a FLIRC aluminium case, with the built in efficient CPU heat sink. “Hot” indicates a second run shortly after a “Cool” test.

Using the plastic case, 80°C thermal throttling again occurred, during both integer and floating point tests. Speeds of the latter appeared to be worse than when four copies of the program were run. Perhaps the high OpenGL CPU utilisation involved heavy use of floating point instructions.

With the FLIRC case, the CPU cores were running at 1400 MHz continuously during “Cool” sessions, the 5% per core reduction in performance being typical when running multiprocessor tests. During the “Hot” tests there was no thermal throttling, but there were instances of the 1200 MHz when 70°C was reached (not necessarily noted in instantaneous sample).

Code:

          MB/second and MFLOPS are for each core

          Integer + OpenGL
          Plastic Case            FLIRC Case Cool         FLIRC Case Hot
          MB/sec   MHz  FPS   °C  MB/sec   MHz  FPS   °C  MB/sec   MHz  FPS   °C

Average     2376  1093 14.9  80.0   3025  1400 18.9  59.6   2954  1387 18.4  68.8
1 Core      3168  1400   20         3168  1400   20         3168  1400   20
%Av/1 Core    75    78   74           95   100   95           93    99   92

Start                        55.8                    37.6                    53.7
Max                          82.7                    67.6                    70.4


          Floating Point + OpenGL
          Plastic Case            FLIRC Case Cool         FLIRC Case Hot
          MFLOPS   MHz  FPS   °C  MFLOPS   MHz  FPS   °C  MFLOPS   MHz  FPS   °C

Average     2880  1137 10.5  79.8   4162  1400 18.4  64.4   4096  1393 18.8  66.8
1 Core      4360  1400   20         4360  1400   20         4360  1400   20
%Av/1 Core    66    81   53           95   100   92           94    99   94

Start                        66.1                    46.2                    50.5
Max                          82.2                    69.3                    69.8



_________________
Regards

Roy
Back to top
View user's profile Send private message
Sakaki
Apprentice
Apprentice


Joined: 21 May 2014
Posts: 215

PostPosted: Thu Sep 13, 2018 11:10 am    Post subject: Reply with quote

roylongbottom,

as always, very interesting results. One question - are the integer stress tests moving 32-bit ints around? If so, do you have a version of the same test that moves 64-bit ints? Unaligned data access (wrt the native word length) would probably impose some performance penalty, as appears to be the case here for 64-bit vs 32-bit mode.
_________________
Regards,

sakaki
Back to top
View user's profile Send private message
roylongbottom
n00b
n00b


Joined: 13 Feb 2017
Posts: 33
Location: Essex, UK

PostPosted: Thu Sep 13, 2018 3:51 pm    Post subject: Reply with quote

Sakaki wrote:
roylongbottom,

as always, very interesting results. One question - are the integer stress tests moving 32-bit ints around? If so, do you have a version of the same test that moves 64-bit ints? Unaligned data access (wrt the native word length) would probably impose some performance penalty, as appears to be the case here for 64-bit vs 32-bit mode.


I have a 64 bit integer version for Linux/PCs. I will see if it is easily convertible.
_________________
Regards

Roy
Back to top
View user's profile Send private message
roylongbottom
n00b
n00b


Joined: 13 Feb 2017
Posts: 33
Location: Essex, UK

PostPosted: Sat Sep 15, 2018 11:28 am    Post subject: Reply with quote

Sakaki

I have converted the program that uses 64 bit integers and believe that it measures performance accurately. (It used assembly code for PC versions). It was compiled using gcc 7. I also recompiled the 32 bit integer program and confirmed that results were essentially the same as the original, from gcc 6. Following are results of 5 second tests at KB sizes 16, 64 and 2046 to use L1 cache, L2 cache and RAM.

CPUs use the same registers and equivalent instructions for 64 bit and 32 bit scalar integer arithmetic (confirmed with disassembly) and can execute them at the same speed, where 64 bit MB/second data transfer speed would be double that using 32 bit numbers. This is best demonstrated in read only access using L1 cache based data. As the measurements become more dependent on data transfer speed, 64 bit arithmetic can be at half speed, or same MB/second, as in the read only from RAM example. There are other considerations where writing to memory is involved.

Code:
         Integer Stresss Test Single Core MB/second

                     Write/Read         Read
                     L1    L2   RAM     L1    L2   RAM

 32 Bit Integers   2989  2916  1524   3348  2866  1862
 64 Bit Integers   5706  4635  1094   6650  5323  1945


If the programs had complied to use vector instructions, execution speed, using 32 bit numbers, would be twice that with 64 bit data.
_________________
Regards

Roy
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM All times are GMT
Goto page Previous  1, 2, 3 ... 14, 15, 16
Page 16 of 16

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum