Could you perhaps try a development version of BOINC to see if it has been fixed already? I see that the website binaries for PC have already been updated, but ARM seems to be lagging behind (maybe compile from source?). I could think of a quick workaround script that detects when a job is finishing and temporarily suspends all others while it is saving its files, but that would be a major hack. Or perhaps trying a faster SD card or faster file system might help (maybe not).

I am considering upgrading to Ubuntu. And I could also use a newer version of BOINC.

Are you positive that the task wouldn't start by itself even if you waited for a few minutes? Maybe the things are related: it is trying to start the next job while the previous is preparing its results? (Just guessing) Could you find anything in the logs (boinccmd --get_messages)? Boinc usually explains why it is or is not doing things.

I noticed that when 2 or more WUs are writing or reading from Flash (e.g. if I resume 2 tasks at once), the system becomes slow to respond. Unfortunately, I already restarted RPI after the error. Since then there is nothing special in the logs. sometimes it is quite difficult to get tasks - often they are not allowed to be sent. And few minutes later its not a problem.

131: 15-Apr-2020 20:06:36 (low) [Rosetta@home] Sending scheduler request: To fetch work.                                                                                                              
132: 15-Apr-2020 20:06:36 (low) [Rosetta@home] Requesting new tasks for CPU                                                                                                                           
133: 15-Apr-2020 20:06:38 (low) [Rosetta@home] Scheduler request completed: got 0 new tasks                                                                                                           
134: 15-Apr-2020 20:06:38 (low) [Rosetta@home] No tasks sent                                                                                                                                          
135: 15-Apr-2020 20:06:38 (user notification) [Rosetta@home] Message from server: Rosetta needs 1907.35 MB RAM but only 966.93 MB is available for use.                                               
136: 15-Apr-2020 20:11:44 (low) [Rosetta@home] project suspended by user                                                                                                                             
137: 15-Apr-2020 20:12:14 (low) [Rosetta@home] update requested by user                                                                                                                               
138: 15-Apr-2020 20:12:18 (low) [Rosetta@home] Sending scheduler request: Requested by user.                                                                                                          
139: 15-Apr-2020 20:12:18 (low) [Rosetta@home] Not requesting tasks: suspended via Manager                                                                                                            
140: 15-Apr-2020 20:12:20 (low) [Rosetta@home] Scheduler request completed                                                                                                                            
141: 15-Apr-2020 20:12:33 (low) [Rosetta@home] task rb_04_12_20719_20959_ab_t000__h001_robetta_IGNORE_THE_REST_07_07_911363_14_1 suspended by user                                                    
142: 15-Apr-2020 20:12:38 (low) [Rosetta@home] task rb_04_12_20719_20959_ab_t000__h001_robetta_IGNORE_THE_REST_07_07_911363_14_1 suspended by user                                                    
143: 15-Apr-2020 20:12:41 (low) [Rosetta@home] task rb_04_12_20719_20959_ab_t000__h001_robetta_IGNORE_THE_REST_04_05_911363_16_1 suspended by user                                                    
144: 15-Apr-2020 20:12:42 (low) [Rosetta@home] task rb_04_12_20719_20959_ab_t000__h001_robetta_IGNORE_THE_REST_08_05_911363_12_1 suspended by user                                                    
145: 15-Apr-2020 20:12:55 (low) [Rosetta@home] project resumed by user                                                                                                                                
146: 15-Apr-2020 20:13:04 (low) [Rosetta@home] update requested by user                                                                                                                               
147: 15-Apr-2020 20:13:07 (low) [Rosetta@home] Sending scheduler request: Requested by user.                                                                                                          
148: 15-Apr-2020 20:13:07 (low) [Rosetta@home] Not requesting tasks: some task is suspended via Manager                                                                                               
149: 15-Apr-2020 20:13:09 (low) [Rosetta@home] Scheduler request completed                                                                                                                            
150: 15-Apr-2020 20:14:03 (low) [Rosetta@home] task rb_04_12_20719_20959_ab_t000__h001_robetta_IGNORE_THE_REST_07_07_911363_14_1 resumed by user                                                      
151: 15-Apr-2020 20:15:04 (low) [Rosetta@home] task rb_04_12_20719_20959_ab_t000__h001_robetta_IGNORE_THE_REST_04_05_911363_16_1 resumed by user                                                      
152: 15-Apr-2020 20:15:29 (low) [Rosetta@home] task rb_04_12_20719_20959_ab_t000__h001_robetta_IGNORE_THE_REST_08_05_911363_12_1 resumed by user                                                      
153: 15-Apr-2020 20:16:31 (low) [Rosetta@home] Sending scheduler request: To fetch work.                                                                                                              
154: 15-Apr-2020 20:16:31 (low) [Rosetta@home] Requesting new tasks for CPU                                                                                                                           
155: 15-Apr-2020 20:16:34 (low) [Rosetta@home] Scheduler request completed: got 2 new tasks                                                                                                           
156: 15-Apr-2020 20:16:37 (low) [Rosetta@home] Started download of rb_04_15_21668_21257_ab_t000__robetta_FLAGS                                                                                        
157: 15-Apr-2020 20:16:37 (low) [Rosetta@home] Started download of rb_04_15_21668_21257_ab_t000__robetta.zip                                                                                          
158: 15-Apr-2020 20:16:39 (low) [Rosetta@home] Finished download of rb_04_15_21668_21257_ab_t000__robetta_FLAGS                                                                                       
159: 15-Apr-2020 20:16:39 (low) [Rosetta@home] Finished download of rb_04_15_21668_21257_ab_t000__robetta.zip                                                                                         
160: 15-Apr-2020 20:16:39 (low) [Rosetta@home] Started download of rb_04_15_21668_21257_ab_t000__robetta.200.3mers.index.gz                                                                           
161: 15-Apr-2020 20:16:39 (low) [Rosetta@home] Started download of rb_04_15_21668_21257_ab_t000__robetta.200.11mers.index.gz                                                                          
162: 15-Apr-2020 20:16:41 (low) [Rosetta@home] Finished download of rb_04_15_21668_21257_ab_t000__robetta.200.3mers.index.gz                                                                          
163: 15-Apr-2020 20:16:41 (low) [Rosetta@home] Finished download of rb_04_15_21668_21257_ab_t000__robetta.200.11mers.index.gz                                                                         
164: 15-Apr-2020 20:17:10 (low) [Rosetta@home] Starting task rb_04_15_21668_21257_ab_t000__robetta_IGNORE_THE_REST_03_11_916702_5_0                       

