C Using Raspberry to compile applications for my AMD64 Desktop.

Alain De Vos

Alain De Vos

Could i use the lower power consumption of my Raspberry to compile applications for my AMD64 Desktop ? How ?
Call it "reverse" cross-compiling ?
 
This could well backfire. We would need to establish a measurement for this, let's call it PPW (Ports Per Watt), beause the RPi is also slower than a normal laptop (not to speak of desktops) it will draw it's lower power for a lot longer.

My first step would be to check the Makefile in /usr/src to build a cross toolchain, and use that to build ports. You might use the kernel and base bor benchmarking the process, as a first step.
 
It took 5 hours to compile 30 packages (dependencies for games/stonesoup) on my Raspberry Pi 400 using Poudriere.
forums.freebsd.org

My exciting journey with poudriere on a Raspberry Pi

Hi, i played with poudriere and now i want to remove the files i created. I removed the jail via poudriere jails -d -j 13aarch64 and now want to remove the data directory in the poudriere directory i configured. Unfortunately, i can't delete the files, even as root. What's wrong...
forums.freebsd.org forums.freebsd.org

Can't recommend it.
 
Interesting question, i'll try to find out knowing power consumption of a raspberry is around 1.5A X 5V = 7.5 W , and on my 8 core desktop poudriere compiles LLVM-11 compiles in 17 hours.
 
Good idea. Just had a look at my old ELIX DMM3900 Digital Multimeter. It measures AC-Current from 20uA upto 20A (8000W).
 
The power consumption of computers is not constant and you need to measure it over time. That's why it's better to use wattmeter or multimeter with logging capabilities.
 
ipmitool sdr get "Power Meter"
Code: 
 Sensor Reading        : 144 Watts
 Sensor Reading        : 144 Watts
-------
 Sensor Reading        : 204 Watts
 --------
Sensor Reading        : 280 Watts
Sensor Reading        : 280 Watts
Sensor Reading        : 280 Watts
ipmitool power readings after starting john the ripper on 24 smt threads
ProLiant DL380 G7, 2 x Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
Code: 
  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
96506 titus        24 103    0   274M    56M CPU7     7 143:43 2394.54% john
 
... and don't let us get into the complex nature of power consumption (as in complex numbers). With some tricks, you could let old power meters turn backwards while still sucking juce from the grid. Simply measuring amperes will not get you very far. But one question, does compile LLVM _really_ take 17 hours? What the beep?

But I am interested in how this turns out. One question - do you still run the system from a SD card?
 
Alain De Vos said:
Good idea. Just had a look at my old ELIX DMM3900 Digital Multimeter. It measures AC-Current from 20uA upto 20A (8000W).
Click to expand...
And: Power consumption of AC loads is not as simple as current x voltage. There's two reasons for that. One is that current can fluctuate rapidly, even within a single sine wave. For that reason, you need a current meter that correctly averages over time; that's called RMS, or root-mean-square (take the square of the current, average it, then take the square root of the average). Second reason a current meter can't deal with by itself, even if it does RMS averaging: Most AC loads do not use current in phase (synchronized) with the voltage. Imagine a load that uses positive current when the voltage is near zero and rising, and negative current when the voltage is near zero and dropping. It actually uses no power at all, since the current is non-zero only when the voltage is nearly zero, and the positive usage during one half of the sine wave exactly compensates the negative usage during the other half. And this example is not hypothetical, this actually happens if the load is purely a capacitor or inductor.

To measure power consumption, you need a power meter; they measure current, and also sense the voltage, then take the product, and integrate (average) the product over time. Industrial-grade power meters tend to be very expensive. In the US, there is one that's called a Kill-A-Watt, which you just plug between the load and the wall socket, and it does the job pretty accurately and is inexpensive.

