[QUOTE=ewmayer;509641]I think it's that key frequently-replacing-needing little parts cost an arm and a leg to buy standalone, relatively speaking. So if one can, without excessive labor, extract a dozen $10-value replacement parts from cannibalizing a broke-o-phone like this, it's well worth $50.[/QUOTE]
Really, consumer goods pricing can be way out of whack sometimes. I bought a new inexpensive printer recently, on sale for about half sticker price. That was less than the cost of the ink cartridges in the box. I think they're way overcharging for the cartridges; they are slender little things.

[QUOTE=kriesel;509643]Really, consumer goods pricing can be way out of whack sometimes. I bought a new inexpensive printer recently, on sale for about half sticker price. That was less than the cost of the ink cartridges in the box. I think they're way overcharging for the cartridges; they are slender little things.[/QUOTE]

Actually, that's all by design - they know ya can't use the printer sans cartridges, so they basically give away the former and then gouge the crap out of you on the latter, they're even working hard to keep people from refilling the things. And since you're using their software to manage the gear, there's another oppo for rent extraction - HP got busted a few years back for programming their printer diagnostics so as to signal "empty" when there was still plenty of ink left in the cartridges. This business model has metastasized into the whole "you don't have the right to repair it, even though you bought it" industry. Right-to-repair laws are only slowly catching up.

Usually, the included ink or toner cartridges are not completely filled.

:mike:

[QUOTE=ewmayer;509658]Actually, that's all by design - they know ya can't use the printer sans cartridges, so they basically give away the former and then gouge the crap out of you on the latter, they're even working hard to keep people from refilling the things. And since you're using their software to manage the gear, there's another oppo for rent extraction - HP got busted a few years back for programming their printer diagnostics so as to signal "empty" when there was still plenty of ink left in the cartridges. This business model has metastasized into the whole "you don't have the right to repair it, even though you bought it" industry. Right-to-repair laws are only slowly catching up.[/QUOTE]
I understand something like that model has appeared in large-pricetag agricultural equipment. (Think air conditioned computerized tractors, and harvesters with crop heads too wide to go down the road except on a trailer lengthwise.) Sure, you own the hardware, but you'll never own the software, and the hardware won't run without the software, so get used to opening up your wallet. This does not go over well with the very independent-minded farmers.

[QUOTE=kriesel;509810]I understand something like that model has appeared in large-pricetag agricultural equipment.[/QUOTE][url]https://motherboard.vice.com/en_us/article/xykkkd/why-american-farmers-are-hacking-their-tractors-with-ukrainian-firmware[/url]

:mike:

[QUOTE=Xyzzy;509821][URL]https://motherboard.vice.com/en_us/article/xykkkd/why-american-farmers-are-hacking-their-tractors-with-ukrainian-firmware[/URL]

:mike:[/QUOTE]I know someone who works over 1000 acres and has lots of IH equipment, no Deere that I recall.He has a harvester for harvesting, and another for parts. he does tractor splits and engine rebuilds in an unheated shed. I have a little 1947 tractor myself. As far as I know, the only semiconductors or software on it would be my cellphone when I'm on it.

At these prices (used), it's understandable farmers think they own it [URL]https://www.ebay.com/sch/i.html?_from=R40&_nkw=tractor&_sacat=0&_sop=16[/URL]

From the latest Galazy-S7-for-parts listings on eBay ... I restricted to ones in the $50ish range, screen seems to be working enough, and either listed as unlocked or no lock status listed (in which case I PMed the seller "Is the phone unlocked or does it have Factory Reset Protection?", so hopefully will know by tomorrow):

1. [url]https://www.ebay.com/itm/samsung-Galaxy-s7-edge-Verizon-For-Parts/401720665387?hash=item5d886ae52b:g:RiUAAOSw8KRcfHky:rk:8:pf:0[/url]

2. [url]https://www.ebay.com/itm/Samsung-Galaxy-S7-Edge-SM-G935U-Silver-Read-selling-for-parts/123601122744?hash=item1cc73375b8:g:qeYAAOSwkjJcQgu-:rk:13:pf:0[/url]

3. [url]https://www.ebay.com/itm/Samsung-Galaxy-S7-Edge-SM-G935A-32GB-Silver-AT-T-Smartphone-ASIS-for-Parts-B030/173813335211?hash=item28781504ab:g:19YAAOSw-YVcdV8C:rk:20:pf:0[/url]

4. [url]https://www.ebay.com/itm/Samsung-Galaxy-S7-edge-SM-G935A-32GB-silver-AT-T-phone-ASIS-for-Parts-B019/173745881059?epid=15024422733&hash=item28740fbfe3:g:B-QAAOSwK89cRhzF:rk:24:pf:0[/url]

Another n00b question: If they list e.g. "Carrier: AT&T|Verizon|T-Mobile|Whatever", deos that imply locked or not?

[QUOTE=ewmayer;510065]...
Another n00b question: If they list e.g. "Carrier: AT&T|Verizon|T-Mobile|Whatever", deos that imply locked or not?[/QUOTE]
Not necessarily bootloader locked but there's a higher chance it is than an unlocked network phone AFAIK. If there's a carrier it does mean locked network. For some models it means you need to flash with a different stock firmware than the unlocked counterpart if something goes wrong, and there may be differences in rooting between network locked/unlocked. One of my S7's is unlocked and the other locked to Three, no difference in the steps taken to root, the only differences are the splash screen and some bloatware.



To try and clear up any confusion there's many ways a device can be "locked":
[list][*]Carrier locked. When a seller says unlocked or a network is specified this is what they mean. It's not necessarily a deal breaker but it is another company that may have had a say in the status of the bootloader. There's normally a carrier splash screen on boot if it's locked or the device manufacturer's splash screen if unlocked
[*]Bootloader. This needs to be unlockable and is a deal breaker, most sellers won't know of its status or existence, and opening the dev menu to find out is involved enough that it'll be hard to convince a stranger it's worth finding out
[*]FRP locked. If a google account is associated with the device you need the credentials to get into android. This is a dealbreaker, but is only tripped if the device has been factory reset from the recovery menu not android itself[*]Account locked. If the device hasn't been factory reset but has an account with a password you need the password. Without it you can factory reset via the recovery menu but then you've tripped FRP and are in a worse position[*]Blacklisted IMEI. AFAIK being blacklisted wouldn't impede us but that needs testing, it definitely disables the devices ability to connect to a network which may make them cheaper to acquire. Blacklisting IMEI is meant to make stealing phones less lucrative
[/list]


Device #4 shows android unlocked so is good to go, #2 hasn't tripped FRP but only shows the android lock screen so it may be account locked, #1 and #3 may be FRP locked.

Thanks! Just ordered item #4 ... I see your Mlucas-setup script in post #51, did you also post a how-to-root somewhere in this thread?

From 0 to crunching
 