It is still a mystery to me when a new task is allowed to start. Sometimes it starts by itself, sometimes only 1 task is left to run. There is nothing about that in the logs.

Also, could you perhaps post some stats while the Pi is fully loaded and happily crunching with BOINC? I would be interested in memory usage and compression ratio: `ps -e v` (or the relevant boinc lines of `top`), `free`, `cat /proc/swaps` and `zramctl` (or the appropriate folder in sysfs)

Running 4 Rosetta tasks (note, this is only the beginning though):
top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1550 boinc 39 19 324092 164704 62372 R 94.1 16.6 7:54.03 rosetta_4.15_aa
1615 boinc 39 19 365552 238068 94284 R 94.1 24.0 5:52.67 rosetta_4.15_aa
1618 boinc 39 19 334516 210708 97852 R 94.1 21.3 5:24.04 rosetta_4.15_aa
1535 boinc 39 19 332424 123680 54592 R 88.2 12.5 7:25.72 rosetta_4.15_aa

free:
total used free shared buff/cache available
Mem: 990132 534196 154188 752 301748 389820
Swap: 1320160 57856 1262304

Filename Type Size Used Priority
/dev/zram0 partition 330040 14252 5
/dev/zram1 partition 330040 15048 5
/dev/zram2 partition 330040 14592 5
/dev/zram3 partition 330040 13196 5

NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram3 deflate 322.3M 12.7M 3.9M 4.9M 4 [SWAP]
/dev/zram2 deflate 322.3M 14.2M 4.5M 5.4M 4 [SWAP]
/dev/zram1 deflate 322.3M 14.5M 4.6M 5.5M 4 [SWAP]
/dev/zram0 deflate 322.3M 13.7M 4.3M 5M 4 [SWAP]

I have already seem more than 200MB data in each partition earlier.