To the question whether a RPi will do compiles cheaper than a big AMD (even if slower): That's a very difficult question, and hard to guess ahead of time. Typically, ARM architecture CPUs run more instructions per watt. But in a modern computer, a significant fraction of the power usage is determined by the memory chips, and the difference in memory access patterns is hard to predict, and depends crucially on caches and cache management. Furthermore, the power consumption of a computer roughly doubles when you take cooling and power conversion into account. That's something where a fanless RPi looks good, except that its power supply may not be very efficient, while desktop power supplies are subject to government regulations that force them to have good efficiency. And then, an amateur desktop probably has very inefficient cooling (while big datacenter computers are cooled exceedingly efficiently, the big data center operators can't afford doubling their megawatts). So you would have to measure this carefully.
 
Crivens said:
But I am interested in how this turns out. One question - do you still run the system from a SD card?
Click to expand...
Ah, good point. If one is using a consumer-grade SD card (where every memory cell can only be overwritten ~100 times) as a system disk, in particular with swapping, then long compiles will likely break the SD card within weeks or months. The cost of replacing those probably far exceeds the power saving.
 
ralphbsz said:
Ah, good point. If one is using a consumer-grade SD card (where every memory cell can only be overwritten ~100 times) as a system disk, in particular with swapping, then long compiles will likely break the SD card within weeks or months. The cost of replacing those probably far exceeds the power saving.
Click to expand...
I once shredded a fairly expensive USB3 stick within 2 weeks of tests simply by it being the target of logging. So this might bite you even sooner than expected. Maybe running these jobs from a memory disk would be a good idea, but in the end you need to hit storage somewhere.
My current idea is to use a USB3->SATA connector to run my Pi from an external SSD, which should be faster than the SD card and also better with regard of the wear and tear.
 
Crivens said:
I once shredded a fairly expensive USB3 stick within 2 weeks of tests simply by it being the target of logging.
Click to expand...
Writing log files can be an extremely brutal workload for flash storage. Depends on the file system. For example, say the logging infrastructure appends 10 bytes to a file every 10ms, and for durability reason that's done with sync writes. In some file systems, that will be implemented by the last block (4K bytes) of the file system being overwritten every 10ms. But many forms of flash storage actually use 64K or larger internal blocks, so on every write, a whole block needs to be slightly modified and rewritten. Like this, a 10-byte write turns into a 64K write. And if the flash has only limited write endurance, that can get ugly pretty quick.

Maybe running these jobs from a memory disk would be a good idea, but in the end you need to hit storage somewhere.
Click to expand...
And RAM is something that is not plentiful on the RPi.
 
As a first test writing to the SD-CARD seems to be painstakingly slow. I might take a few hours to just do a just "pkg update".
[ It was an SD-CARD priced less then 10 Euros. ]
 
Verified . Currently Kingston. Vendor spec, SDHC , A1, Video Class V10, UHS class1, Class10 , Read speed upto 100MB/s.
C10 (Class 10): minimum write speed of 10MB/s
Should be ok.
 
Journaling is disabled & average filesize is 16K-something.
The only thing i can do is check to tune ufs to sync less frequently to disk.
Code: 
kern.metadelay
kern.dirdelay
kern.filedelay
I've increased them to 5 minutes as maximum sync time.
 
sysctl dev.cpu.0.freq_levels is showing,
Code: 
1500/-1 600/-1
And sysctl dev.cpu.0.freq shows,
Code: 
1500
Which is ok.
Like Crivens suggested will use an USB to SATA.
[ PS: I think Sandisk is a better brand compared to Kingston for SSD cards.]
 
I have found "blocksize" is important for speedly dd transfer to the SSD-Card. A blocksize of 16M works fine.
The default filesystem blocksize of ufs is 32K and maximum is 64K
 
I did an update of the eeprom of the board with the use of a raspberry pi os on a sd-card.
Then i did some manual tuning to the freebsd ufs filesystem on the sd-card.
Still extracting packages is very very very slow.
 
You must log in or register to reply here.
Back
Top