[LIST][*]Unlock the dev menu by finding the build number in settings and pressing it seven times[*]Unlock bootloader, this is in the dev menu, possibly elsewhere (or nowhere) depending on model. If you can't unlock the bootloader you're probably out of luck[*]Enable USB debugging and disable updates from the dev menu[*]You may need to keep the screen turned on when plugged in to keep the SoC active, this is also in the dev menu. Turn display brightness to minimal[*]Root device via flashing. Precise method depends on model, I used Auto-CF-Root to root an S7 which should work for most Samsung devices, YMMV ( [URL]https://www.mersenneforum.org/showpost.php?p=506758&postcount=25[/URL] )[*]Debloat android by uninstalling and disabling apps, disabling unnecessary services, location, sync, bluetooth etc[*]Install F-Droid, a FOSS repo, from f-droid.org[*]Install UserLAnd from F-Droid. This allows you to run a Linux environment[*]In UserLAnd there are four distros (Arch, Debian, Ubuntu, Kali), choose whichever one you're comfortable with. You'll be using ssh so it should make little difference in the end, but I had trouble configuring Debian so went with Ubuntu[*]Username is important as you'll use it to ssh into the device. If you set it to root you'll be root by default (which I don't recommend but there it is)[*]Install ssh, and while we're at it tmux (or equivalent multiplexer), nano (or equivalent text editor), lm-sensors (to read SoC temperature sensors) and git (in Ubuntu do "sudo apt install tmux ssh lm-sensors nano git")[*]Find the LAN ip of the device (on the device in Ubuntu with "hostname -I", with nmap or equivalent on a Linux machine connected to the LAN, or in the router settings)[*]Use ssh to connect to the device from your computer (on Windows you need putty). My device defaults to port 2022, if this doesn't work scan the device's ip with nmap[*]To be able to log in with your computers public key instead of a password, copy it into .ssh/authorized_keys . This also allows you to easily use scp from scripts. Harden ssh as you see fit[*]Type "tmux" to be able to use multiple terminals in the same session and allow the programs to keep running if disconnected. As a crash course, by default CTRL+B followed by " or % will create new terminals, swap between terminals with CTRL+B followed by an arrow key, close a terminal with "exit", resize the current terminal by holding CTRL+B and pressing an arrow[*]Put the mlucas binary at ~/mlucas[*]Clone the c3tools with "git clone https://github.com/sillygitter/c3tools"[*]Find the best worker config for the SoC and pass it to the setup script. Each argument is another worker and the contents defines the CPU config passed verbatim to mlucas. Even with the setup script you're likely going to need to babysit through some quirks. (For example Exynos 8890 has 8 cores, only 6 are assignable but testing shows 8 workers has the best throughput, "setup 0 1 2 3 4 4 5 5") (Helio X25 has 10 cores in 3 clusters, they only show up in /proc/cpuinfo and to mlucas when under load. Sometimes mlucas will complain but the worker still works, sometimes it'll complain and the worker will not start. 5 workers for the most throughput, no good way to initialise to ensure all workers work. "setup 0,1 0,1 0,1 0,1 0,1")[*]The setup script creates the worker directories and one at a time generates mlucas.cfg with the other workers under synthetic load. This may not go smoothly if the SoC is a piece of work, for example with the Helio X25 there's a good chance one of the workers fails to start. It may also be a waste of time to generate mlucas.cfg individually if every worker is the same. In this case you can optionally quit the script after it's generated the first mlucas.cfg, "pkill mlucas" and copy-paste the mlucas.cfg to the rest of the workers to save some time[*]The workers should be good to go but should be sanity checked[*]Once everything is set up I recommend only connecting the device to a LAN with no access to WAN[/LIST]
The scripts might need shoring up a bit, I'll try to look at them before you try them. Locally I've at least switched from hard coded human-readable worker directories to numbers and there may be a few more things too.

Just heard back from seller of item #2 in post 104 above - "It is unlocked and doesn't have any accounts linked to it."

$59.99 a tad pricey for my purposes however - seller doesn't have Make Offer enabled, but PMed to offer $49.99.

[QUOTE=ewmayer;510354]Just heard back from seller of item #2 in post 104 above - "It is unlocked and doesn't have any accounts linked to it."

$59.99 a tad pricey for my purposes however - seller doesn't have Make Offer enabled, but PMed to offer $49.99.[/QUOTE]So seller's willing to deal; make him a counteroffer.

[QUOTE=kriesel;510356]So seller's willing to deal; make him a counteroffer.[/QUOTE]

I may have phrased that poorly - I meant that I was gonna offer him that amount, once I'd ascertained that the phone would likely suit my compute-node needs ... I ended up offering a round $50, since you don't want to use the penny-less psych-trick when you're on the bid side of things ... phone is on its way.

I saved the details of both ebay listings for the 2 S7s I bought, if one proves "unsuitable and unrootable" or whatnot, I can just put it back up as a for-parts sale item. But I hope both will suit!

[QUOTE=M344587487;508226]Without rooting I haven't found a way to get the mlucas ELF binary to run but I could just be ignorant. With an APK you definitely don't need a rooted phone and the overhead may be minimal. The gist is you need to compile mlucas into a library function using the NDK then call it using the JNI from a barebones java app. Every app has a writable directory which the user can access which can contain the working directories.

Had a quick peek at the NDK example in android-studio weeks ago but attempting to modify it into something more complicated defeated me due to inexperience with CMakeLists among other things. It doesn't look too complicated for someone competent, the next time I'm feeling masochistic I might give it another go. If going the APK route there is a small complication in that without jumping through some annoying hoops you can only run one instance of an app, so the java wrapper will need basic worker management built in.[/QUOTE]

Re. nonrootable phones - would an actual Android dev-tools build solve that problem, by allowing the binary to run sans any hackery? If so, that would seem to be called for - owners of rooted phones can simply use the ARM/linux build, the rest can use the Android build. That would greatly ease the logistics of acquiring broke-o-phones on the cheap with which to run code.

Are there any folks aound here who've used the Android dev-tools? From M344587487's above summary it sounds like we need:

o Mlucas build-from-source under Android dev-kit; is that GCC-based?

o Some kind of runscript to encapsulate multiple instances of the Mlucas binary, each running on some subset of cores, so at top level that looks like a single app instance running;

o Need to make sure runscript plays nice with the primenet.py script Mlucas uses to manage assignments (one instance of primenet.py active in each separate run directory being used by an Mlucas instance).

Lastly, re. portability - would we need one build version of the app for each major Android version, what?

BOINC runs code on androids using an app it might be possible to use that framework. [url]https://boinc.berkeley.edu/wiki/Android_FAQ[/url]

The need for an APK was based on my mistaken belief that the device needed to be rooted to run ELF binaries (when I initially tried that was true but I probably did something wrong), and that an unrooted solution would be nice to lower the barrier of entry. In reality unrooted devices can run ELF binaries, so you just need to setup a Linux environment and treat the device as you would a normal computer. The basic steps are this:
[LIST][*]Optionally root. This would allow you to debloat more than an unrooted device and install custom roms if you want to get your hands really dirty[*]Clean the device. Factory reset if necessary, debloat by uninstalling what can be uninstalled and disabling what can be disabled. Connect to wifi with WAN access[*]Enable the dev menu by pressing the build number 7 times. In the dev menu disable updates, keep the screen awake when charging and enable USB debugging.[*]Install F-Droid, a FOSS repo for android apps from here: [URL]https://f-droid.org/[/URL][*]Install UserLAnd from F-Droid, an app that lets you run a Linux environment[*]Install an Ubuntu environment in UserLAnd using ssh as the method of communication. The username and password are important as they are the login credentials for ssh[*]In that environment install ssh with "sudo apt install ssh"[*]In that environment find the devices ip with "hostname -I" (I as in capital eye)[*]On your computer install ssh and connect to the same network that the device is on. Logging in to the device can be done with a command like this with the username and password you used in the UserLAnd step, "ssh -p 2022 username@ip_address"[*]You should now be logged into an ssh session. The device can now be treated roughly as you would a normal Linux computer. Compile mlucas using gcc or copy the c2simd build from the readme page. Optionally use the c3tools scripts (from [URL]https://github.com/sillygitter/c3tools[/URL] ) to help automate creating workers with the correct cpu flags for benchmarking or production[*]Once you're completely done with setting the device up I recommend disconnecting from the WAN permanently so that nothing can receive a forced update and break itself.[/LIST]I'm working on a guide to help explain the process, maybe a PDF with screenshots, a video showing the process from start to finish or both. There's nothing fancy going on but it may look tricky if you're not familiar with Android or more importantly Linux.

Yes, with Matt's help and my "is there a simpler way" smartphone-n00bness questioning we have drastically simplified the setup of such a phone as an Mlucas compute node - several of the steps in matt's above post can be eliminated, too, more on that later in the week. Not needing to root should also greatly increase the pool of eligible devices and users. For my end, needing to build just a single Linux binary (well, 2, actually, one non-SIMD, one with-SIMD) which is usable on Raspberry Pi, Odroid and other micro-PCs as well as on Android phones is a big plus.

I'm busy doing timing tests using my Odroid-built ARMv8 binary on one of the two broke-o-phone S7s I bought on ebay, it's quite clear cooling is going to be *very* important to get close to the CPUs' peak throughput, because even the [url=https://www.amazon.com/AC-Infinity-MULTIFAN-Receiver-Playstation/dp/B00MWH4FL4/ref=sr_1_2_sspa?keywords=usb+cooling+fan&qid=1552340198&s=gateway&sr=8-2-spons&psc=1]140x140 mm USB cooling fan[/url] I bought to blow air over the USB charging station which will act as a rack for 4-5 phone isn't cutting it.

It seems to me this broken-hardware-repurposed strategy applies also to for-parts laptops of various sorts. There's a wide variety available.

Cracked display, flaky keyboard, bad clamshell hinges, dead or absent hard drive, dead battery, absent dvd/cd, and dead either wired or wireless networking connection but not both, leaving one functional connect path, working processor and RAM, plus a working USB port, a bootable USB stick with the OS and application and some work space and space for logging, seems like the minimum, as long as there's a way to set it to boot from USB.

Running headless /remotely is common for linux servers and also routine for Windows servers.

[QUOTE=kriesel;511257]It seems to me this broken-hardware-repurposed strategy applies also to for-parts laptops of various sorts. There's a wide variety available.[/QUOTE]

True, but the sheer numbers of smartphones bought/broken each year dwarfs evrything else, I expect - and the small size and common-ways-these-get-broken makes it easy to buy in volume. Now that we've determined we don't need to root them and got the whole setup procedure down to just few minutes, we can look for ones where the screen and touch functionality mostly work, but various kinds of damage make them unsuitable for regular-phone usage, a very common combination. I'm looking for lots of for-parts S7s on ebay - for instance I am considering offering $350 for [url=https://www.ebay.com/itm/LOT-OF-10-Samsung-Galaxy-S7-Active-SM-G891A-32GB-Gold-CRACKED-GLASS-LINES/254032533030]this lot of 10[/url], only waiting to hear definitive word from the seller as to whether they have FRP-locking or not. I really only can handle 4-5 more before maxing out my 5-port charging station and a few unused USB ports on devices nearby on my desk - anybody wanna go halvsies here?

The only other damage-related criterion I've run into from my first 2 broke-o-phones is that the metal caseback should be more or less intact, especially in the crucial area over the row of hot chips, where a strip of thermal tape conducts heat from the metal chip-holder backs to the metal caseback. My case-intact S7 runs a DC at 2816K FFT length @48 ms/iter 'cold', but throttles back to 64 ms/iter under 24/7 load, under the modest airflow the 0.8W USB fan I bought to blow air over the charging station provides. That's a 25% throughput reduction due to throttling. The other S7 has a loose caseback, and even jammed on there as tightly as I can manage, goes form 54 ms 'cold' to 81 ms in 24/7 mode at the same 2816K FFT length, a 33% throughput reduction. A beefier fan would help with that, as well, of course.

[QUOTE=ewmayer;511361]The only other damage-related criterion I've run into from my first 2 broke-o-phones is that the metal caseback should be more or less intact, especially in the crucial area over the row of hot chips, where a strip of thermal tape conducts heat from the metal chip-holder backs to the metal caseback. My case-intact S7 runs a DC at 2816K FFT length @48 ms/iter 'cold', but throttles back to 64 ms/iter under 24/7 load, under the modest airflow the 0.8W USB fan I bought to blow air over the charging station provides. That's a 25% throughput reduction due to throttling. The other S7 has a loose caseback, and even jammed on there as tightly as I can manage, goes form 54 ms 'cold' to 81 ms in 24/7 mode at the same 2816K FFT length, a 33% throughput reduction. A beefier fan would help with that, as well, of course.[/QUOTE]Pull the back off and place a small heat sink on the CPU. Square shaped heatsinks with fins are easy to find, and they often come with a sticky pad all ready to attach.

[QUOTE=retina;511363]Pull the back off and place a small heat sink on the CPU. Square shaped heatsinks with fins are easy to find, and they often come with a sticky pad all ready to attach.[/QUOTE]

I tried that, and ran into a nasty little surprise - speed dropped by half. Snapped caseback back on, back to normal. There seems to be some kind of built-in sensor in there somewhere that detects if the back is off. No-back also makes it much dodgier to take phone in hand and e.g. fiddle with settings and such, which I am finding myself doing a couple times day, at least during this early debugging-the-setup stage of the experiment. (For instance I just discovered that one of the 2 phones had an put-apps-to-sleep feature enabled for power saving, clearly not something good for my purposes.)

[QUOTE=ewmayer;511364]I tried that, and ran into a nasty little surprise - speed dropped by half. Snapped caseback back on, back to normal. There seems to be some kind of built-in sensor in there somewhere that detects if the back is off.[/QUOTE]That would suggest that rooting the phone is needed. Get rid of the annoying Google-phone-home code, and the reduce-clocks-with-no-back code, and whatever-other-bad code hiding in there.

[QUOTE=ewmayer;511361]True, but the sheer numbers of smartphones bought/broken each year dwarfs evrything else, I expect - and the small size and common-ways-these-get-broken makes it easy to buy in volume.[/QUOTE]
Sheer numbers:[CODE]A quick check on ebay now, by category, all models:
cell phones, for parts or not working, qty 33970
laptop, for parts or not working, qty 12590
desktop, for parts or not working, qty 1202[/CODE]Advantage cell phones on number (2.7/1 over laptops).

Processing power per unit is likely to favor laptops.
Processing power per watt, probably cell phones.
Processing power per dollar, who knows.
If laptops break due to age and cellphones due to rough and constant handling, the broken phones would be newer than the broken laptops and so tech in the broke phones would be more current and more power efficient.
For those of us that it matters, laptops are a more straightforward path via Windows.

[QUOTE=kriesel;511408]Advantage cell phones on number (2.7/1 over laptops).[/QUOTE]Also processing power per unit volume is likely to favour mobiles.
(How many could one house in an old desktop case with some shelves rigged up? The case fan could help cooling.)
A few of [URL="https://www.webstaurantstore.com/10-1-2-round-steamer-rack/922STR1050.html"]these kitchen cooling racks[/URL] or [URL="https://www.amazon.co.uk/PME-Carbon-Non-Stick-Cooling-10-Inches/dp/B00LRP9G1Q"]these in the UK[/URL] would allow one to quickly and cheaply stack them up fairly densely.

I made a $350 offer on the lot of 10 I linked, which was accepted. Given the loose-back and underperformance issues with the 1 of the 2 phones I used as guinea pigs, decided to put that one back up 4 sale, along with any of the upcoming 10 which for one reason or another don't pass 24/7-run muster. Since my needs are a bit more specialized than the average for-parts buyer I figure I can resell the leftovers for roughly what I paid.

Re. physical setup, the 5-port USB charging station I bought has plastic dividers that slot each device in its own 2cm-wide slot. You can get USB-to-uUSB cables as short as 4 inches to minimize cable tangling. The 0.8W USB fan I have blowing air over the assembly is super quiet. Since one of the reqs for using these as a compute node is working WiFi, once one has Mlucas installed and the primenet.py script checking twice a day whether any comms with the Primenet server are needed, it's set-it-and-forget-it. One can ssh in to each node occasionally to check status if one likes; a more simple "is it crunching?" check is to simply touch a fingertip to the section of the caseback covering the CPU to gauge the temperature. It'll be interesting to see the evolution of the price/performance metrics as newer phone models roll out - of course traditional desktop/deskside compute hardware is ever-evolving as well, so the question is whether those two kinds of hardware are on similar $/FLOP trajectories over time or whether one is ramping up more quickly than the other.

Another nice aspect of the phones is - assuming the battery works, even if not 100% - that they have built-in UPSes. I'll want to fiddle the settings so that any Watt-sucking apps like Mlucas get put to sleep when the phone is running off battery power.

[QUOTE=Uncwilly;511416]Also processing power per unit volume is likely to favour mobiles.
(How many could one house in an old desktop case with some shelves rigged up? The case fan could help cooling.)
A few of [URL="https://www.webstaurantstore.com/10-1-2-round-steamer-rack/922STR1050.html"]these kitchen cooling racks[/URL] or [URL="https://www.amazon.co.uk/PME-Carbon-Non-Stick-Cooling-10-Inches/dp/B00LRP9G1Q"]these in the UK[/URL] would allow one to quickly and cheaply stack them up fairly densely.[/QUOTE]
Laptops already have a built in cooling system.
They can typically be stood on edge with display plane at right angles to keyboard plane to increase areal density when the UI is not in active use. (Inverted V might be too precarious.) A wire shelf unit to hold dozens of powered laptops with minimal air flow obstruction is under $100 US. [URL]https://www.menards.com/main/storage-organization/garage-outdoor-organizers/freestanding-shelving-units/sandusky-lee-reg-48-w-x-72-h-x-18-d-6-shelf-wire-shelving-unit/ws481872-z/p-1481786334276-c-12652.htm?tid=-2286065336124355195&ipos=30[/URL] I have my GIMPS laptops on one of the wall-attached wood shelves that came with the house.

The real limit is not feasible power density, but how much power can be dissipated into the room(s) where the compute farm is housed. That is typically reached well before volume of the computing gear becomes an issue, with laptops or towers or cell phones. That consideration is particularly significant as the heating season in the northern hemisphere, where most of the human population lives, is coming to an end, and air conditioning season approaches.

For a given computing throughput, there are advantages to having it be fewer units to administer (few but fast systems) rather than more (many but slow systems). I'm already using spreadsheets to keep track of patch and application update status, without housing a hundred compute phones. I'd much rather set up and maintain one 16-Intel-core system perhaps with a couple gpus, than 20+ phones to try to match the throughput.

Any approach has pros and cons. And exploring multiple approaches has value.

[QUOTE=kriesel;511441]Any approach has pros and cons. And exploring multiple approaches has value.[/QUOTE]

In the server stack domain, there is a long established concept of the "hot aisle" and the "cold aisle".

This gets even so detailed such that in a 42U rack there are to be blanker plates installed, such that there are never "short circuits" in the cooling airflow between the back of the machines and their fronts.

Considering this kind of experience to what we're talking about here might be of value.

[QUOTE=ewmayer;511438]Since one of the reqs for using these as a compute node is working WiFi, once one has Mlucas installed and the primenet.py script checking twice a day whether any comms with the Primenet server are needed, it's set-it-and-forget-it. One can ssh in to each node occasionally to check status if one likes; a more simple "is it crunching?" check is to simply touch a fingertip to the section of the caseback covering the CPU to gauge the temperature.[/QUOTE]
For scaling to larger counts, how about a cron job on each device that regularly checks when each mlucas log file was last modified, and if it's too old, sends something to a single syslog server? That could work for both cpu based and gpu based apps, and gives one place to check for AWOL alerts for all app instances of a fleet of hardware, whether a stoppage is due to a hung or crashed app or phone, primenet or internet outage. (Or NFS central log location, and modification-time sort the directory listing. Keying on low cpu utilization as in top doesn't handle the gpu-application case.)