I see my 2GB phone has also started crunching Rosetta despite the fact that it failed with the same memory limit error. My theory is that Rosetta is generating special tasks for low-memory ARM phones and SBC, maybe along with normal-memory ones for more capable ARM's. As many such devices are sitting idle, maybe there is high competition for these tasks and they dry out too soon for you to notice.

My guess is that the life cycle of tasks in BOINC is something like:

- fetching from server scheduler
- got task metadata
- download assets from server (this can be hundreds of megabytes/piece)
- slot initialization (this copies a half gig zip and than also unpacks the thousands of files from it)
- running
- taking snapshots
- suspended, in memory
- suspended, killed
- restarting executable, reloading snapshot, reconstructing state and resuming calculation
- running
- result gathering & cleanup
- upload
- deleted

From your logs I can see that it did not get such low-memory tasks at first, but it did get some on a later retry. After downloading, it indeed started working on it without hesitation I'm not sure if I understand your problem correctly, but if my assessment is correct, you Pi only downloaded 2 tasks, but immediately started working on them. You may try to experiment by increasing your task queue size so that you don't sit idle too idle too much when supply is low (maybe 0.5+0.5?), but otherwise I think we should be patient.

So it seems, as zram wasn't kicking in at such an early execution stage on the small tasks, I think it should be the I/O. If you are really curious what make starting slow, you may fire up `top` and `iostat 5` while you are doing the resume or the initial execution. My guess is that if you wait for the SD card too much, your %wa (I/O wait) will stay up, perhaps a little system as well.

Unfortunately, SD cards themselves are very slow both in linear write throughput and especially in random access. Random access is the one that kills performance the most and this is what happens when you manipulate a vast amount of files, for example when you are extracting a huge zip with heap loads of files inside. There's no wonder here - there exist some specialty high-IO cards and USB thumb drives out there, but an SSD is more suited to cope with this.

What is the make, model number and size of your card? Many ways exist to benchmark it, like: (substitute your device)

time dd if=/dev/sda bs=30M count=2 iflag=direct of=/dev/null
hdparm -t /dev/sda

I guess you could also test random I/O with iozone3 or sysbench as well.

As a workaround, you may try to look up which file system runs the fastest for such a use case on SD cards. I imagine compression could help here (like that in btrfs if mounted right), as that reduces bandwidth, and maybe a non-journaling or log structured file system could also be advantageous (just guessing, please look it up or try it yourself). Basically most budget SD cards lack in amount of parallel open erase blocks and some other implementation details that can enable acceptable linear single-file transfer performance for FAT32, but appalling one for many files and with ext4.

You could actually partition your SD card (from your computer or from a reader when booted from another SD card) so that you reduce the size of the native file system root and create another, different kind of file system next to it that you will mount under /var/lib/boinc* via fstab).

Still overall I think because most of the time your I/O is just idling, it would make more efficient use of the existing hardware if task initialization was strictly sequential and/or if such timeouts were increased. I think they did manage to do the latter in the newer development builds, but I didn't check.

I spent last few evenings working on this. I think that I managed to learn quite a lot about zram, compression, BOINC memory management, and I started learning bash to be able to read your script.

Here is the result:
I am able to run 4 WUs at the same time on my 3B+ 24/7 automatically starting, without having any swap use, using zram.

Solutions which I applied:
- Instead of using custom script I switched to a tool called zram-tools which is in the repository. This is using standard LZO algorithm which is significantly faster than Deflate (used by the script). I found that Rosetta's tasks can be compressed with a ratio of around 2,6 using LZO, so I set my zram partition size to 250% of my ram size (2,4GB). This seems to increase the speed of calculations by around 3-5%. I never reach the limit in size ( it very rarely stores more than 600MB data - ca 240MB after compression), but just to be sure, I set up a 1GB swap partition.

- I increased the allowed memory use of BOINC to 300%. This allows 4 WUs to start even if the RAM is not empty to start with. The kernel simply moves data from the ram to the zram partitions. I have not experimented with the value itself.

- I increased the buffer of WUs to around 1 day. I will have to experiment with this a bit more, but it seems like this could be enough.

I tested Ubuntu server and I found out that it uses almost 200MB ram idle. Raspbian lite uses only around 55MB. Right now I am testing these settings on Raspbian, however, I would definitely like to try them also on Ubuntu and see whether there is any performance difference.

