Times to build just devel/llvm50 via poudriere-devel: Pine64+ 2GB, RPi3, RPi2 V1.1

[Mark Millard]

[I should have mentioned: non-debug kernels were in use.]

On 2018-Jan-4, at 6:23 PM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2018-Jan-4, at 3:40 PM, Andreas Schwarz <freebsd.asc at strcmp.org> wrote:
> 
>> On 04.01.18, Mark Millard wrote:
>> 
>>> eMCC performance notes:
>>> The rpi3 can get between 10 MiByte/s and
>>> 12 MiByte/s, while the Pine64+ 2GB can get
>>> between 5 MiBytes/s and 6 MiBytes/s, from
>>> what I have observed.
>> 
>> Unfortunatly the DiskIO (to SD Card) of the Pine64 is very slow 
>> in comparsion to RPI2B (or RPI3).
>> 
>> root at rpi2b:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024
>> 1024+0 records in
>> 1024+0 records out
>> 1073741824 bytes transferred in 80.823823 secs (13284967 bytes/sec)
>> 
>> root at pine64plus:~ # dd if=/dev/zero of=/var/zero.img bs=1m count=1024
>> 1024+0 records in
>> 1024+0 records out
>> 1073741824 bytes transferred in 383.600722 secs (2799113 bytes/sec)
>> 
>> Both devices running r327391 with without any debugging, INVARIANTS, 
>> etc.. Used SD Cards: Samsung MB-MGBGB SDHC 32GB
>> 
>> Mark, can you perform the write test with your eMMC to MicroSD 
>> Adapter?
> 
> [I probably should have noted that I mount
> with -o noatime for all these contexts. And
> all 3 have heat sinks and fans. The RPi2B
> V1.1 and Pine64+ 2GB were running -r327364
> at the time (and still are).]

Also: non-debug kernels were in use for all 3
examples.

> The RPi2 context is odd because the usdcard slot
> is partially broken: Its mechanism for hold in
> cards has failed but its mechanism for ejecting
> them still works. This is one reason why there is
> a USB SSD stick on a powered USB hub involved:
> USB is where the kernel, the dtb file that the
> kernel reads, the root file system, and the
> swap space are all from. I hold in the usdcard
> until the kernel starts to load then I let go.
> 
> As the poudriere bulk activity was based
> (RPi2B V1.1: USB SSD stick). . .
> 
> RPi2B V1.1 (cortex-a7) using the USB SSD stick:
> # dd if=/dev/zero of=/var/zero.img bs=1m count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes transferred in 48.251071 secs (22253223 bytes/sec)
> 
> (Note: The powered hub and USB SSD stick are all USB 3.0
> capable and for a good USB 3.0 context can sustain well
> over 10 times the above figure.)
> 
> RPi3: (cortex-a53) using a 64 GB eMMC via a usdcard adapter:
> # dd if=/dev/zero of=/var/zero.img bs=1m count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes transferred in 72.442738 secs (14821939 bytes/sec)
> 
> Pine64+ 2GB: (cortex-a53) using a 128 GB eMMC via a usdcard adapter:
> # dd if=/dev/zero of=/var/zero.img bs=1m count=1024
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes transferred in 189.560701 secs (5664369 bytes/sec)
> 
> The RPi2B V1.1 and RPi3 have similar amounts of RAM,
> and so likely similar amounts of swapping activity
> (compared to the Pine64+ 2GB), but the slower I/O
> rate context (RPi3) took less time for the build
> than the faster I/O rate context (RPi2B V1.1).
> 
> The Pine64+ 2GB did some swapping, but not much compared
> the the RPi2/3 (far more RAM). With this difference (and
> hardware differences), the slowest I/O rate of the 3
> contexts took the least build time.

Non-debug kernels were in use for all 3
examples.

> RPi2B V1.1 eMMC via an adapter: no figures, I'm afraid. . .
> 
> Each of my attempts to hold an eMMC with an adapter
> in the RPi2 usdcard slot for a test have resulted in
> a panic. I'm afraid I'll not be getting an RPi2B V1.1
> timing for an eMMC via an usdcard slot adapter.
> 
> 
> eMMC adapter note:
> 
> Some cases for single board computers interfere
> with using an eMMC via an adapter.

===
Mark Millard
markmi at dsl-only.net