[QUOTE=kriesel;511450]For scaling to larger counts, how about a cron job on each device that regularly checks when each mlucas log file was last modified, and if it's too old, sends something to a single syslog server? That could work for both cpu based and gpu based apps, and gives one place to check for AWOL alerts for all app instances of a fleet of hardware, whether a stoppage is due to a hung or crashed app or phone, primenet or internet outage. (Or NFS central log location, and modification-time sort the directory listing. Keying on low cpu utilization as in top doesn't handle the gpu-application case.)[/QUOTE]

Yes, something along these lines definitely seems called for in the context of managing multiple compute nodes. I'm already in the process of enancing the primenet.py script to send regular job-progress updates to the server ... maybe also do a last-logfile-update-too-old check and e-mail the user if that triggers? The updated script will use entries in a local.ini file to manage job-progress updates, no reason this couldn't include a contact e-mail and user-set machine ID.

[QUOTE=chalsall;511443]In the server stack domain, there is a long established concept of the "hot aisle" and the "cold aisle".

This gets even so detailed such that in a 42U rack there are to be blanker plates installed, such that there are never "short circuits" in the cooling airflow between the back of the machines and their fronts.

Considering this kind of experience to what we're talking about here might be of value.[/QUOTE]Well, of course, as an experienced trained engineer (and someone who's built server & network gear racks) I considered heat transfer and fluid mechanics. What's the likely wattage in a filled server rack in that well air conditioned server farm scenario? [url]https://datacenterfrontier.com/roundtable-rack-power-densities-rising-but-slowly/[/url] shows averages of 6kw and up, for some, WAY up, per ~0.6m lateral space (~10kw/meter or more). I did not get the sense that anyone's proposing to individually implement a thousand-cellphone compute farm to hit 5KW load, and spend ~$50k for a pallet of broke-o-phones. In a server farm scenario, density matters and more energy is spent moving air or liquid coolant and removing heat. In my environment density is not a virtue. (The incremental cost of the real estate is zero. The cost of active cooling is to be reduced or eliminated by using low energy density.) The shelf unit full of laptops is likely to be not much more than about the equal per lateral meter of floor space that I have sitting on carpet with no fancy AC for it, in the form of hefty workstation towers running near max power ~1kw/meter. The lower levels of laptops would give the upper a somewhat higher ambient, since after the laptop fans do their thing the exhaust will rise by natural convection. 18 laptops at 30W each positioned as for normal use / 1.2m =0.45kw/meter. For on-edge herringbone arrangement, 8/shelf, 8*6=48 x 30W / 1.2m = 1.2kw/meter. Laptops count in normal use for their cooling air flow on the little ~1mm gap between case bottom and supporting surface created by little bump feet at the corners. They're really no longer supported for use on a person's lap because it may interfere with air access to the grill. That narrow 1mm gap must restrict air flow. A wire rack shelf would let the laptop breathe easier.

The "domino effect" is another issue. I'm not seriously proposing standing them on edge, unsecured, around pets or small children or in earthquake zones.
If there are toddlers or preschoolers around, all shelf units, big screen tvs, etc, should be securely fastened to the wall, and great care taken with anything electrical including outlets, for the safety of the little feral climbers and anyone else nearby.

[QUOTE=ewmayer;511453]Yes, something along these lines definitely seems called for in the context of managing multiple compute nodes. I'm already in the process of enhancing the primenet.py script to send regular job-progress updates to the server ... maybe also do a last-logfile-update-too-old check and e-mail the user if that triggers? The updated script will use entries in a local.ini file to manage job-progress updates, no reason this couldn't include a contact e-mail and user-set machine ID.[/QUOTE]
I'm experimenting with appending an application exit message to an app instance-specific file in a central file server folder. Automatic modification date/time sort will float the most recent entries to the top. The file names will tell me what system, what gpu, what worker instance needs attention. And my email client won't get flooded with multiple emails when batch scripts loop; the files just get a bit bigger. And it's all local, so the utility contractors can cut the internet connection again and it still works. Also immune to errant spam filtering.

It turns out that n systems x 2 gpus each x 3 work types (+ here and there a second mfaktc instance or cudapm1 version or multiple gpuowl versions for best fft-specific speed) and maybe some mlucas or whatnot added to the cpu side really adds up.

Another avenue that occurred to me for users to easily oversee many-device-farm work: Assuming the client provides regular progress updates to the Primenet server - which I already have working, it just needs an automated way for the server to provide the 32-char GUID it creates for each manual test account to the user (and/or the primenet.py script), Aaron is experimenting with some things there. Then, if a user could click a link to "active assignments", which would bring up a simple page listing same 1 per line with some sensible sort options (most-recently-updated, smallest-to-largest exponent, date-assigned, etc), there you go - just view by longest-time-since-last-update and (since the script does updates every 12 hours by default) look for entries older than 12 hours at top of the list. Refresh page once per day.

[QUOTE=ewmayer;511475]Another avenue that occurred to me for users to easily oversee many-device-farm work: Assuming the client provides regular progress updates to the Primenet server - which I already have working, it just needs an automated way for the server to provide the 32-char GUID it creates for each manual test account to the user (and/or the primenet.py script), Aaron is experimenting with some things there. Then, if a user could click a link to "active assignments", which would bring up a simple page listing same 1 per line with some sensible sort options (most-recently-updated, smallest-to-largest exponent, date-assigned, etc), there you go - just view by longest-time-since-last-update and (since the script does updates every 12 hours by default) look for entries older than 12 hours at top of the list. Refresh page once per day.[/QUOTE]Making use of primenet as feasible is a given. The several ways a user's assignment page can be order sorted is very handy. I find sort by expiration date useful. Unfortunately gpu apps have not a primenet interface. For gpu GIMPS activity, all work types, all instances, all gpus get lumped into the single manual assignment heap per user id. And there's no progress reporting of gpu apps, so only assignment and result. Perhaps what you're working on for mlucas is a step on the way to getting primenet ready for gpus. The nature of the primenet and gpu apps status quo is why I'm exploring stopgap approaches for gpu apps. (And cell phones have little gpus.)

[QUOTE=kriesel;511515](And cell phones have little gpus.)[/QUOTE]
I wonder though, how easy (or hard) it would be to adapt something like mfakto to cellphone GPUs. Even though it is "OpenCL" it seems heavily AMD dependent. There are OpenCL interfaces available for stuff like VideoCore IV (Raspberry Pi), ARM Mali (many cellphones including Samsung and Huawei) but I haven't explored that any further.

[QUOTE=nomead;511517]I wonder though, how easy (or hard) it would be to adapt something like mfakto to cellphone GPUs. Even though it is "OpenCL" it seems heavily AMD dependent. There are OpenCL interfaces available for stuff like VideoCore IV (Raspberry Pi), ARM Mali (many cellphones including Samsung and Huawei) but I haven't explored that any further.[/QUOTE]I wonder about that too. But I'm running mfakto right now on a couple of Intel igps. It's been done for nonAMD before, by BDot.
Another thing to wonder about is how the gpu using part of the cell phone power budget would affect mlucas throughput on the cpu cores. I see around a 50% hit in prime95 on the Intel igp use in laptops. If totalling raw GhzD/day, it's a win to run the igp on my laptops. If scaling to % primality test throughput and % TF throughput running independently it may not be. If scaling igp TF downward by ~15:1, it is not. And gpus can run PRP or LL or P-1, although that is I think a harder porting problem than TF. Another consideration is the Intel igps tend to be small throughput, ~5-20 GhzD/day on TF depending on model and input parameters, and unsuitable for DP computations usually used for PRP or LL or P-1.

[QUOTE=nomead;511517]I wonder though, how easy (or hard) it would be to adapt something like mfakto to cellphone GPUs. Even though it is "OpenCL" it seems heavily AMD dependent. There are OpenCL interfaces available for stuff like VideoCore IV (Raspberry Pi), ARM Mali (many cellphones including Samsung and Huawei) but I haven't explored that any further.[/QUOTE]
I've mildly explored that avenue but didn't manage to get a working OpenCL stack with Mali. The idea has potential as modern phones need a higher proportion of GPU grunt although that may boil down to ASICs for things like video encode/decode. Some of the newer devices have 6GB of RAM or more, any chance they're interesting for P-1 stage 1?

[QUOTE=kriesel;511522]I wonder about that too. But I'm running mfakto right now on a couple of Intel igps. It's been done for nonAMD before, by BDot.
Another thing to wonder about is how the gpu using part of the cell phone power budget would affect mlucas throughput on the cpu cores.[/QUOTE]

If someone can get *any* kind of igp-heavy app running side-by-side with Mlucas on a phone, that would certainly be an interesting experiment in terms of looking to maximize total compute throughput of such a device.