- I increased the buffer of WUs to around 1 day. I will have to experiment with this a bit more, but it seems like this could be enough.

The watchdog timer has recently been increased form 4 hours to 10 hours. If your estimated completion times are low, and you get a longer running Task (or several), things could get ugly.
I'd suggest

                                Store at least 1 days of work (maybe even just 0.8?)
                     Store up to an additional 0.02 days of work

And give things a week or 3 so see how things go.
We could be in for a bumpy ride.

---

Grant
Darwin NT

Thanks for reporting back and for all the experiments, these are very useful insights! I'm glad you feel like you are learning useful things during the ride.

Surely `deflate` and `zlib` are the slowest choices available and they weren't meant for realtime use cases at all. On a desktop machine I use, I store my BOINC slot and project folders on a zram compressed ramdisk formatted to ext4 for a nice I/O speed boost. The space saved by `deflate` compared to `LZO` was about 20%.

How did you manage to benchmark the "speed of calculations" so precisely (close to a margin of error), what did you check? Could you perhaps consider benchmarking some other algorithms as well? LZ4 and LZ4HC were also designed for realtime use and can give you a bit more headroom. You may check what is available on your system from this, although it doesn't list all possibilities:

cat /sys/block/zram0/comp_algorithm

I think that I finalized a guide for getting Rosetta to run on Raspberry Pi 3B+ (and also 2B v1.2, 3B, 4 - 1GB). It is available here:
https://www.reddit.com/r/BOINC/comments/g0r0wa/running_rosetta_covid19_workunits_on_raspberry_pi/

Unfortunately, I am not able to update the post here in this thread.

The speed of calculations seems like a wrong estimate, so do not base anything on it. I am sorry for misleading.
While test running the WUs, I noticed that the average speed of calculations with kernel 4.19. and the Deflate algorithm is around 28000sec. Ubuntu server with kernel 5.3 with LZO-RLE seemed to need around 26500 sec to complete a work unit, which would indicate an improvement around 5,5 percent, However, later I found that the Kernel 4.19 with LZO needs around 27000sec, which is very close. It is impossible to objectively compare the algorithms with only a few results.

I also discovered that my RPI has a significantly higher benchmark on Ubuntu server with kernel 5.3 than on Raspbian with kernel 4.19. Maybe this could explain the difference?
Raspbian:
Measured floating point speed 1333.92 million ops/sec
Measured integer speed 29853.32 million ops/sec
Ubuntu:
Measured floating point speed 1631.85 million ops/sec
Measured integer speed 36629.84 million ops/sec

What I managed to measure fairly accurately is the compression ratio of Rosetta tasks. Zramctl showed that even with overhead, LZO was having a compression ratio around 2.55-2.65, which is pretty nice. Here is LZO-RLE which I am running on Ubuntu right now:
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram3 lzo-rle 598.8M 188.4M 69.8M 73.2M 4 [SWAP]
/dev/zram2 lzo-rle 598.8M 187.8M 69.4M 72.9M 4 [SWAP]
/dev/zram1 lzo-rle 598.8M 187.8M 70.2M 73.6M 4 [SWAP]
/dev/zram0 lzo-rle 598.8M 189.1M 70.5M 73.9M 4 [SWAP]

I can definitely tell that the compression of LZO is worse than deflate. With deflate, 1GB ZRAM was enough for 4 tasks. With LZO and the same amount of ZRAM, I stalled the system and got it to a point when it was not responding, meanwhile it was stuck writing to SD card. Unfortunately, I did not test the compression ratio of deflate before switching to LZO.

I would like to try other compression algorithms like LZ4 later. But for now, I feel like I am at a point where I am satisfied with the performance of both Raspbian and Ubuntu. Now it will be important to get as many as possible onboard and get their RPIs to crunch numbers effectively. Let's just hope that the new changes to Rosetta won't mess up too much with RPis.

Thanks for all the help and advice! Even though I did not implement all the suggestions, it was great to get feedback and guidance on what to concentrate on.

Thanks for the write up and sharing your detailed setup. Keep spreading the word!

Please read the posts that explain how credits are awarded in Rosetta@home.