[QUOTE=M344587487;511525][In reply to nomeand]I've mildly explored that avenue but didn't manage to get a working OpenCL stack with Mali. The idea has potential as modern phones need a higher proportion of GPU grunt although that may boil down to ASICs for things like video encode/decode. Some of the newer devices have 6GB of RAM or more, any chance they're interesting for P-1 stage 1?[/QUOTE]

P-1 stage 1 needs no more memory than an LL test ... when you speak of GB-levels of RAM you're talking about stage-2-capable. Adding p-1 support to Mlucas is on my long-term roadmap, but given the relative amounts of project throughput dedicated to p-1 vs LL/PRP, it's a lower priority than "growing market share" in the latter area.

[QUOTE=M344587487;511525]I've mildly explored that avenue but didn't manage to get a working OpenCL stack with Mali. The idea has potential as modern phones need a higher proportion of GPU grunt although that may boil down to ASICs for things like video encode/decode. Some of the newer devices have 6GB of RAM or more, any chance they're interesting for P-1 stage 1?[/QUOTE]
More RAM is better, in stage 2, and even at 1GB, gpus can usefully participate for years to come. See [URL]https://www.mersenneforum.org/showpost.php?p=489365&postcount=7[/URL] and consider that we're currently at 90M for P-1 wavefront and advancing at about 6M/year; (177-90)/6= 14.5 years. The 100Mdigit exponents' P-1 is practical with 4GB. TF is the less difficult programming job. An issue with igps can be a lack of DP capability, which can eliminate PRP, LL, and P-1 as porting possibilities for them. (The Intel HD620 showed up as SP only, so, fine in TF via mfakto, but no go in gpuowl which utilized the cpu OpenCL instead, taking more cycles away from prime95 than gpuowl throughput made up for.)

Would-be gpu developers ought take note of the recent Radeon VII find that two processes are better throughput than one even in the very efficient gpuowl. I've confirmed there's a small advantage also on RX480. There's also some advantage to multiple processes running on a gpu on mfaktc, with the % throughput advantage increasing with faster gpus. (On a gtx1080Ti, there's ~3% gain, 1070 1-2%; considerably more on an RTX20xx.) This is so even after fully tuning mfaktc.ini for performance. There are multiple possibilities why this may be so, and multitask gpu applications could exploit it for higher throughput. Some intervals to exploit may be very brief, as when mfaktc writes a checkpoint file or finishes a class and writes console output. Others can be quite lengthy, such as when the data are moved from gpu to cpu for computation of a gcd on a single cpu core in cudapm1, which can take around an hour on a large exponent and older cpu model, while the gpu sits idle in the one instance one task case (with a lot of its memory allocated for the duration).

Took delivery yesterday of a [url=https://www.ebay.com/itm/GREAT-Samsung-Galaxy-S7-active-SM-G891-32GB-Gold-AT-T-Unlocked-HAS-LINE-SHADOW-/163513148646?oid=254032533030]lot of 10[/url] S7 Active phones (pic below, or click preceding link), seller was asking $400, I paid $350. Just finished setting first of these up - looks like they were wiped and basic-software-reinstalled by seller, after powerup it took an annoyingly long time to work through multiple "click here to let us data-suck your entire life" menus from google, samsung, etc, many of which make it *really* hard to decline the offered 'service'. Hopefully the annoyance will be worth it by these ending up with less spy/crap/bloatware than typical. I didn't need to activate the sekrit developer options (the find-sekrit-widget-and-click-7-times-while-chanting-the-magic-incantation deal), just needed to press 'Allow' for various things in order to copy the Userland APK file from my macbook over to the phone's Download folder. Mlucas is up and running on a 2816K-FFT DC - the one thing about these which differs from my first pair of S7s is that the "S7 Active" models are wrapped in a rubberized plastic skin around the side and back. Among other things, said skin covers the area where the CPU is, and I'm worried that is going to make the throttling problem even worse. I like the skins as far as easier handling, especially for us spastic types who can barely even look at a smartphone without touching something unintended, but are they easily removable, should they indeed prove to exacerbate the throttling problem?

One other thing I've noticed - disabling WiFi after firing up Mlucas cuts runtime as much as 5% (of course I have to fondle the phone to check that, sans WiFi and the ssh-from-my-laptop capability it enables) - makes sense, one less hot chip inside the package. But therein lies a conundrum, because run management (either manual or via the primenet.py script) needs WiFi on. What would be really useful would be a way for the app (in my case the aforemention py-script) to enable WiFi on the device as-needed, do its I/O and then shut the WiFi down. But I'm guessing in the context of the kind of code I'm running that's not going to be possible. Can anyone more knowledgeable re. Android app-development comment?

[QUOTE=ewmayer;512336]disabling WiFi after firing up Mlucas cuts runtime as much as 5% (of course I have to fondle the phone to check that, sans WiFi and the ssh-from-my-laptop capability it enables) - makes sense, one less hot chip inside the package. But therein lies a conundrum, because run management (either manual or via the primenet.py script) needs WiFi on. What would be really useful would be a way for the app (in my case the aforemention py-script) to enable WiFi on the device as-needed, do its I/O and then shut the WiFi down. But I'm guessing in the context of the kind of code I'm running that's not going to be possible. Can anyone more knowledgeable re. Android app-development comment?[/QUOTE]Does the wifi respond to ifup and ifdown? [URL]https://ccm.net/faq/1141-restart-network-interface-using-command-lines-in-linux[/URL]
[URL]https://www.oreilly.com/library/view/linux-security-cookbook/0596003919/ch03s02.html[/URL]

Little linux expertise here, but how about launching the computing task at bootup, and a separate daily cron job that periodically does primenet communication, and gives you an hour window for remote management by ssh? Job might be something like

ifup (wifi interface)
short delay
run Python result submission and work queue refill
start ssh server
copy log and interim results backup files to local cache server
one hour delay
(warn of imminent shutdown of ssh server, on any open terminals, followed by some delay?)
stop ssh server
update time sync if not automatic
brief delay
ifdown (wifi interface)

Seems like some quick interactive experimentation with an ammeter on an otherwise idle phone with no battery, fed power by microUSB would show what effect if any there is on power consumption, of the various commands in the Oreilly page, or others.

But maybe it's only possible to turn it off interactively on the physical system.
[URL]https://www.linux.org/threads/can-not-turn-on-off-the-power-on-wi-fi.10526/[/URL]

If you can't get it to turn off by program control, maybe some really aggressive wifi power management (near zero transmit power) would get you part of the power savings and allow scheduled or program control of power. What can be increased, can usually be decreased.
[URL="https://www.hacking-tutorial.com/hacking-knowledge/increase-wifi-signal-strength-tx-power-on-kali-linux/"]https://www.hacking-tutorial.com/hacking-knowledge/increase-wifi-signal-strength-tx-power-on-kali-linux/
[/URL]Also layout and construction materials selection to minimize the transmit power needed when on. (I wonder how a little rack of 5 phones in close proximity affects that, especially if their ifup times overlap.)

Although it does not appear to be the same as the hardware enable/disable switch, maybe rfkill will help. [URL]https://www.digimantra.com/linux/rfkill-enabledisable-wireless-linux-laptop/[/URL] [URL]https://linux.die.net/man/1/rfkill[/URL]

Update on my note yesterday re. the rubberized sleeve on the batch of S7 Active phones I bought - the timings for my 2816K DC started more or less the same as on the faster (because case was intact, the other phone has loose backplate which hurts heat transfer from CPU to caseback) of my 2 non-sleeved S7s: self-test timing (I ran these one FFT length at a time, allowing 5 mins cooldown between lengths, to get as close to non-throttled timings as I could) ~50 ms/iter at that FFT length, first 10000-iter checkpoint showed 64 ms/iter, but instead of running stably at that as does the unsleeved phone, the S7 Active timings rise anothe 5-6%, now stabilized ~68 ms/iter.

Also, I didn't need to enable Developer Mode for the software install, but a few hours after starting my DC run was reminded why I need it - one needs to use dev-mode to enable "screen always active" to keep the phone from sleeping or going into some other kind of low-wattage torpor.

Now, to Ken's excellent suggestions (thanks for the research!):

o /sbin/ifconfig -a ... that needs me to 'sudo apt install net-tools', once done the result on this phone is as below, I'm guessing 'wlan0' is the wifi interface:
[code]dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500
inet6 fe80::a0f5:9dff:fe4e:9e4f prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 210 (210.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

epdg0: flags=4240<POINTOPOINT,NOARP,MULTICAST> mtu 1430
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

epdg1: flags=4240<POINTOPOINT,NOARP,MULTICAST> mtu 1430
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

epdg2: flags=4240<POINTOPOINT,NOARP,MULTICAST> mtu 1430
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

epdg3: flags=4240<POINTOPOINT,NOARP,MULTICAST> mtu 1430
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

epdg4: flags=4240<POINTOPOINT,NOARP,MULTICAST> mtu 1430
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)
RX packets 394 bytes 36412 (36.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 394 bytes 36412 (36.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

p2p0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet6 fe80::d8c4:6aff:fe13:12e8 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_data0: flags=0< mtu 1500
netrom txqueuelen 1000 (AMPR NET/ROM)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_data1: flags=0< mtu 1500
netrom txqueuelen 1000 (AMPR NET/ROM)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_data2: flags=0< mtu 1500
netrom txqueuelen 1000 (AMPR NET/ROM)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_data3: flags=0< mtu 1500
netrom txqueuelen 1000 (AMPR NET/ROM)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_data4: flags=0< mtu 1500
netrom txqueuelen 1000 (AMPR NET/ROM)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_data5: flags=0< mtu 1500
netrom txqueuelen 1000 (AMPR NET/ROM)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_data6: flags=0< mtu 1500
netrom txqueuelen 1000 (AMPR NET/ROM)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_data7: flags=0< mtu 1500
netrom txqueuelen 1000 (AMPR NET/ROM)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

rmnet_ipa0: flags=65<UP,RUNNING> mtu 2000
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

sit0: flags=128<NOARP> mtu 1480
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.21 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::dac4:6aff:fe13:12e8 prefixlen 64 scopeid 0x20<link>
inet6 2601:643:4080:503:dac4:6aff:fe13:12e8 prefixlen 64 scopeid 0x0<global>
inet6 2601:643:4080:503:3d5b:3a41:ce0e:315a prefixlen 64 scopeid 0x0<global>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 9890 bytes 10635528 (10.6 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5792 bytes 1296628 (1.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[/code]
But, no joy trying to disable wlan0 from the command line (wifi is on currently, allowing me to try all this from the comfort of my laptop):
[i]
ewmayer@localhost:~$ ifdown wlan0
-bash: ifdown: command not found
ewmayer@localhost:~$ /sbin/ifdown wlan0
-bash: /sbin/ifdown: No such file or directory
[/i]
Prepending 'sudo' didn't help.

Try "sudo apt install ifupdown". This page indicates that's the package to install ifdown: [url]http://manpages.ubuntu.com/manpages/trusty/man8/ifup.8.html[/url]

If I remember rightly, there are competing systems for network control these days, with varying static-dynamic tradeoffs.
You might need something like "wicked ifdown wlan0" instead (as superuser).

[QUOTE=M344587487;512398]Try "sudo apt install ifupdown". This page indicates that's the package to install ifdown: [url]http://manpages.ubuntu.com/manpages/trusty/man8/ifup.8.html[/url][/QUOTE]

Thanks - that does indeed install ifup/down, but still no joy, with both ifup|ifdown and sans|with 'sudo' prepended, I get:
[i]
Unknown interface wlan0
[/i]
Even though '/sbin/ifconfig -a|grep wlan' clearly shows wlan0:
[i]
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
[/i]
Nick's 'wicked' gives 'comman not found' - lemme guess, I need to install another package for that. :)

Unrelated: another annoyance on this S7 Active phone: I can't figure out how to disable screen Auto-Rotate, that is not an option under Settings -> Display, even though it's rather pertinently display-related, one would think.

[QUOTE=ewmayer;512404]...
Nick's 'wicked' gives 'comman not found' - lemme guess, I need to install another package for that. :)[/QUOTE]Yep, the environment on these phones is very barebones so most of it isn't installed and may not be configured properly when you install it. I've never heard of wicked but haven't ventured far from the defaults. Wifi is one of those things that may be handled strangely because android is involved.

[QUOTE=ewmayer;512404]Unrelated: another annoyance on this S7 Active phone: I can't figure out how to disable screen Auto-Rotate, that is not an option under Settings -> Display, even though it's rather pertinently display-related, one would think.[/QUOTE]
It's in the drop down menu that you drag from the top of the screen. There are a few battery saving options you can also access from there including disabling sync and location tracking if you haven't disabled that already.

[QUOTE=M344587487;512405]It's in the drop down menu that you drag from the top of the screen. There are a few battery saving options you can also access from there including disabling sync and location tracking if you haven't disabled that already.[/QUOTE]

Not on *this* android phone, it's not. (And going to settings, clicking the 'find' magnifying-glass widget and entering 'rotate' brings up nothing.) Ah, well, not a huge deal since once I get everything setup the way I want for Mlucas crunching I won't be handling the phone much.

[QUOTE=ewmayer;512404]Thanks - that does indeed install ifup/down, but still no joy, with both ifup|ifdown and sans|with 'sudo' prepended, I get:
[I]
Unknown interface wlan0
[/I]
Even though '/sbin/ifconfig -a|grep wlan' clearly shows wlan0:
[I]
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
[/I][/QUOTE]And yet, it's pretty clear it's wlan0 doing the talking, judging by traffic counters in your ifconfig output.

That long list of interfaces looks like a bit of an R&D tarpit.

"linux wifi disable" web search turned up this among other things, and it sounds closer to what you want than the preceding. TURN the wifi radio OFF.[CODE]nmcli radio wifi off[/CODE][URL]https://askubuntu.com/questions/597116/how-to-disable-wireless-from-command-line#597131[/URL]
If it can be done from a Windows GUI app (and it can on my laptops), it ought be possible to do the equivalent on linux.
Also has the bonus of avoiding interface names and the correct name syntax.

The man page for it has seemingly everything, including [B]secret agents[/B]. No joke.
[URL]http://manpages.ubuntu.com/manpages/xenial/man1/nmcli.1.html[/URL]

Judging by this emulated terminal's output on a debian linux VM in Virtualbox on a Windows laptop accessed by a remote desktop session, you'll need to install nmcli to try it.[CODE]ken@debian-falcon-x64-2gb:~$ /sbin/ifdown
/sbin/ifdown: Use --help for help
ken@debian-falcon-x64-2gb:~$ /sbin/ifdown lo
/sbin/ifdown: failed to open lockfile /run/network/.ifstate.lock: Permission denied
ken@debian-falcon-x64-2gb:~$ /sbin/nmcli
bash: /sbin/nmcli: No such file or directory[/CODE] Good morning, Mr. Phelps.
Your mission, should you decide to accept it, is to determine why nmcli won't work on the Samsung S7 Android either.
This message will self destruct in (pseudorandom) seconds. [URL]https://www.youtube.com/watch?v=AvBVGsd4Lzc[/URL]

I would look to see if you can do reverse tethering over USB.

[QUOTE=Mark Rose;512543]I would look to see if you can do reverse tethering over USB.[/QUOTE]
Appears to require root access to the phone, plus it raises questions about whether this fits with the high GIMPS-crunching power requirements for a flock of phones from a powered USB hub and the powering scheme and economics Ernst has evaluated. ~8W/phone, 40+W for a 5-pack. Highest I've seen is 4A/powered hub (20W).

[url]https://www.howtogeek.com/214375/how-to-reverse-tether-an-android-smartphone-or-tablet-to-your-pc/[/url]

[QUOTE=kriesel;512557]Appears to require root access to the phone, plus it raises questions about whether this fits with the high GIMPS-crunching power requirements for a flock of phones from a powered USB hub and the powering scheme and economics Ernst has evaluated. ~8W/phone, 40+W for a 5-pack. Highest I've seen is 4A/powered hub (20W).

[url]https://www.howtogeek.com/214375/how-to-reverse-tether-an-android-smartphone-or-tablet-to-your-pc/[/url][/QUOTE]

All the broke-o-phones I've set up so far have perfectly working WiFi - that's in fact a required for the EZ-setup procedure Matt (M344587487) has devised and which I am currently tweaking as I set up additional phones for my own cluster. Besides the power savings and 3-5% improvement in crunching throughput resulting from running in WiFi-off mode, another reason to only turn on as needed for comms with the Primenet server - and if we don't insist on the daily-progress-update run management scheme I outlined using an upgraded version of the primenet.py script and a few server-side API tweaks, we are talking about once a month per phone being sufficient - is the myriads of stealth apps and auto-upgrade crap (which is really hard to entirely disable across all the apps, and Google clearly has reserved itself the right to override pretty much any user settings there if it feels like it - which are constantly doing stuff behind your back if WiFi is on.

Now once a month one can do manually for up to ~10 phones without it becoming an egregious PITA - just tap to enable WiFi on phone1, go to userland, run the primenet.py script in single-shot mode, disable WiFi, proceed to phone2 - but it would still be far, far preferable to have WiFi-toggle-on-demand from the Linux shell built into the comms script. Failing that, I don;t see a way to run at any kind of scale without leaving WiFi on 24/7 - perhaps that could be tweaked into a low-power/low-bandwidth mode, or perhaps there's some way of restricting the Apps which are allowed to use the connection - I'm a relative novice on this stuff, so just throwing ideas out for the experts to take up or shoot down.

As far as my own USB charge station, it has 5 ports, each 2.4A max, 8A max (i.e. 40W) across all ports. Currently happily running 3 S7s , planning to add a fourth today. Sans WiFi I think 1.6A per phone is doable with the battery topped up - OTOH it seems some form of period partial-discharge-and-recharge is built into these things for purposes of battery maintenance. One phone suddenly drawing crunching-plus-recharge amperage could easily spike the total 5-phone demand over 8A. I may have seen such a periodic-discharge cycle occur already, but the symptoms were different - last night when I quick-checked my cluster to make sure all nodes were running, phone1 had mysteriously shut off and the battery was down to 70%. I thought maybe that USB plug on the charger had gone bad on me, but unplugging the phone, turning it back on, restarting Userland and Mlucas and plugging back in started the phone recharging, once again running happily @100% battery charge as I type this.

[QUOTE=ewmayer;512581]Besides the power savings and 3-5% improvement in crunching throughput resulting from running in WiFi-off mode, another reason to only turn on as needed for comms with the Primenet server - and if we don't insist on the daily-progress-update run management scheme I outlined using an upgraded version of the primenet.py script and a few server-side API tweaks, we are talking about once a month per phone being sufficient - is the myriads of stealth apps and auto-upgrade crap (which is really hard to entirely disable across all the apps, and Google clearly has reserved itself the right to override pretty much any user settings there if it feels like it - which are constantly doing stuff behind your back if WiFi is on.
[/QUOTE]Sounds like the sort of thing that might motivate me to very aggressively firewall it upstream of the phones, such as at an AP router.

First draft of how-to-setup-a-C^3 section added to the Mlucas readme page - check out the "Running Mlucas On an Android Cellphone Compute Cluster" section linked at top of page. Comments/questions welcome!

My little 12-node cluster is built out - 10 silicone-sleeved S7 Actives in a pair of 5-port/40W USB charging stations, the 2 metal-housing S7s I bought first dangling from a mini 2-USB-port plug in a wall outlet. I found the metal-housed phones do OK throttling-wise simply in ambient room air, if the location is not too warm and each phone has "air on all sides" - so one is on a 10" microUSB cable, the other on a 4".

Gonna let each phone do a couple successful DCs before switching to first-time tests - once the first results start completing the cluster will be averaging ~3 days per DC at the 2816K FFT needed for current DCs with exponents ~50M. That includes a roughly 25-30% throttling penalty, as I've not yet conducted any experiments with more radical cooling solutions - the slowest of my phones, a metal-cased S7 with a slightly warped backplate, will serve as my guinea pig there. Removing the backplate causes the speed to drop instantly by half, even with very good airflow and a little mini-heatsink mounted atop the hot CPU, indicating that there is some kind of internal (maybe optical "can you see daylight?" based?) backplate-off sensor at work. Sometime in the coming week I will attempt to bypass that by using my Dremel moto-tool with a thin cutting-wheel attachment to cut a small rectangular window in the backplate over the CPU, reaffix the mini heatsink through the window and see what the resulting speeds are. Even should that fail in terms of reducing throttling, the current throttling level is acceptable, given how low-power and quiet the USB cooling fans are - they're rated 4W (0.8A) max, but are plugged into 2 of the 4 USB ports of my little Odroid C2 which sits next to the phone cluster on my desk, and whose USB ports are rated 0.5A max.

All seems stable under 24/7 crunching - the first-bought phone has been going for 3 weeks nonstop - but fingers crossed that batteries don't start exploding after a few months. The current operating mode has batteries remaining @100% except for whatever occasional-maintenance-cycling they may be programmed to do, WiFi turned off once initial setup done - I only need to briefly turn on WiFi every ~2 months and run the primenet.py script in single-shot mode to submit any new results and get more work. Longer-term (in a year or two) it will be interesting to see what kinds of newer-gen phones make for good upgrade targets, and what kind of price the current ones will fetch on resale into the for-parts/backup-phone market.

With WiFi off the risk of sneaky software upgrades putting a halt to crunching is minimized, and it's easy to check that things are running - I just set the screen to always-on at low brightness and before going to bed each night glance at the cluster to make sure all the screens are lit. Low-tech but effective. Briefly touching a fingertip to the back of a phone over where the CPU is is a more reliable secondary check in case there's any doubt - it's not hot in any finger-burning sense, just clearly warmer than ambient.

My worries about the 10 S7 Active phones suffering increase throttling due to their integrated silicone rubber sleeves have been allayed - in the modest fan airflow I provide they do just fine. Presumably silicone rubber was chosen for it combination of grippiness and not-horrible heat transfer capabilities.

Did you give each phone a node name for PrimeNet porpoises? If you did, was there a nice theme?

My ingenious-if-I-say-so-myself naming scheme has the nodes named phone[0,1,2,3,4,5,6,7,8,9,a,b]. Where I find such creative inspiration is a mystery to me. :o

Since the current version of the primenet.py script is essentially just using the manual-test pages behind the scenes, the Primenet server doesn't register any specific machine IDs, it just knows it's dealing with user ewmayer and is probably flagging submissions as both "suspicious" and "annoying" as a result.

[QUOTE=ewmayer;513291]My ingenious-if-I-say-so-myself naming scheme has the nodes named phone[0,1,2,3,4,5,6,7,8,9,a,b]. Where I find such creative inspiration is a mystery to me. :o

Since the current version of the primenet.py script is essentially just using the manual-test pages behind the scenes, the Primenet server doesn't register any specific machine IDs, it just knows it's dealing with user ewmayer and is probably flagging submissions as both "suspicious" and "annoying" as a result.[/QUOTE]

Thank you! I'm glad you chose hex instead of octal! :wink:

[QUOTE=ewmayer;513291]My ingenious-if-I-say-so-myself naming scheme has the nodes named phone[0,1,2,3,4,5,6,7,8,9,a,b]. Where I find such creative inspiration is a mystery to me. :o

Since the current version of the primenet.py script is essentially just using the manual-test pages behind the scenes, the Primenet server doesn't register any specific machine IDs, it just knows it's dealing with user ewmayer and is probably flagging submissions as both "suspicious" and "annoying" as a result.[/QUOTE]Thanks for the laugh. Please consider leaving 2 or more on DC duty continuously, which is now nearly 37M behind, and falling further behind by about 2M/year as is.

[QUOTE=ewmayer;513289]but fingers crossed that batteries don't start exploding after a few months. [/QUOTE]While they are unlikely to "explode", they will certainly gradually lose capacity over time. Why not just remove them entirely? In their current situation they are an unneeded liability.

[QUOTE=retina;513301]While they are unlikely to "explode", they will certainly gradually lose capacity over time. Why not just remove them entirely? In their current situation they are an unneeded liability.[/QUOTE]

As a mini UPS. I don't fancy having to restart 12 phones, 12 UserLAnd sessions and 12 Mlucas jobs every time there's a glitch in the power or a charging cable gets jiggled. Hooking the charging stations to an actual office-desk-style UPS solves the former issue, but not the latter. I don't really care if the batteries lose half their capacity or more over the next couple years, since these are destined to be cannibalized for parts, of which the battery is just one.

Is the main factor degrading LiIon batteries the number of charge *cycles*, constant-full-chargedness, or what? The former is not a problem since the batteries will be at 100% nearly all the time. The built-in periodic-partial-discharge cycling (which seems to happen roughly once a week, based on my limited testing) should address the latter issue, right? IOW, I though the main reason typical heavily-used cellphone batteries degrade quickly is that they undergo many cycles, roughly one a day. Am I misunderstanding the tech here?

[QUOTE=ewmayer;513302]As a mini UPS. I don't fancy having to restart 12 phones, 12 UserLAnd sessions and 12 Mlucas jobs every time there's a glitch in the power or a charging cable gets jiggled. Hooking the charging stations to an actual office-desk-style UPS solves the former issue, but not the latter. I don't really care if the batteries lose half their capacity or more over the next couple years, since these are destined to be cannibalized for parts, of which the battery is just one.[/QUOTE]Okay. I hadn't realised the jobs could not self start. But the setup seems very fragile to me.[QUOTE=ewmayer;513302]Is the main factor degrading LiIon batteries the number of charge *cycles*, constant-full-chargedness, or what?[/QUOTE]In your case the main factor is the passing of time. A secondary factor is that full charge degrades the battery faster than 40% charge.

The ideal situation, which is impractical, is to have the battery at 40% charge constantly. That will give the longest lifetime. But it will still degrade over time. So unless you have some fancy stasis booth to keep the battery in then your battery will degrade no matter how you treat it.

One thing I do with rechargeable batteries that I keep plugged in is to have a programmable timer cut the power off periodically to avoid overcharging which causes chemical loss. This way my rechargeable batteries last for years. iPhone reduces the charging current (trickle charging) after 80% charge to avoid overcharging.
One thing to be careful with lithium batteries is that they can catch fire and indeed people have perished as of resulting fires of such batteries.

[QUOTE=a1call;513306]iPhone reduces the charging current (trickle charging) after 80% charge to avoid overcharging.[/QUOTE]All phones have similar circuitry. But it is not at 80% (how would it know the charge state anyway) and it isn't trickle charge. They use a four state charge cycle.[list=1][*]Trickle, for when the battery voltage is very low (usually under 3.0V). This should never be needed in normal usage.[*]Full current for the main charge.[*]Ramp down in current at full voltage (usually 4.2V).[*]Standby when current reaches 1/10 of full output.[/list]This is usually referred to as CC/CV cycle.

At least that is the basic charge mode that the very cheap controller chips support. There are other methods and cycles, like pulse charging to reduce the ramp down time, and sometimes other voltages and current cut-offs are used to avoid premature failure, etc.

So in any modern phone (i.e. made after ~2005, and even before that) you won't need to manually alter the power delivery to "protect" the battery. The charge controller will do it all itself.

It is 80%
Please see the animation here:



[QUOTE]
Your Apple lithium-ion battery uses fast charging to quickly reach 80% of its capacity, then switches to slower trickle charging. The amount of time it takes to reach that first 80% will vary depending on your settings and which device you’re charging. Software may limit charging above 80% when the recommended battery temperatures are exceeded. This combined process not only lets you get out and about sooner, it also extends the lifespan of your battery.

[/QUOTE]
[CODE]
Stage 2: Trickle Charge
Eases the electrical current to extend battery lifespan.
[/CODE]


[url]https://www.apple.com/ca/batteries/why-lithium-ion/[/url]

[QUOTE=a1call;513308]It is 80%
Please see the animation here:




[CODE]
Stage 2: Trickle Charge
Eases the electrical current to extend battery lifespan.
[/CODE]


[url]https://www.apple.com/ca/batteries/why-lithium-ion/[/url][/QUOTE]Yeah, I know what they [i]say[/i]. It is standard marketing bollocks. They do it like everyone else does it.

So I was playing with my one S7 that has a slightly warped backplate to see if I could hack the cooling - my plan was to use my Dremel moto-tool with a cutting wheel to cut a little rectangular window in the backplate to allow me stick a mini-heatsink on the metal plate over the CPU, but that is easier said than down - the backplate is not metal, it's some kind of weird metallized plastic sandwich with a graphite-based cooling sheet glued to the inside, very hard to cut through without cracking the back. So I decided to do a bit of reading-up on the details of the S7 cooling system, [url=https://pocketnow.com/galaxy-s7-cooling-system-explained]which is quite impressive[/url] - that copper pipe running down the chipset on the opposite (front) side of the phone is in fact a sophisticated liquid-evaporator-condenser system whose inside is a copper micro-mesh. The copper heatpipe is more important to cooling than anything else, and anything which damages it even slightly can really hurt performance of the CPU. I found this out with one of the last several of the batch of 10 S7 Active phones I set up. All the phones are running DCs at 2816K, for the most part timings with the modest airflow supplied by the USB fans range from 64-70 ms/iter. The warped-backplate S7 suffers more throttling and runs 75-80 ms/iter. But the one S7 Active in question wwas inexplicably running at a whopping 120 ms/iter, even though its backplate was intact. This phone has damage to the glass in the bottom-right portion of the face, it looks as if some set it on the ground and stomped on it there. That portion of the case also happens to be where the bottom (recondensation) end of the heatpipe is, and there is a set of 10 pinholes in a 5x2 array in the bottom of the case (these are clearly visible in the photo I added to the Mlucas readme page in the new CCC section, reproduced below) - Since there's no micro-fan inside the case there I don't think they are vent holes, but they definitely appear to be important to the heat spreader system. In the stomped-on phone the holes had been partially blocked by whatever event damaged the case. I used a pin to open them and restore them to their original shape, and moved the phone from the center of the 5-port charging station (by the center of the USB fan, where airflow is weakest) to the leftmost port, and the timings have now dropped to a still-anomalously-high but much better 85 ms/iter.

I think those 5x2 holes are for the microphone.

[QUOTE=retina;513575]I think those 5x2 holes are for the microphone.[/QUOTE]

Ha! the coincidental proximity to the end of the Cu heat pipe fooled me. No *wonder* there's no hot air coming out of this thing, it's all coming out of the person talking into it! :)

So my bit of hole-opening needlework didn't make a difference on the slow phone, it was all due to getting better air from outer part of the USB fan. The only possible use of the holes I could think of in re. heat dissipation was some kind of ambient-air sensor, but even that made little sense.

Oh, someone asked how an S7 stacks up vs a Raspberry Pi3 - Based on Mlucas SIMD-build benchmarks, my Odroid C2 equals 1.5 Raspberry Pi3s, and the Snapdragon CPU of the S7 gives a bit more than 2x the throughput of the Odroid C2, so each of my broke-o-phones gives me around 3.5x the compute throughput of a Pi3.

[QUOTE=ewmayer;513576]Oh, someone asked how an S7 stacks up vs a Raspberry Pi3 - Based on Mlucas SIMD-build benchmarks, my Odroid C2 equals 1.5 Raspberry Pi3s, and the Snapdragon CPU of the S7 gives a bit more than 2x the throughput of the Odroid C2, so each of my broke-o-phones gives me around 3.5x the compute throughput of a Pi3.[/QUOTE]

Cool!

First noticeable runtime glitch among my 12 crunching phones, this phone was one of the last-set-up and has been crunching 24/7 for 2 weeks:
[code]
FATAL: iter = 17649705; nonzero exit carry in radix176_ditN_cy_dif1 - input wordsize may be too small.[/code]
At which point said run was interrupted and the program started on the next exponent in the worktodo.ini file without incident. Once I noticed the glitch, killed the run, restored the interrupted-run exponent to the first line of worktodo file, restart was without incident and no repetition of the above error:
[code]
Restarting M50382649 at iteration = 17640000. Res64: C70880DBB325AAD6, residue shift count = 34099054
M50382649: using FFT length 2816K = 2883584 8-byte floats, initial residue shift count = 34099054
this gives an average 17.472232125022195 bits per digit
Using complex FFT radices 176 16 16 32
[Apr 25 18:19:24] M50382649 Iter# = 17650000 [35.03% complete] clocks = 00:10:59.738 [ 65.9739 msec/iter] Res64: 618DD61892F108AD. AvgMaxErr = 0.045421568. MaxErr = 0.062500000. Residue shift count = 47302787.[/code]

[QUOTE=ewmayer;514694]First noticeable runtime glitch among my 12 crunching phones, this phone was one of the last-set-up and has been crunching 24/7 for 2 weeks:
[code]
FATAL: iter = 17649705; nonzero exit carry in radix176_ditN_cy_dif1 - input wordsize may be too small.[/code]At which point said run was interrupted and the program started on the next exponent in the worktodo.ini file without incident. Once I noticed the glitch, killed the run, restored the interrupted-run exponent to the first line of worktodo file, restart was without incident and no repetition of the above error:
[code]
Restarting M50382649 at iteration = 17640000. Res64: C70880DBB325AAD6, residue shift count = 34099054
M50382649: using FFT length 2816K = 2883584 8-byte floats, initial residue shift count = 34099054
this gives an average 17.472232125022195 bits per digit
Using complex FFT radices 176 16 16 32
[Apr 25 18:19:24] M50382649 Iter# = 17650000 [35.03% complete] clocks = 00:10:59.738 [ 65.9739 msec/iter] Res64: 618DD61892F108AD. AvgMaxErr = 0.045421568. MaxErr = 0.062500000. Residue shift count = 47302787.[/code][/QUOTE]
So, one glitch in a 12 pack in 2+ weeks of running? Plus failover to next assignment so not much throughput lost. Not bad!

[QUOTE=kriesel;514744]Plus failover to next assignment so not much throughput lost. Not bad![/QUOTE]I would have thought that auto-retry for a few times before giving up and moving on would be better. Such things are the job for the computer, not the human operator. Currently it requires manually monitoring the progress and being prepared to manually stop, manually edit and manually restart things. So much "manually" in there. Computers were supposed to be our slaves, not the other way around.

[QUOTE=retina;514747]I would have thought that auto-retry for a few times before giving up and moving on would be better. Such things are the job for the computer, not the human operator. Currently it requires manually monitoring the progress and being prepared to manually stop, manually edit and manually restart things. So much "manually" in there. Computers were supposed to be our slaves, not the other way around.[/QUOTE]

I'll probably add automated retry-from-last-savefile for this, but this particular kind of data-corruption error is relatively rare in my experience, so handling it has been a low priority. It's also a little tricky because the same error signature can occur without data corruption, if the user forces an FFT length significantly larger than the default for a given exponent, e.g.
[code]
M20000059: using FFT length 5120K = 5242880 8-byte floats, initial residue shift count = 9771056
this gives an average 3.814708518981933 bits per digit
Using complex FFT radices 160 32 32 16
mers_mod_square: Init threadpool of 2 threads
Using 2 threads in carry step
FATAL: iter = 275; nonzero exit carry in radix160_ditN_cy_dif1 - input wordsize may be too small.

Return with code ERR_CARRY[/code]
...but the main use case is default production run mode, so the retry logic can simply differentiate on that basis.

First completed DC due tomorrow, from the first-configured phone, which has been running for ~5 weeks. Fingers crossed!

[QUOTE=ewmayer;514748]First completed DC due tomorrow, from the first-configured phone, which has been running for ~5 weeks. Fingers crossed![/QUOTE]

[url=https://www.mersenne.org/report_exponent/?exp_lo=50315123&full=1]That's a match[/url].

This was run on the phone pictured below - first half of the run, before I mass-setup the batch of 10 S7 Active phones, I had it sitting in one of my 5-port-charger-with-USB-fan modules, but as I ended up with 12 phones and just 10 ports splits between 2 such modules, I took this phone and one other, selected on basis of their appearing to have the best-functioning internal cooling systems, and hung them by microUSB cable from a simple little 2-port wall-plug USB charger next to a west-facing living room window which admits cool breezes most of day, except from ~2-7pm when the sun hits that building wall. At night this phones runs ~60ms/iter @2816K; during that late-afternoon warm spell it will throttle back to as slow as ~70 ms/iter on warm days.

Nice. That briefing app looks like one of those apps that take the leftmost tab on the home tabs with the other tabs being used for app icons. You can probably disable it by holding down on an empty app icon space as if you wanted to rearrange icons, swipe to the briefing tab then click the disable toggle top right.

Update on my 12-phone cluster: As of yesterday all but one laggard phone - more on that shortly - has successfully completed its first DC. In addition to the first-completed DC of [url=https://mersenneforum.org/showthread.php?t=23998&page=16]post #170[/url] we have DCs of exponents
[url=https://www.mersenne.org/report_exponent/?exp_lo=50291471&full=1]50291471[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50329519&full=1]50329519[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50345153&full=1]50345153[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50356067&full=1]50356067[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50356997&full=1]50356997[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50380357&full=1]50380357[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50382649&full=1]50382649[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50382677&full=1]50382677[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50382757&full=1]50382757[/url],[url=https://www.mersenne.org/report_exponent/?exp_lo=50382881&full=1]50382881[/url].

There were 2 runs which experienced "nonzero exit carry" data-corruption issues of the kind noted in [url=https://mersenneforum.org/showthread.php?t=23998&page=16]post #166[/url], causing them (due to lack of better handling of this particular kind of error in v18) to halt the run and proceed to the next exponent in the worktodo.ini file. I manually halted both runs, restored the first-run exponent to the top of worktodo.ini and restarted, both runs subsequently completed without incident, and gave results matching the first-time test. That tells me that the data corruption in question - at least based on this limited sample - is in the big residue array, as opposed to the auxiliary precomputed FFT/DWT-related data tables, which are O(sqrt(n)) in size and thus provide a much smaller "attack surface" for data corruption issues. And thus that the way to handle such errors is to simply halt processing and restart from the most-recent savefile. I've implemented this in my v19 under-development code and switched all 12 phones to the latter, in hopes that the second round of DCs will experience at least one more such incident and thus test the new retry-on-error logic.

One other performance-related tweak I've made in v19 is of the "tunable accuracy based on exponent" variety. This is based in the DWT-weights computation code in the carry routines. As noted above, as with the FFT twiddles, my DWT code combines data from a pair of O(sqrt(n)) precomputed tables to on-the-fly generate the needed n DWT weights and their inverses. (Both forward and inverse weights use the same pair of tables, the inverse-weights computation makes use of the identity wt[j]*wt[n-j] = 2, thus to compute 1/wt[j] we use the 2-tables-based forward-weight computation of wt[n-j] and multiply the result by 0.5). Several years ago I added code in the carry step which, instead of computing the weights needed for each convolution output from scratch this way, uses a cheaper chained-weights computation to generate the next few weights from an initial one by applying a fixed (exponent-dependent) multiplier and a conditional factor of 0.5 which can be cheaply computed in branchless fashion. My choice for the length of said up-multiply chain (i.e. how frequently we do a high-accuracy 2-tables re-init of the current DWT weight) was based on the maximum exponents at each FFT length, thus the resulting chains tend to be of short length, typically no more than 8, and - this is dependent on the odd component of the FFT length - as short as 3. But, those high-accuracy reinit steps are expensive, and there is no good reason to use such a fixed chain length targeting the extreme end of the exponent range for each FFT length for the smaller exponents covered by said FFT length. So in v19 I have switched to a 3-tier chain-length scheme, consisting of long,medium and short chain lengths, typical values for these might be 16,8,4 or 15,10,5 depending on FFT length. Based on my numerical trials the lengths get applied like so, based on pmax, the maximum allowed exponent at the given FFT length - parse the below in C case()-style fall-through fashion:

o p < 0.98*pmax uses long chain
o p < 0.99*pmax uses medium chain
o p >= 0.99*pmax uses short chain (previously all p's at the FFT length used the short chain).

I get a speedup of up to 5% from using the long chain, and since each FFT length covers exponents ~10% larger than those of the next-smaller FFT length, 0.98*pmax covers roughly the lower 90% of exponents at each FFT length.

Lastly, as noted in post #23 of [url=https://mersenneforum.org/showthread.php?t=23030&page=3]the next-gen Odroid thread[/url], at the FFT lengths corresponding to the current first-time-test wavefront, the ARMv8 build on 4-core (or more) CPUs really likes the larger leading radices available at each FFT length. E.g. at 5120K leading radix 320 runs as much as a full 10% faster than leading radix 160. Based on my earlier coding-up-and-testing of leading radices 288 and 320, none of the x86-based CPU families I've run on has shown this marked a preference for leading radices > 256: 288 did give as much as a 5% speedup over 144 on some CPUs, but 320 on x86 was a bust, so I left things lying there until now. Since we are within a year or so of transition from 5120K to 5632K at the first-time-test wavefront, in order to get maximal performance on ARM I need leading radix 352. I've added that in my v19 dev-code, and here is the before-and-after comparison versus v18, using the 5632K entries from the respective mlucas.cfg files, the numbers are from running 4-threaded on the 4 cortex-a73 cores of my Odroid N2:

v18: [i]5632 msec/iter = 130.55 radices = 176 32 32 16[/i]
v19: [i]5632 msec/iter = 114.77 radices = 352 16 16 32[/i]

Now, interestingly, the ARM likes larger leading radices so much that even for my DCs running at 2816K, having radix 352 available gives as much as a 5% speedup. Interestingly, said speedup is very thermals-dependent: On my S7 broke-o-phones having good-functioning internal cooling the resulting speedup is modest, 2-3%, e.g. from 61ms/iter to 59ms/iter on the fastest of my phones. But on the phones with poorer internal cooling (based on runtimes), the radix-352 speedup is greater. Using the v18 build and leading radix 176 my one 'laggard' phone mentioned at top of this post was running at an average of 85ms/iter @2816K, for a throughput fully 30% less than my fastest phone (a slimline S7), and - to make for an apples-to-apples comparison - fully 20-25% than its silicone-housing S7 Active brethren, and that 85ms/iter was with the laggard phone placed in one of the edge slots of its 5-port USB charging station, where it catches the maximum outer-part-of-the-fan-blades airflow of the USB fan cooling said charging station. When I switched that particular phone to the beta v19 code, its per-iteration time @2816K dropped from 85ms to 74ms. It used the v18 code for most of it first-DC run, however, thus will need a full week more to complete its initial DC.

The last of my 12 broke-o-phones successfully completed its first DC last week, and earlier today the first (and fastest, as it happens) of the Dirty Dozen finished its 2nd DC and started a first-time test. Timings went from 60 ms/iter @2816K to 98 ms/iter @4608K, a near-perfectly-linear scaling. (The theoretical n * log(n) scaling extrapolates to 101 ms/iter @4608K). Thus it'll need around 100 days to complete said LL test ... but with 12 such tests going on simultaneously things don't look bad at all.

Update - 23 of the 24 DCs (2 per phone) in my initial-assignments batch completed successfully, one mismatched the first-time-test result and a TC showed the cellphone result to be the bad one.

More direly, after several months of running, 5 of the original 12 phones have had to be shut off due to gas-swollen battery packs, and several more are showing signs of that. The 10 S7 Active phones alas are [url=https://www.ifixit.com/Guide/Samsung+Galaxy+S7+Active+Battery+Replacement/108065]such a tight integrated package that it's nigh-impossible to get at the battery[/url], but I tried disconnecting it in the one regular-S7 phone that had swelling, only to find the phone won't power up without the battery connected. So the picture on the cellphone compute cluster front looks a lot less promising that a few months ago - one would need to limit oneself to models with relatively-accessible batteries,

Note that the battery-gas-swelling problem is apparently very common even for regular phone-style usage, just shows up much even more frequently under the stress of 24/7 running. Annoyingly, a simply tiny designed-in pinhole-vent mechanism would cure this problem, but I'm very leery of DIYing such by poking in a hole in one of the swollen battery packs to let the accumulated gas escape ... although with a shut-off phone rendered unusable by said problem, maybe letting the battery first run down to 0 and trying it would be worthwhile. at worst the battery will be rendered unusable, as in "no worse than currently, just with an extra pinhole."

Matt's take:
[quote]Hi,
That is unfortunate, so matey was right about the batteries I thought
it was outdated advice. Maybe there's a way to fake the battery being
connected or run power from the battery connector instead of USB. 3rd
party batteries for S7 exist and are only £4 so there can't be
anything too fancy in them.[/quote]
That's the risk associated with this kind of proof of principle work! That's really the only blocking issue, the phones whose batteries have not suffered the swelling are crunching great, and I rarely have to intervene to restart a phone and such.

[QUOTE=ewmayer;522874]Update - 23 of the 24 DCs (2 per phone) in my initial-assignments batch completed successfully, one mismatched the first-time-test result and a TC showed the cellphone result to be the bad one.

More direly, after several months of running, 5 of the original 12 phones have had to be shut off due to gas-swollen battery packs, and several more are showing signs of that. The 10 S7 Active phones alas are [URL="https://www.ifixit.com/Guide/Samsung+Galaxy+S7+Active+Battery+Replacement/108065"]such a tight integrated package that it's nigh-impossible to get at the battery[/URL], but I tried disconnecting it in the one regular-S7 phone that had swelling, only to find the phone won't power up without the battery connected. So the picture on the cellphone compute cluster front looks a lot less promising that a few months ago - one would need to limit oneself to models with relatively-accessible batteries,

Note that the battery-gas-swelling problem is apparently very common even for regular phone-style usage, just shows up much even more frequently under the stress of 24/7 running. Annoyingly, a simply tiny designed-in pinhole-vent mechanism would cure this problem, but I'm very leery of DIYing such by poking in a hole in one of the swollen battery packs to let the accumulated gas escape ... although with a shut-off phone rendered unusable by said problem, maybe letting the battery first run down to 0 and trying it would be worthwhile. at worst the battery will be rendered unusable, as in "no worse than currently, just with an extra pinhole."
[/QUOTE]
Have you seen the mess a leaking lithium battery can make? I have an old system that I long ago installed a big lithium "Forever" RTC battery in. When it finally leaked, admittedly decades later, it etched the solder and pads off parts of a card or two below it. It looked like my cat had gotten very sick in there. A gentle wipe of the spongy matter crusting the card dislodged a chip that had been cut loose by the etching. But who needs a functioning hard disk interface?
You could try a venting experiment with a sharp pin or very high numbered drill bit, on a fully discharged battery, and the phone that turned in the bad DC. Might be a good idea to put a plastic tray under it to protect your furniture or floor.
A quick try here powering up an old Motorola QA30 without battery shows it wakes up, detects no battery, complains unable to charge (the air where the battery would be), and then refuses any interactive input. But some code is running to get that far.
Maybe rooting your phone would get you around the no-battery barrier?

[QUOTE=ewmayer;522874]I tried disconnecting it in the one regular-S7 phone that had swelling, only to find the phone won't power up without the battery connected.[/QUOTE]I've had the contact plate separate from a cell phone battery. I wonder if you could connect the battery's severed contact plate to a power supply with some narrow gauge enamel wire, insert an inert spacer, and fool it.

Phone farms
 

Put your phones to work earning money to buy replacement batteries or more phones.
[url]https://www.vice.com/en_us/article/d3naek/how-to-make-a-phone-farm?utm_source=pocket-newtab[/url]

[QUOTE=kriesel;522884]Put your phones to work earning money to buy replacement batteries or more phones.
[url]https://www.vice.com/en_us/article/d3naek/how-to-make-a-phone-farm?utm_source=pocket-newtab[/url][/QUOTE]

While I don't support the clickfarm-fraud business model, the associated how-to videos and such are more or less directly applicable for some wanting to set up a compute cluster for other purposes.

Decided to be bold earlier today, all of my bloat-o-phones were charged near 100%, too impatient to fire up Mlucas on one and let it run 3-4 hours to discharge ... just took the most-swollen phone, slipped a sewing needle in the gap created by the swollen battery wedging apart the back from the front housing (see pic below), poked a tiny hole in the foil battery cover. Now I had practiced this before on an S7 which I had earlier basically destroyed by trying to disassemble it to get at the battery - that allowed me to feel the battery pack before and after hole-pokage to let out the excess gas, which told me that the insides are basically solid-core ... there was no liquid leakage out the hole I made.

The one I poked today deswelled nicely, booted up fine and has been cranking Mlucas for 4-5 hours ... its OS must've decided on boot that is was time for a battery discharge/recharge cycle because it ran down to 0, shut off, now after restarting is slowly charging, slowly because under the same full 4-core load. No sign of leakage or explosions yet, ha ... will keep an eye on it for 24-48 hours before attempting the same treatment on one of its fellow bloated brethren. Wish me luck!

I don't understand how releasing the gas can make the battery "work" again.

I guess that the pressure was causing something else to fail. Perhaps the mainboard has dry joints that are distorted when it is flexed.

I still say that if anyone wants to make the devices last ten times longer they will have to find a way to either eliminate the batteries completely, or find a supply of new batteries. And by new I mean freshly made, not stocking up now and trying to use them years later.

[QUOTE=retina;523057]I don't understand how releasing the gas can make the battery "work" again.[/QUOTE]

You misunderstand - the battery never stopped working, it just got so bloated that it started tearing the case apart and representing an explosion risk. I was worried that hole-pokage might cause liquid leakage and such, but no sign of that so far on the one I've performed surgery on.

[QUOTE=ewmayer;523085]You misunderstand - the battery never stopped working, it just got so bloated that it started tearing the case apart and representing an explosion risk. I was worried that hole-pokage might cause liquid leakage and such, but no sign of that so far on the one I've performed surgery on.[/QUOTE]

I don't think lithium batteries so much "leak" as "explode". If it didn't explode when you poked it (by creating an internal short) then I guess you'd be okay? :smile:

There's no shortage of videos online of people destroying Li-ion batteries... on purpose. Those might give you a better idea of what to expect and what could happen in a worst-case scenario. And also entertaining. LOL

[QUOTE=Madpoo;523249]I don't think lithium batteries so much "leak" as "explode". If it didn't explode when you poked it (by creating an internal short) then I guess you'd be okay? :smile:

There's no shortage of videos online of people destroying Li-ion batteries... on purpose. Those might give you a better idea of what to expect and what could happen in a worst-case scenario. And also entertaining. LOL[/QUOTE]

As of today, 5 swollen-battery phones - 4 which I'd shut off before trying the pinhole-vent surgery, and 1 which was running but had gotten pretty bloated - successfully pinhole-vented. On pulling the sewing needle out I typically hear a faint hiss as the accumulated gas vents, and then I can use the palms of my hands to gently squeeze together the bloating-wedged-apart front and back case sections so everything snaps nicely back into place, power the phone back up and away we go. The surgeried phones have been running 24/7 from 1-5 days, so far without incident. The fact that I've only heard gassy noises on poking the hole, never liquid-bubbling, tells me the innards of the battery are perhaps not dry but not liquid. I'm guessing if the venting causes eventual deterioration it will more likely be via slow drying-out of the innards (though the hole is tiny and pressing the case back together may effectively close it back up again, while allowing any further gases to continually be vented) rather than leakage of any corrosive liquid.

Again, several months of 24/7 running will tell the tale, but wouldn't it be amusing if such a simple fix sufficed for most such cellphone battery problems? I mean, judging from the search-engine hits, the incidence of this particular issue is legion.

Unrelatedly, on the software side of things, for unknown reasons UserLand refused to boot up on all the restarted phones, got stuck in "starting services..." mode. But I had backed up all my Mlucas savefiles before powering each bloating-afflicted phone down, so it was a simple matter to uninstalll UserLand, reinstall from the apk file still stored in User Files, install ssh, copy the backed-up files from my PC to the phone and resume.

Electrolytes may be organic (flammable) liquid, ceramic, or glass. [url]https://en.wikipedia.org/wiki/Lithium-ion_battery#Electrolytes[/url]

How disappointing
 

They left out Mlucas [url]https://www.computerworld.com/article/2487680/20-great-uses-for-an-old-android-device.html?utm_source=pocket-newtab[/url]

[QUOTE=kriesel;527046]They left out Mlucas [url]https://www.computerworld.com/article/2487680/20-great-uses-for-an-old-android-device.html?utm_source=pocket-newtab[/url][/QUOTE]

You bastards! :) Relatedly, I think it would be a good thing to try to contact some of the folks in the computer-magazine world who regularly do ARM benchmarks about adding Mlucas to same.

[QUOTE=Madpoo;523249]I don't think lithium batteries so much "leak" as "explode". If it didn't explode when you poked it (by creating an internal short) then I guess you'd be okay? :smile:

There's no shortage of videos online of people destroying Li-ion batteries... on purpose. Those might give you a better idea of what to expect and what could happen in a worst-case scenario. And also entertaining. LOL[/QUOTE]

I just added an UPDATE section to the Mlucas-on-Android-phone section of the [url=http://www.mersenneforum.org/mayer/README.html]Mlucas README[/url] page which resembles that remark.

[QUOTE=ewmayer;523255]...
Unrelatedly, on the software side of things, for unknown reasons UserLand refused to boot up on all the restarted phones, got stuck in "starting services..." mode. But I had backed up all my Mlucas savefiles before powering each bloating-afflicted phone down, so it was a simple matter to uninstalll UserLand, reinstall from the apk file still stored in User Files, install ssh, copy the backed-up files from my PC to the phone and resume.[/QUOTE]
I remember userland being very finicky in how you get it started, navigate to the wrong tab and back or switching tabs while it was still loading and it stalled.

[QUOTE=M344587487;527306]I remember userland being very finicky in how you get it started, navigate to the wrong tab and back or switching tabs while it was still loading and it stalled.[/QUOTE]

I've found what appears to be a reliable workaround - i.e. not needing reinstall nor risking data loss - for such startup-hangs, also described in the aforementioned update to the Mlucas readme page - The workaround is to touch the 3 vertical dots at top right of the main UserLAnd menu bar, select "Clear All Support Files", then retry Ubuntu startup. This may need WiFi to be enabled - been a while since I ran into the problem, and no longer 100% sure if I needed WiFi for the workaround, or for the older clean-reinstall kludge).

[QUOTE=kriesel;527046]They left out Mlucas [url]https://www.computerworld.com/article/2487680/20-great-uses-for-an-old-android-device.html?utm_source=pocket-newtab[/url][/QUOTE]

Update -- I managed to dig up an e-mail contact for the author of that article, sent him links to the Mlucas readme (highlighting the Android-phone section) just heard back from him: "Hey, [i]there's[/i] an interesting use! Thanks for passing it along." No corresponding edits in the article, though, at least not as of this writing.

A new use for old phones:
[url]https://www.androidcentral.com/artist-creates-fake-traffic-jams-google-maps-99-phones-and-wagon[/url]

[QUOTE=Uncwilly;536615]A new use for old phones:
[URL]https://www.androidcentral.com/artist-creates-fake-traffic-jams-google-maps-99-phones-and-wagon[/URL][/QUOTE]An obvious solution to the traffic jam spoofing is to confirm or contradict traffic density indications by reference to increasingly ubiquitous traffic cameras, many of which are publicly available on the internet.

[QUOTE=ewmayer;548645]I'm down to just 3 of the 12 Andoid broke-o-phones which were my main GIMPS-crunching hardware outlay last year, I doubt more than one of those will last through end of this year, the batteries slowly deteriorate and apparently the system software does not allow the damn things to run sans working battery, simply off a microUSB power/recharge cable.[/QUOTE]So how much do broke-o-phone battery replacement or reconditioning cost? Getting only one year out of most before their value drops for lack of a battery does not seem like what you had budgeted for. That's an unfortunate turn of events.

[QUOTE=kriesel;548835]So how much do broke-o-phone battery replacement or reconditioning cost? Getting only one year out of most before their value drops for lack of a battery does not seem like what you had budgeted for. That's an unfortunate turn of events.[/QUOTE]

Batteries are difficult if not impossible to replace in these things ... you can peruse ifixit.com for the gory details. The smooth-case ones are bad enough, the 2 sides of the metallized plastic clamshell case are glued together but with careful application of heat and some really delicate prying one can allegedly open them nondestructively. When I tried it on 1 of the 2 such ones I bought out of my Dirty Dozen, I shattered the caseback. Then one encounters the glued-into-place battery and lots of tiny routed-through-multiple-parts-of-the-chassis wiring. That phone was not a dead-battery one, but was the first batteries-swell-with-flammable-gas-accumulation case I ran into. I.e. I didn't so much want to replace the battery as to see if there was a simple way to release the gas while leaving the battery insides otherwise functional. Answer is yes, but I destroyed that battery in figuring it out. The other 10 phones are rubberized all-glued-together 'extreme' models, there one can deswell the battery using a sewing needle poked through a small gap in the swelling-induced separation of front and back halves of the case, but good luck getting said halves apart for e.g. battery replacement.

See my Mlucas readme page for further adventures with battery-degasification. The 'flammable' bit comes into play at a later point. long story short, all 12 phone batteries within months suffered the pains of intestinal bloating, 3 did not survive my attempts to release the pressure. The remaining 9 lasted on average around a year, but are now down to 3. Sure I'm disappointed they don't last longer, but the $ outlay was not huge for what I consider a useful proof-of-principle, namely that ARM-based phone CPUs running code tuned for that instruction set can be quite fast, relatively speaking. The units as a whole are simply designed, like so much modern e-gear, for planned and rapid obsolescence.

[QUOTE=ewmayer;548838]Batteries are difficult if not impossible to replace in these things ... you can peruse ifixit.com for the gory details.[/QUOTE]Yeah, seen that elsewhere.

J7's are easier; no adhesive involved for the back plate, and there's a little notch there to peel it off using a fingernail. Light pressure snaps the catches back in place.

For S7, [URL]https://www.amazon.com/Battery-Upgraded-Li-Polymer-Replacement-Warranty/dp/B07T4FB799/ref=psdc_2407780011_t3_B06XCJMR2R[/URL]
One site indicated 15 to 45 minutes required. A new kit of tools would not be needed for each. Kind of expensive by the ounce.
[url]https://www.ebay.com/itm/New-Replacement-Battery-for-Samsung-Galaxy-S10-Plus-S9-S8-Plus-S7-S6-edge-S5-S4/283238094849?hash=item41f24e5801:g:kqQAAOSwEOJb2gN1[/url]