* https://boinc.bakerlab.org/rosetta/forum_thread.php?id=669&postid=10377
* http://https://boinc.bakerlab.org/rosetta/forum_thread.php?id=2194&postid=24612#24612

TL;DR: the time a WU takes doesn't really matter, it's the number of finished decoys that count and the difficulty of the individual decoys within a given kind of WU. There are various kinds of WU's, maybe dozens of them, all having mixes of various difficulties.

The only accepted valid way of measuring the productivity of your rig is to run a given configuration without touching anything for 2 weeks and record the RAC after that point. All other kind of determination is by definition a guesstimate.

If you do want to benchmark the effects of your tweaks scientifically, I think you could copy away a slot directory which seems to be checkpointing and producing models a lot for safe keeping. The parametrization of the executable and all input data is available next to it (or from `ps -e f`), along with the random seed I think. Hence creating a script to run the same executable for a few hours could show you the seconds per model production speed on that given work unit. To properly simulate the memory and kernel load as well, you should probably run this four times at the same time (maybe from separate places). This type of measurement usually wouldn't generalize, but if you are only using it to tweak a given computer (kernels, configs, paging setup, sysctls, cooling and whatnot), it should be useful.

Still you would need to repeat the measurement a couple of times to arrive at any reasonable statistical significance that could show 5-10% of difference.

Also, I think if you create a complete rewrite of your first post that encompasses all points written therein with no omission (possibly with using strike-through for outdated information) and perhaps containing some new or updated links, you may ask a moderator to copy&paste it for you into the top post (but use this wisely as mod time is costly).

This thread interests me greatly - I actually gave up on running Rosetta on my Xbian pi 3B and ordered a 4 GB pi 4 to try with Rosetta.

That said, has anyone tried to use a network file mount for boinc storage instead of the local flash storage? Writes and reads to freenas have to be faster over gb networking than to local flash.

My current plan for the pi 4:

Reduce power by turning off HDMI, LEDs, wireless, and USB and anything else I can find to turn off.

Run raspbian / raspbian light based on above info, and use ZRam to ensure the pi4 has enough memory to run 4 Rosetta threads at all times.

Store as much as possible on my freenas. I may even consider PXE network boot and forgo a local SD card entirely.

Thoughts?

That said, has anyone tried to use a network file mount for boinc storage instead of the local flash storage? Writes and reads to freenas have to be faster over gb networking than to local flash.

Sounds like a good idea, and could support a lot of Pi units.
I think the important thing will be to delay the startup of BOINC, so it doesn't go looking for files that aren't there because the network connection hasn't been established.

I may even consider PXE network boot and forgo a local SD card entirely.

Which would mean the network connection would definitely be up before BOINC starts.

---

Grant
Darwin NT

That said, has anyone tried to use a network file mount for boinc storage instead of the local flash storage? Writes and reads to freenas have to be faster over gb networking than to local flash.

Sounds like a good idea, and could support a lot of Pi units.
I think the important thing will be to delay the startup of BOINC, so it doesn't go looking for files that aren't there because the network connection hasn't been established.

We should be able to set the boinc-client service to require and start after networking, though there may be another service or two in the dependency tree. Sometimes I miss initd. S99boinc-client would handle this nicely.

That sounds like an excellent plan, do keep us posted. I'm especially interested in your future power consumption! Also don't forget to update your firmware as that decreases consumption a lot. You may even try undervolting everything and underclocking unused parts of the chips (like the GPU).

Also, depending on how willing you are to do some experimentation, as we now know that 1GB RAM + zram swap/zcache can be enough for 4 tasks at once, that means we actually have about 3GB free to play with! You could even consider creating a zram compressed RAM-disk that could hold about 5GB of data. Or at least store your I/O hungry slots directory here and story the project directory over NFS.

An added benefit of not using NFS at all would be that you could also disable ethernet (FYI. gigabit consumes extra) and only enable file transfers over wifi intermittently to save even more power. That would require PXE booting a mini-distribution onto a RAM-disk as well, similar to how Puppy Linux does it on the PC. I actually have a PC setup just like this: booting squashfs to RAM, spinning off disks, zram swap, zram scratch system (ext4 for now due to trim support).

I feel this one to be a little tight though in 4GB, but it would be doable with a deduplicating file system in RAM or doing KSM on the whole RAM by using qemu for example (would need to benchmark the impact).

That sounds like an excellent plan, do keep us posted. I'm especially interested in your future power consumption! Also don't forget to update your firmware as that decreases consumption a lot. You may even try undervolting everything and underclocking unused parts of the chips (like the GPU).

Also, depending on how willing you are to do some experimentation, as we now know that 1GB RAM + zram swap/zcache can be enough for 4 tasks at once, that means we actually have about 3GB free to play with! You could even consider creating a zram compressed RAM-disk that could hold about 5GB of data. Or at least store your I/O hungry slots directory here and story the project directory over NFS.

An added benefit of not using NFS at all would be that you could also disable ethernet (FYI. gigabit consumes extra) and only enable file transfers over wifi intermittently to save even more power. That would require PXE booting a mini-distribution onto a RAM-disk as well, similar to how Puppy Linux does it on the PC. I actually have a PC setup just like this: booting squashfs to RAM, spinning off disks, zram swap, zram scratch system (ext4 for now due to trim support).

I feel this one to be a little tight though in 4GB, but it would be doable with a deduplicating file system in RAM or doing KSM on the whole RAM by using qemu for example (would need to benchmark the impact).

Per this article, the pi’s wireless uses 10x the power of Ethernet, just being idle (unfortunately, it doesn’t provide WiFi load power usage).

https://github.com/superjamie/lazyweb/wiki/Raspberry-Pi-Power

Presuming this is similar for the pi 4, having WiFi On for 2.5 hours per day is the same power as always on Ethernet. In this case, I think the advantages of an always on network connection probably outweigh the benefits of switching WiFi on and off to get a similar power usage.

I thought this would be a good place to ask. I want to set up a personal Raspberry Pi4 for myself and possibly my kids. Can anyone suggest a good setup to purchase that is reasonably priced but is well setup for running R@h?

---

Per this article, the pi’s wireless uses 10x the power of Ethernet, just being idle (unfortunately, it doesn’t provide WiFi load power usage).

This is not true for 3B+. Disabling Ethernet together with USB hub provides the biggest consumption reduction possible - almost 200mA. Wifi consumes around 55mA. For me, disabling Ethernet means a significant reduction in temperature.
https://www.raspberrypi.org/forums/viewtopic.php?p=1286716

I thought this would be a good place to ask. I want to set up a personal Raspberry Pi4 for myself and possibly my kids. Can anyone suggest a good setup to purchase that is reasonably priced but is well setup for running R@h?

I would suggest Raspberry pi 4 with at least 2GB of RAM. Preferably 4GB of you can afford it. I would not buy 3B, or 3B+ unless you can get it 2nd hand for a cheap price.

1GB RAM - usable, with limitations for Rosetta. It is still fun, but I do not expect from this version to be well supported for a very long time. It is very easy to use out 1GB RAM while doing any kind of work. Ubuntu server uses 25% RAM just by being idle.
2GB RAM - enough to do calculations atm, you might still want some extra zram/swap though. If you want to do some more serious work - connect it as a PC, browse the internet etc, you will probably hit the limits.
4GB RAM - more than enough for the current workloads. You might not be able to use the full potential just yet, but I would expect that in the future it might prolong the useful life of the RPI.

I thought this would be a good place to ask. I want to set up a personal Raspberry Pi4 for myself and possibly my kids. Can anyone suggest a good setup to purchase that is reasonably priced but is well setup for running R@h?

Even with the 4GB model, I think running R@h with 4 processes AND doing something else May be a tall task. That said, I have 4 PIs at home - one pi 2 that runs pi hole, and 3 boinc processes of asteroids at home.

I have 1 pi 2 and 2 pi 3s that run XBian and 3 boinc processes - having 1 spare CPU to run the intended function of the PI is pretty important.

For the pi 4, I ordered:

1)The 4GB pi 4 itself ($49)

2)A Flirc aluminum heatsink case (very, very important for running CPUs constantly) ($15)

3) A 32GB Samsung EVO+ flash card (if you have high performance storage requirements, look to the Samsung pro or sandisk ultra)
($8)

4)A power supply (I bought a 6 port 60watt USB charger.. the official pi power supply would be better for a single pi) ($10 for a single power supply)


All that should run around $80, depending where you get the pi. (Micro center in store is like $20 less than buying from amazon)

Per this article, the pi’s wireless uses 10x the power of Ethernet, just being idle (unfortunately, it doesn’t provide WiFi load power usage).

This is not true for 3B+. Disabling Ethernet together with USB hub provides the biggest consumption reduction possible - almost 200mA. Wifi consumes around 55mA. For me, disabling Ethernet means a significant reduction in temperature.
https://www.raspberrypi.org/forums/viewtopic.php?p=1286716

Why does Ethernet go down when turning off usb? Can’t they be disabled independently?

I'm not sure where the author got the measurement, but I would believe that the ethernet chip itself could consume that amount, but you always have to add the transformer and other components as well. This: review also mentions 0.2W power saving when using wifi instead of ethernet (measurement precision unknown):
http://https://www.digitec.ch/en/page/the-raspberry-pi-4-new-top-notch-and-tough-to-get-hold-of-12482

I don't have a Pi of my own, but I've been told my someone that ethernet on a Pi adds about 0.3W. However, I had measured in the past various kinds of wifi routers. The more efficient ones consume 0.9W from the wall when idling, but you need to add +0.3W for each inserted 100M ethernet jack, easily consuming more than the whole chipset if I insert 5 cables. Interestingly I've measured the same amount on a notebook and a netbook as well. Gigabit consumes much more, in the order of a watt maybe, but that can depend on a lot of factors.

Also it is near trivial to switch wifi on/off from software (for example via cron), but it is usually not possible to achieve the same amount of power saving without physically disconnecting the ethernet cable - something not possible in software.
1-2 lines of shell maybe by brute force from cron, a few more lines if you want to do it really efficiently (check whether there are any tasks waiting for upload, network up, ping something until it works, boinccmd --network_available, then wait a minute and/or parse out the logs or query boinccmd --get_file_transfers until it is empty, network down).

So running the network for 2.5 hours is a luxury. We could measure this easily, but if you have at least a 5Mb/s Internet connection, the few megabytes Rosetta uploads/downloads shouldn't tax you that much. I wouldn't be surprised if with efficient coding, you could actually get away with less than half an hour a day in total. If you increase WU runtime to communicate less, maybe even less.

This might sound like over doing it, but every watt counts in your rig efficiency and your temperatures.

Why does Ethernet go down when turning off USB? Can’t they be disabled independently?

Unfortunately, in this case, the ethernet is connected to the USB hub, so I shut down the USB hub together with the ethernet. I do not know how big the consumption is if you shut down only the ethernet module.
Ethernet module on 3B+ and 4 is 1Gb if I remember correctly, which is I guess it simply is not that well power-optimized.

This might sound like over doing it, but every watt counts in your rig efficiency and your temperatures.

Getting the carbon footprint (from both electricity consumption and hardware production) as low as possible should definitely be a priority.

Why does Ethernet go down when turning off USB? Can’t they be disabled independently?

Unfortunately, in this case, the ethernet is connected to the USB hub, so I shut down the USB hub together with the ethernet. I do not know how big the consumption is if you shut down only the ethernet module.
Ethernet module on 3B+ and 4 is 1Gb if I remember correctly, which is I guess it simply is not that well power-optimized.

This might sound like over doing it, but every watt counts in your rig efficiency and your temperatures.

Getting the carbon footprint (from both electricity consumption and hardware production) as low as possible should definitely be a priority.

On the pi4 Ethernet, poor choice to keep it attached to the usb hub instead of moving it independently to the pcie bus. I had read an article that stated that Ethernet had been moved, but it must have been incorrect.

It would be nice to use WiFi from a cabling perspective, but I’m potentially considering 20 Pi4s, and they will be across the house and on a different floor from the WiFi router. I know distance plays a part in WiFi power efficiency and that many devices will increase interference - especially when I stack pis in heatsink cases into a brick so they can be cooled with, potentially a single 120mm fan. I’ll give WiFi a shot, but I don’t have a good feeling about it.

Regarding the efficiency for pi 3 and 4 in Rosetta, I’m a little concerned that needing to use zram will reduce the points per watt to the point that it would be more efficient to use, say, a Ryzen 3950 or a threadripper 3990 (or whatever the zen 3 / Ryzen 4000 options are).